ai-rete-rag

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.1
Disambiguation4/5
Each tool has a distinct role: decide runs the engine, list_rules and get_rule_source expose rule views in different formats (readable vs. editable YAML), put_rules and import_policy_rules handle rule authoring vs. drafting, ingest_text and list_documents manage knowledge, and get_usage tracks account limits. There is minor overlap between list_rules and get_rule_source, but their differing output formats make the purpose clear.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern: decide, list_rules, ingest_text, list_documents, get_rule_source, put_rules, import_policy_rules, get_usage. Every name clearly indicates the action and the resource, with no mixing of styles or vague verbs.
Tool Count5/5
With 8 tools, the set is well-scoped for a rules-and-RAG domain. It covers decision execution, rule inspection/authoring (including import), document management, and account usage without unnecessary bloat or missing critical pieces.
Completeness4/5
The surface covers the core lifecycle: rule viewing (list_rules, get_rule_source), rule creation/replacement (put_rules), rule drafting from policy (import_policy_rules), document ingestion/listing, and decision execution (decide). Minor gaps exist—no explicit delete for rules or documents—but put_rules can clear rules by replacing with an empty set, and document deletion is not essential for the primary workflow.
Average 4.6/5 across 8 of 8 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares safe read-only behavior, and the description adds the scope of 'ingested into a domain's knowledge base.' It does not discuss pagination, ordering, or return details, but for a simple list tool with annotation coverage, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter input, the presence of an output schema, and a clear scope in the description, it is mostly complete. It could benefit from noting whether results are sorted or paginated, but those are non-critical gaps for a basic listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'domain's' in passing, which implies the domain parameter selects the knowledge base, but it does not explain domain's format, requiredness, or behavior. The single parameter is simple, but the description adds minimal value.
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 description uses a specific verb ('List') and resource ('documents ingested into a domain's knowledge base'), clearly stating what the tool does. It differentiates from siblings like list_rules by targeting documents rather than rules.
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?
Provides clear context: this lists documents from a domain's knowledge base, which implies when it should be used versus other tools like ingest_text or put_rules. However, it does not explicitly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already discloses the read-only nature. The description adds context by specifying it is scoped to 'this account' and includes 'remaining monthly quota,' which is useful. It does not disclose other behavioral traits like caching or data freshness, but for a simple usage check this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action 'Show,' and contains no redundant words. Every word contributes to understanding the tool's purpose and scope.
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?
The tool is simple with no parameters and has an output schema that likely describes return values. The description covers the purpose and scope, making it complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The empty schema already covers all parameter information, and the description adds no unnecessary detail. This is appropriate.
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 description uses a specific verb 'Show' and clearly identifies the resource: the account's decision usage, plan, and remaining monthly quota. This distinguishes it from sibling tools like 'decide' or 'list_rules' that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it shows account usage and quota, suggesting it would be used to check limits before making decisions. However, it does not explicitly state when to use it or mention alternatives such as the 'decide' tool that consumes quota.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already covers the read-only nature, but the description adds useful context by mentioning that the tool returns 'whether you may edit it' and that demo domains are read-only. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main function, followed by usage guidance. Every word earns its place with no redundancy or fluff.
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 a tool with one parameter and an output schema, the description is complete. It explains the purpose, what is returned (editable YAML, parsed rules, editability), and when to use it. No missing information required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), and the description only clarifies that the parameter is a 'domain' without explaining its format or allowed values. While the meaning is inferable from the tool name and context, it does not compensate for the lack of schema documentation.
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 description clearly states the tool fetches a domain's rule set as editable YAML, plus parsed rules and editability status. It specifies the exact resource (domain's rule set) and verb (fetch), and distinguishes itself from sibling tools by positioning it as a precursor to put_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use this before put_rules to see the current rules.' It also notes a key constraint: 'the built-in demo domains are read-only,' providing clear guidance and an alternative-related tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint annotation by detailing the return structure: condition formats (flat AND list or when tree), verdict, salience, asserted facts, edges with forward-chaining semantics, citation purpose, and overlap warnings. This gives an agent a thorough understanding of what to expect from the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences pack a high density of information without fluff. Front-loaded with the primary action, each subsequent sentence adds meaningful semantics (return fields, edges, citation, overlap warnings) and ends with a practical use case. No word is wasted.
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?
The description fully contextualizes the tool: what it lists, what the output contains, why edges and citations matter, and how the domain parameter behaves. Given the simple schema (1 optional param) and presence of an output schema, this description is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter description (0% coverage), but the phrase 'one domain (or all domains)' clarifies that the `domain` parameter filters to a specific domain while null/omission means all domains. This is valuable, though it doesn't explicitly name the parameter or mention validation/format.
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 description opens with 'List the decision rules for one domain (or all domains),' clearly stating a specific verb and resource with a scope qualifier. It also distinguishes the tool from siblings like `decide` by positioning it as a read-only listing tool for learning domain expectations, and its focus on rules differentiates it from `list_documents` and `get_rule_source`.
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?
Provides a clear when-to-use signal: 'Use this to learn which fact fields a domain expects before calling `decide`.' This explicitly ties the tool to a pre-decision workflow, but it lacks an explicit 'when not to use' or named alternatives for related operations like retrieving the original policy text (get_rule_source).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses key behavioral traits: decisions are deterministic, reproducible, and compliant because they are produced by the rule engine rather than the LLM. It also details how rule_firings are ordered causally and what response modes return, adding substantial value beyond structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, it is well-structured and front-loaded with the core purpose, followed by a clear Args list and advanced usage patterns. Each sentence adds necessary information for a complex 7-parameter tool with no schema descriptions, so there is little waste.
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?
Given the tool's complexity and 7 parameters, the description is thorough: it covers what the tool does, how verdicts are produced, how to inspect rules, how response modes work, and how advanced retrieval patterns can be used. The presence of an output schema reduces the need to document return values, but the description still offers relevant return behavior for audit mode.
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?
With 0% schema description coverage, the description fully compensates by explaining every parameter in the Args section, including an example for facts and clarifying the meaning of response_mode and the two retrieval patterns. The enum values are enriched with practical guidance (e.g., 'verdict_only' is fastest, 'full_audit' is available on every plan).
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 description opens with 'Make a deterministic, auditable decision in a domain' which uses a specific verb and resource, and distinguishes the tool from siblings like list_rules and ingest_text. It further clarifies that the verdict comes from a Rete engine, not the LLM, leaving no ambiguity about its core function.
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?
The description provides clear context for use: making decisions in a domain based on rule sets, with examples of domains. It references list_rules as a way to determine which facts a domain requires, giving the agent a path for preparation, but it does not explicitly state when not to use the tool or name alternatives for exclusion. This falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations mark the tool as non-read-only and non-destructive, the description adds valuable behavioral context: text is chunked and embedded, future explanations will cite it, creating a new domain claims it for the account, plan limits apply, and admin permissions are required on team plans. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: a purpose statement, behavioral detail, usage restrictions, and a clear Args list. Every sentence carries relevant information without filler, and the most important action appears first.
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?
Given the tool's moderate complexity, the description covers purpose, behavior, ownership implications, permission constraints, and all parameters. Since an output schema exists, not detailing return values is acceptable. The description is complete enough for an agent to select and invoke the tool correctly.
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%, so the description must fully compensate. It does: 'Args' defines domain (existing or new), text (policy/reference text), and source (optional source name shown in the document list). This adds meaning beyond the bare schema properties.
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 description clearly states the verb and resource: 'Add policy/reference text to a domain's knowledge base.' It also explains that text is chunked/embedded and cited in future decisions, which distinguishes this from sibling tools like list_rules, decide, or get_usage.
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?
The description gives clear context: demo domains are read-only, so users should ingest into their own domain; team plans restrict ingest to domain admins. It does not explicitly contrast with sibling tools like put_rules or import_policy_rules, but it does provide practical when-to/when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with destructiveHint=true, the description adds substantial behavioral detail: domain claiming, plan limits, read-only demo domains, validation before saving, response contents, cycle rejection, and the behavior of 'not' on absent fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: summary, ownership caveats, YAML formats with examples, validation semantics, citation guidance, and an integration note for import_policy_rules. It is front-loaded and well-structured.
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?
Given the tool's high complexity (nested all/any/not, forward chaining, citations, retrieval scopes), the description thoroughly covers behavior, input format, edge cases, and response contents. It is complete enough for an agent to select and invoke the tool correctly.
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%, but the Args section and extensive YAML examples thoroughly explain domain, rules_yaml, and dry_run. The description compensates fully, even covering nested condition structures, assertions, citations, and retrieval_scope.
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 description opens with 'Create or replace a domain's rule set from YAML (self-serve rule authoring).' This is a specific verb+resource statement that clearly distinguishes it from sibling tools like list_rules and decide. The 'replace' aspect also sets it apart from simple creation.
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 clear context: first save claims a domain, demo domains are read-only, and dry_run validates without persisting. It references import_policy_rules for persisting drafts, but does not explicitly contrast with other siblings or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, it discloses that nothing is saved, describes the return payload (validated draft rules, rule→rule edges, overlap warnings, citation fields), and warns to review drafts before persisting. This adds significant behavioral context not captured by the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely informative but well-structured: purpose first, then return details, then critical workflow warning, then parameter docs. Every sentence earns its place with no fluff or repetition.
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?
Given the output schema exists, the description successfully covers all essential contextual aspects: what the output contains, citation tracking, no side effects, and the recommended persistence workflow. It is a complete mental model for an agent to act correctly.
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?
Despite 0% schema coverage, the description defines both parameters: domain ('an owned domain or a new name') and policy_text ('max ~50k characters'). This adds meaningful semantic constraints and context beyond the bare schema property names.
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 description opens with a specific verb and resource: 'Convert a written policy document into DRAFT decision rules.' It clearly distinguishes itself from sibling tools like put_rules (persist) and list_rules (list existing rules) by emphasizing the draft and no-save aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool and what to do next: 'NOTHING IS SAVED: review the drafts... then persist explicitly with put_rules — validate first with dry_run=true.' This provides a concrete workflow and names the exact sibling tool for persistence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ai-rete-rag-mcp MCP server](https://glama.ai/mcp/servers/zaharajabeen13-create/ai-rete-rag-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zaharajabeen13-create/ai-rete-rag-mcp)

Score Badge

Copy to your README.md:

[![ai-rete-rag-mcp MCP server](https://glama.ai/mcp/servers/zaharajabeen13-create/ai-rete-rag-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zaharajabeen13-create/ai-rete-rag-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zaharajabeen13-create/ai-rete-rag-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server