mcp server

ai·rete·rag

Author rules from policy docs, then decide: a Rete engine gives the verdict, an LLM explains why.

Description as published by the maintainer. Source

• version 0.6.1
• active
• retrieval

active — Most recent push to the repository was 2026-08-05. Dashed tags are derived by ZBS Index from the published description, not stated by the maintainer.

What this server can do

8 functions, named and described by the server itself. Parameter names are shown because they say more about what a function does than its name usually does.

decide(facts, query, domain, response_mode, unstructured_text, extract_from_retrieval, filter_retrieval_with_rules)

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. 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 `list_rules` to see which fields a domain's rules test. unstructured_text: Optional free text (an application, a case note); 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). Required: domain, query.

get_rule_source(domain)

Fetch a domain's rule set as editable YAML (plus the parsed rules and whether you may edit it). Use this before `put_rules` to see the current rules; the built-in demo domains are read-only. Required: domain.

get_usage

Show this account's decision usage, plan, and remaining monthly quota.

import_policy_rules(domain, policy_text)

Convert a written policy document into DRAFT decision rules (LLM-assisted). Returns validated draft rules (when/action, including chained asserts where the policy stages its determinations), derived rule→rule edges, and overlap warnings. Each returned rule carries a `citation` field holding the policy sentence it encodes (also summarized in the top-level `citations` map). NOTHING IS SAVED: review the drafts (and show them to the user), then persist explicitly with `put_rules` — validate first with dry_run=true, and keep each rule's `citation` in the YAML you save so the audit trail back to the policy survives. Args: domain: Domain the rules are drafted for (an owned domain or a new name). policy_text: The policy document text (max ~50k characters). Required: domain, policy_text.

ingest_text(text, domain, source)

Add policy/reference text to a domain's knowledge base. The text is chunked and embedded; explanations for future decisions in this domain will cite it. Creating a new domain claims it for your account (plan limits apply). The built-in demo domains are read-only — ingest into your own domain instead. On team plans, only the domain admin (the member who created the domain, or the subscription owner) can add documents. Args: domain: Domain to ingest into (existing or new). text: The policy or reference text. source: Optional source name shown in the document list. Required: domain, text.

list_documents(domain)

List the documents ingested into a domain's knowledge base. Required: domain.

list_rules(domain)

List the decision rules for one domain (or all domains). Returns each rule's conditions — either a flat AND list (field / operator / value) or a `when` condition tree (nested all/any/not) — plus its verdict, salience, and any asserted facts (`action.assert`, the facts a rule produces for other rules to consume). `edges` lists the derived rule→rule dependencies: src asserts a fact type that dst's conditions test (forward chaining). Each rule may also carry `citation` — the policy sentence it encodes — which is what lets a decision be traced back to the source clause. Also includes overlap warnings. Use this to learn which fact fields a domain expects before calling `decide`.

put_rules(domain, dry_run, rules_yaml)

Create or replace a domain's rule set from YAML (self-serve rule authoring). The first save to a new domain claims it for your account (plan limits apply); the built-in demo domains are read-only. Rules are validated before saving — set dry_run=true to validate without persisting. The response reports ok/errors, the parsed rules, and any overlap warnings. YAML format — a list of rules. Flat form (conditions are AND-ed): - name: "Approve" salience: 10 conditions: - type: loan field: credit_score op: ">=" value: 700 action: verdict: "APPROVED" reason: "Credit score meets threshold" Tree form — `when:` holds nested all/any/not condition groups, and an action may assert derived facts that other rules consume (forward chaining; the rule graph derives from these automatically): - name: "Sepsis Screen" salience: 30 when: all: - {type: clinical, field: temperature_f, op: ">=", value: 101.5} - any: - {type: clinical, field: wbc_count, op: ">", value: 12.0} - {type: clinical, field: bands_pct, op: ">", value: 10} action: verdict: "URGENT_ALERT" assert: - {type: sepsis_flag, fields: {severity: high}} - name: "Escalate" salience: 40 when: all: - {type: sepsis_flag, field: severity, op: "==", value: high} - {type: clinical, field: age, op: ">=", value: 65} action: verdict: "ADMIT_ICU" Use either `conditions:` or `when:` per rule, never both. `not` passes when the inner condition does not hold (including when the field is absent). Produce/consume cycles between rules are rejected at validation. An action may also carry `retrieval_scope: { <key>: <value> }` to narrow which documents retrieval searches (Pattern 01). A rule may also carry `citation:` — the policy sentence it encodes. It is stored with the rule and shown beside it in decision audits, so a verdict can be defended with the source language, not just the rule name: - name: "Decline Late Returns" salience: 20 citation: "Returns are accepted within 30 days of delivery." when: all: - {type: retail, field: days_since_delivery, op: ">", value: 30} action: verdict: "DENIED" IMPORTANT: when persisting drafts returned by `import_policy_rules`, copy each rule's `citation` through into this YAML. Dropping it silently loses the link from the decision back to the policy clause that justifies it. Args: domain: Domain to author (an owned domain, or a new name to claim). rules_yaml: The full rule set as YAML text. dry_run: Validate only, without saving. Required: domain, rules_yaml.

Last successful function declaration observed on 2026-08-13. Source: https://ai-rete-rag.com/mcp. We list what the server declared; we do not call any of these functions.

Endpoint status observed on 2026-08-13. Source: https://ai-rete-rag.com/mcp.

Signals

These are separate measurements of different things. They are deliberately not combined into one score, because a popularity number that mixes website traffic with saves and stars cannot be checked or acted on.

Where to get it

• Repository — https://github.com/zaharajabeen13-create/ai-rete-rag-mcp
• Website — https://ai-rete-rag.com
• pypi: ai-rete-rag-mcp
• Remote endpoint (streamable-http) — https://ai-rete-rag.com/mcp

Also from zaharajabeen13-create

• Inferra
  Auditable rule-based decisions with RAG explanations: a Rete engine decides, an LLM explains why.