Skip to main content
Glama

Save rules

put_rules
Destructive

Create or replace a domain's rule set from YAML, validating rules before saving and claiming new domains for your account. Set dry_run=true to validate without persisting.

Instructions

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 — 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.3

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag a destructive write, and the description goes well beyond them: domain claiming and plan limits, demo-copy semantics, pre-save validation, dry_run behavior, rejected produce/consume cycles, response contents (ok/errors, parsed rules, overlap warnings), and a warning that dropping `citation` silently loses the policy link.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and every paragraph adds real information for a YAML-authoring tool, but three full YAML examples make it long; the citation example is valuable while the second tree-form example is somewhat verbose for what it teaches.

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 complex, destructive, 0%-coverage schema with an output schema present, the description covers everything an agent needs: YAML grammar, validation/dry-run path, cycle rejection, domain claiming, and the import_policy_rules citation handoff.

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 coverage is 0%, so the description must carry the load and does: `domain` is 'an owned domain, or a new name to claim', `dry_run` is 'validate only, without saving', and `rules_yaml` is documented in depth with flat/tree forms, conditions-vs-when exclusivity, and `not` semantics.

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?

Opens with a specific verb and resource: 'Create or replace a domain's rule set from YAML.' It clearly distinguishes itself from siblings like list_rules, get_rule_source, and import_policy_rules by describing authoring/persistence rather than reading or draft import.

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?

Gives concrete context: first save to a new domain claims it (plan limits apply), saving to a demo domain creates a private copy, and dry_run validates without persisting. It also names the import_policy_rules handoff, though it never states explicitly when another tool should be preferred over this one.

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