Loading ToolBench
MCP server for ai·rete·rag — deterministic rule-based decisions with RAG-powered explanations
Six tools with complete schemas and descriptions. Tool naming follows verb_noun pattern (decide, list_rules, ingest_text, list_documents, get_rule_source, put_rules). Descriptions are substantive (100-300 chars), explaining WHAT, WHEN, and consequences. All parameters have types and descriptions. Input schemas are well-structured with enums (response_mode). Error handling is present but generic. Security: API key injection via environment variables is correct; no secrets in parameters. Composition is sound, each tool has one responsibility. Main gaps: output schemas not documented in code; error recovery guidance minimal; no pagination for list tools.
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.
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.
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.
List the documents ingested into a domain's knowledge base.
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`.
Output schemas not documented. Tool descriptions explain inputs but not return structure. LLMs cannot plan downstream calls or extract fields without knowing what decide(), list_rules(), etc. return.
list_documents and list_rules lack pagination parameters (limit, offset, cursor). Large result sets will blow context windows. No documented result cap.
Error responses are generic ('Error {status_code}: {detail}'). No recovery guidance. If decide() fails with 'Invalid domain', LLM has no hint to call list_rules() first.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
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.
put_rules is destructive (replaces entire rule set) but lacks confirmation/dry-run guidance in description. dry_run parameter exists but description does not emphasize irreversibility.
decide() accepts 'facts' as dict[str, Any] with no schema validation. Description says 'Use list_rules to see which fields a domain's rules test' but does not specify format, required fields, or type constraints per domain.