What ai·rete·rag does
The ai·rete·rag MCP server connects an MCP client to the ai·rete·rag decision service. It supports domains containing policy rules and a knowledge base of ingested documents. Agents can inspect existing rules, create rules from YAML, turn written policy into draft rules, and evaluate cases using structured facts or free text.
The verdict comes from a Rete rule engine. Retrieval-augmented text is used to explain the result, not to replace the rule evaluation. This separation is useful when a workflow needs reproducible decisions alongside explanations that cite the policy material behind them.
How it works
A typical workflow starts with get_parameters, which returns the facts used by a domain's rules, ordered by decisiveness. The agent can then map information from a case into those fields and call decide. The decision response can identify missing parameters, allowing the agent to request additional facts and evaluate the case again.
decide accepts structured facts and/or free text. It also supports two optional retrieval patterns: one can narrow the applicable rule scope, and the other can place retrieved information into working memory. When an agent extracts facts from files or other media, fact_sources can record which source supplied each fact for the decision audit trail. The API receives the extracted facts rather than interpreting the media itself.
Setup and configuration
The ai·rete·rag MCP server can be started on demand with uvx ai-rete-rag-mcp, installed from PyPI with pip install ai-rete-rag-mcp, or run from a source checkout. Configure AI_RETE_RAG_API_KEY with an API key created in the service settings. The key authenticates requests and associates them with the account's plan quota.
AI_RETE_RAG_API_URL defaults to https://ai-rete-rag.com and can point to another API base, such as http://localhost:8000 for local development. A key is not required to explore shared demo domains, although free-tier limits apply.
The hosted service is also available at https://ai-rete-rag.com/mcp. The authenticated endpoint at /mcp/auth uses a browser sign-in flow and is intended for account-specific access. Clients that support a static authorization header can use the regular /mcp endpoint with a bearer key.
Tools and capabilities
The server exposes these MCP tools:
decide evaluates a case in a domain and returns the rule-derived verdict with an explanation.
get_parameters lists the facts a domain's rules use, with the most decisive first.
list_rules shows rule conditions, verdicts, salience, and overlaps.
get_rule_source returns a domain's rules as editable YAML.
import_policy_rules creates unsaved draft rules from policy text and cites the source sentence for each draft.
put_rules creates or replaces a domain rule set from YAML and supports validation with dry_run.
ingest_text adds policy text to a domain knowledge base.
list_documents lists ingested documents.
get_usage reports the plan and remaining monthly decision quota.
The import workflow does not save rules automatically. Review the drafts first, then use put_rules when they are ready.
Limitations and notes
The LLM does not determine the verdict; the Rete engine does. Explanations depend on policy documents ingested into the relevant knowledge base. The service's API receives facts extracted by the agent, so the agent—not the API—reads photos, scans, voice notes, or video.
Account-based usage is tied to the configured API key and plan quota. Without a key, access is limited to shared demo domains and their free-tier constraints. Hosted connections that require browser authentication may need the /mcp/auth custom connector rather than a header-based connection.