Skip to main content
Glama

ai·rete·rag

by com.ai-rete-rag

Save rules

put_rules
Destructive

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYes
dry_runNo
rules_yamlYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even though annotations already mark destructiveHint=true, the description adds rich context: first save claims a domain, plan limits apply, demo domains are read-only, validation occurs before saving, overlap warnings are returned, and produce/consume cycles are rejected. It also discloses the silent citation-drop risk. 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?

Though long, the description is well-structured and front-loaded with the core purpose immediately. The YAML examples, caveats, and Args section all earn their place given the complexity of rule authoring; there is no filler or redundancy.

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 a simple schema but complex YAML payload, the description is exceptionally complete. It covers ownership, validation, dry-run behavior, response contents, YAML forms (flat/tree), assertions, forward chaining, retrieval_scope, citation, and a critical data-loss warning. The output schema exists but the description still usefully summarizes response fields.

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 fully documents each parameter: domain as owned/new domain, rules_yaml as YAML text, dry_run as validate-only. This compensates completely for the empty schema descriptions and adds practical meaning beyond parameter 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 'Create or replace a domain's rule set from YAML (self-serve rule authoring)', which is a specific verb + resource + scope statement. It clearly distinguishes itself from alternatives like import_policy_rules by explicitly referencing that tool's drafts.

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?

The description provides explicit when-to-use context: new domain claims, demo domain read-only restriction, dry-run alternative, and the relationship to import_policy_rules for persisting drafts. It gives clear directives like 'set dry_run=true to validate without persisting' and warns to copy citation fields when persisting drafts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ai·rete·rag toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool serves a clearly distinct purpose: decide executes decisions, rule management tools (get_rule_source, list_rules, put_rules) each address different aspects of rule viewing/editing, import_policy_rules handles policy-to-rule drafting, and document tools handle knowledge base content. No two tools are easily confused.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern, e.g., list_rules, get_usage, put_rules, import_policy_rules. The single-verb 'decide' fits naturally as the core action. There is no mixing of styles or unpredictable naming.

Tool Count5/5

With 8 tools, the server is well-scoped for its purpose of rule-based decisioning with RAG support. Each tool represents a distinct capability in the workflow—policy ingestion, rule authoring, knowledge base management, decision execution, and usage monitoring—without excess.

Completeness4/5

The tool set covers the core lifecycle: ingest policy text, import draft rules, publish rules, list rules/source, and execute decisions. Minor gaps exist such as no explicit delete for documents or rules (though put_rules with empty YAML can effectively clear rules), and domain listing is indirect via list_rules. These are workable omissions.

Resources