Is ai·rete·rag MCP server safe?

Findings (1)

• lowUnusually long tool description (over 2,000 characters)poison.long-description

  tool decide: …Make a deterministic, auditable decision in a domain. The verdict comes from the domain's rule set (Rete engine, never the LLM), so it is reproducible and compliant. The explanation is generated from the domain's ingested policy documents. Without an API key only the shared demo domains are available, and the response carries `next_step`: how to get a free key for your own rules. Pass that on to the user rather than dropping it. Args: domain: Rule-set domain, e.g. "loan", "fraud", "clinical". query: Natural-language question or decision request. facts: Structured facts for working memory, e.g. {"credit_score": 710, "annual_income": 85000}. Use `get_parameters` to see which fields a domain's rules test. Facts you read yourself from photos, document scans, voice notes or video go here, under those field names; explicit facts always win over anything extracted server-side. fact_sources: Where each fact in `facts` came from, e.g. {"monthly_income": "payslip.jpg", "claim_usd": "voice note 1"}. Always set this for facts you read from a file, photo, recording or video: it is stored in the decision's audit record so a reviewer can tell typed facts from ones read off evidence. Facts without a source are recorded as "request". as_of: Read the domain's policy documents as of this day, as YYYY-MM-DD (default: today). Use the date a case was filed to decide it under the policy in force then; the rules themselves are always the current ones. unstructured_text: Optional free text (an application, a case note, a voice-note transcript, what a photo or video shows); facts are extracted from it automatically and merged. response_mode: "verdict_only" (fastest), "verdict_with_explanation", or "full_audit" (every rule evaluation + retrieved chunks, available on every plan including the free tier). rule_firings come back in causal order: a rule that matched a fact asserted by an earlier firing appears after it, with the derived facts listed under `asserted_facts`. filter_retrieval_with_rules: Pattern 01 — run the rules first and let a fired rule's `retrieval_scope` action narrow which documents the retrieval searches before it runs. extract_from_retrieval: Pattern 02 — parse the retrieved documents into facts and assert them into working memory, so rules fire on what was actually read (not just the facts you passed). The result's `missing_parameters` lists rule inputs that were not supplied but could still change the verdict, most decisive first. When it is non-empty, tell the user the verdict is provisional and ask for those facts; when it is empty, more facts cannot change the verdict. …