ai-rete-rag
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AI_RETE_RAG_API_KEY | No | Your API key — authenticates calls and ties them to your plan quota. Without a key you can still explore shared demo domains subject to free-tier limits. | |
| AI_RETE_RAG_API_URL | No | API base URL — point at http://localhost:8000 for local dev. | https://ai-rete-rag.com |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| decideA | 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 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
The result's |
| list_rulesA | 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 |
| get_parametersA | List the input parameters a domain's rules decide on — the facts to
collect before calling Each parameter has its |
| ingest_textA | 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). Ingesting into a built-in demo domain gives your account its own copy of that demo (it counts as one of your domains); the shared demo others see is unchanged. On team plans, only the domain admin (the member who created the domain, or the subscription owner) can add documents. Documents can be dated. A decision only cites documents in force on its
date, so a replaced policy is never quoted for a new decision. To publish a
new version, ingest it under a new Args: domain: Domain to ingest into (existing or new). text: The policy or reference text. source: Optional source name shown in the document list. effective_from: First day this document applies, as YYYY-MM-DD (default: always). effective_until: First day it no longer applies, as YYYY-MM-DD (default: no end). supersedes: Source name of the document this one replaces. |
| list_documentsA | List the documents ingested into a domain's knowledge base. |
| get_rule_sourceA | Fetch a domain's rule set as editable YAML (plus the parsed rules and
whether you may edit it). Use this before |
| put_rulesA | 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). Saving to a built-in demo domain saves your own copy of it, seeded from the demo; the shared demo others see is unchanged. 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 — Use either A rule may also carry IMPORTANT: when persisting drafts returned by 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. |
| import_policy_rulesA | 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 Args: domain: Domain the rules are drafted for (an owned domain or a new name). policy_text: The policy document text (max ~50k characters). |
| get_usageA | Show this account's decision usage, plan, and remaining monthly quota. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| decide_case | Agent workflow: pick the parameters a domain's rules need from a case — text, photos, voice notes or video — ask for what is missing, and reach a rule-backed verdict. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools are clearly distinct across the decision lifecycle: inspecting parameters, listing rules, fetching editable rule YAML, deciding, ingesting documents, drafting rules, saving rules, and checking usage. However, get_parameters, list_rules, and get_rule_source all expose rule/domain metadata and can overlap when an agent is trying to learn which facts or rules matter before calling decide.
All tool names use consistent snake_case and are predominantly imperative verb_noun forms such as get_parameters, list_rules, put_rules, ingest_text, and import_policy_rules. The single verb decide is the one deviation, but it is clear and consistent with the server's action-oriented naming style.
Nine tools is well scoped for a rule-based RAG decision server, covering discovery, authoring, ingestion, decision-making, and account usage without feeling bloated. Each tool appears to support a real part of the workflow.
The core lifecycle is covered: inspect parameters and rules, author/import/save rules, ingest and list documents, make decisions, and check usage. Minor gaps exist around domain/document management, such as no explicit list_domains or document deletion/read-content tool, though list_rules across all domains may partially mitigate this.