ai-rete-rag

Make a decision

decide

Make a deterministic, auditable decision in a domain.

Instructions

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.

Input Schema

Name	Required	Default
`as_of`	No
`facts`	No
`query`	Yes
`domain`	Yes
`fact_sources`	No
`response_mode`	No	verdict_with_explanation
`unstructured_text`	No
`extract_from_retrieval`	No
`filter_retrieval_with_rules`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.11.0Oct 22, 2026

addedInput schema / properties / as_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "As Of"
+}

Changed1 schema field changedv0.9.0Oct 3, 2026

addedInput schema / properties / fact_sources

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Fact Sources"
+}

First observedv0.5.3Aug 2, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=false and destructiveHint=false already set, the description adds substantial behavioral context beyond annotations: verdicts come from a deterministic Rete engine, explanations come from policy documents, fact_sources are stored in an audit record, and missing_parameters signals provisional verdicts. It also explains response_mode ordering and retrieval patterns, which an agent needs in order to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but proportionate to nine parameters and complex behavior. It is front-loaded with the core purpose and mechanism, then organized into an Args section with one clear block per parameter, and closes with actionable guidance on missing_parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description does not need to document every return field, yet it still highlights important response semantics: next_step, missing_parameters, and rule_firings causal order. Combined with detailed parameter and API-key guidance, it gives an agent everything needed to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the full burden, and it does: every one of the nine parameters is explained with purpose, examples, defaults, and interactions. This includes domain and query examples, facts field discovery via get_parameters, fact_sources audit semantics, as_of policy-date meaning, response_mode trade-offs, and the two retrieval patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: making a deterministic, auditable decision in a domain. It explains the mechanism (Rete rule engine, not the LLM) and the source of explanations (ingested policy documents), which distinguishes this tool from sibling rule-management tools such as list_rules or put_rules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operational context: demo domains without an API key, use get_parameters to discover fields, use as_of for historical policy, and pass next_step to the user. It does not explicitly say when to prefer decide over siblings like get_rule_source or ingest_text, but the intended use case is clear from the purpose and parameter guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server