ai-rete-rag

Make a decision

decide

Make deterministic, auditable decisions in a domain using a rule set, not an LLM. Provide a query and facts to get a verdict and explanation.

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". 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

TableJSON Schema

Name	Required	Default
`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

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the real behavioral burden and does so well: deterministic/non-LLM verdicts, explanations sourced from ingested policy docs, free-tier domain limits, and the `missing_parameters` contract that determines whether a verdict is provisional. It also documents `rule_firings` causal ordering and `asserted_facts`, which the agent could not infer otherwise.

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

Conciseness4/5

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

It is long, but front-loaded with the verdict mechanism and its guarantees before the Args block, and each paragraph adds distinct information (audit trail, free-tier behavior, missing_parameters semantics). Some prose in the Args block is verbose enough that it could be tightened, keeping it from a 5.

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?

For an 8-parameter tool with an output schema (so return values need not be described) and only safety annotations, the description supplies everything an agent needs: input semantics, mode selection, free-tier constraints, the next_step handoff, and how to interpret missing_parameters. Nothing material is left unstated.

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% across 8 parameters, so the description must compensate, and it does: every parameter is explained with examples (facts, fact_sources with audit implications, unstructured_text extraction, the three response_mode values, and the two pattern flags). The fact_sources explanation adds meaning the schema cannot convey (typed vs evidence-read facts recorded as 'request').

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 opening sentence names a specific verb and resource ('Make a deterministic, auditable decision in a domain') and immediately characterizes the mechanism (Rete rule engine, never the LLM). This clearly separates it from siblings like list_rules, put_rules, get_parameters, and ingest_text, which manage rules/documents rather than produce a verdict.

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 real operating context: no API key means demo domains only, and it points to get_parameters to discover which fields a domain's rules test. It also tells the agent what to do with `next_step`. It stops short of explicit when-not-to-use routing (e.g., 'use put_rules to define a domain before calling decide'), so a 4 rather than 5.

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

Deploy Server