Skip to main content
Glama

Decide Runtime

Check a proposed action against supplied rules

decide_prepaid_evaluate
Idempotent

Evaluate supplied Rulebook rules and facts; save an immutable account-owned decision. yes means the supplied rules allow, no means they block, review needs human review. Use decide_prepaid_get_record for its summary and decide_prepaid_export_record for signed evidence. Require approved policy and trusted facts. One paid unit per completed record; identical operation_id/input retries add no debit. Pending has no record: read or retry unchanged. Changed input under the same ID is OPERATION_CONFLICT; never replace IDs to clear pending work. Requires owner-approved scoped access. Export before 90-day expiry; on RECORD_EXPIRED stop, never change IDs to bypass it. On HTTP 429 stop automatic retries and honor Retry-After; without it, ask the owner to inspect the lifetime limit. No result grants external-action authority. No credit purchases, limit changes or execution.

Input Schema

NameRequiredDescriptionDefault
inputYesComplete Rulebook v1 request with policy-owner-approved rules and trusted facts. Preserve all fields for retries, summary reads and exports. Examples show structure only; Decide does not verify policy approval or real-world facts.
operation_idYesCaller-generated proposal ID: 1-160 ASCII letters, digits, underscore or hyphen. Preserve it with the complete input before calling. Reuse for identical-input retries; changed input returns OPERATION_CONFLICT. Choose a new ID only for a genuinely new proposal, never to bypass a pending outcome or limit.

Output Schema

NameRequiredDescriptionDefault
codeNo
recordNo
statusNo
accountNoCurrent prepaid credit and owner/client spending limits. Available wallet credit is not the effective spending allowance.
messageNo
environmentNo
operation_idNo
billing_enabledYes
execution_enabledYes
price_per_record_microusdNoPrice per completed record; 1 USD = 1,000,000 micro-USD. Reads and identical retries add no record debit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "input": {
      +      "context": {
      +        "inputs": {
      +          "proposed_amount_minor": 9000
      +        }
      +      },
      +      "mode": "rulebook",
      +      "question": "Illustrative request only; not approved policy or authority to spend or execute.",
      +      "rulebook": {
      +        "default_outcome": {
      +          "action": "record_only",
      +          "decision": "review",
      +          "reason_code": "OUTSIDE_EXAMPLE_LIMIT",
      +          "verdict": "REVIEW"
      +        },
      +        "rulebook_id": "example_amount_limit",
      +        "rules": [
      +          {
      +            "condition": {
      +              "field": "proposed_amount_minor",
      +              "operator": "lte",
      +              "value": 10000
      +            },
      +            "outcome": {
      +              "action": "record_only",
      +              "decision": "yes",
      +              "reason_code": "WITHIN_EXAMPLE_LIMIT",
      +              "verdict": "ALLOW"
      +            },
      +            "priority": 1,
      +            "rule_id": "within_limit"
      +          }
      +        ],
      +        "schema_version": "rulebook_v1",
      +        "version": "1"
      +      }
      +    },
      +    "operation_id": "example_record_001"
      +  }
      +]
    • changedInput schema / properties / input / description
      Previous value: -"A bounded Rulebook v1 request. Use facts and rules explicitly supplied by the developer; never invent action authority. The server also enforces size and reserved-field limits."New value: +"Complete Rulebook v1 request with policy-owner-approved rules and trusted facts. Preserve all fields for retries, summary reads and exports. Examples show structure only; Decide does not verify policy approval or real-world facts."
    • changedInput schema / properties / operation_id / description
      Previous value: -"Your stable proposal/request ID. Preserve it and the exact input for retries and reading."New value: +"Caller-generated proposal ID: 1-160 ASCII letters, digits, underscore or hyphen. Preserve it with the complete input before calling. Reuse for identical-input retries; changed input returns OPERATION_CONFLICT. Choose a new ID only for a genuinely new proposal, never to bypass a pending outcome or limit."
    • addedOutput schema / properties / price_per_record_microusd / description
      Added value: +"Price per completed record; 1 USD = 1,000,000 micro-USD. Reads and identical retries add no record debit."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover readOnly/idempotent/destructive flags; the description goes far beyond them, disclosing billing ('one paid unit per completed record', no debit on identical retry), conflict behavior (OPERATION_CONFLICT on changed input), pending-state semantics, a 90-day expiry with RECORD_EXPIRED, and 429/Retry-After guidance. It also bounds authority ('No result grants external-action authority').

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?

Dense and front-loaded: purpose and outcome vocabulary come first, then routing, then edge-case behavior. Every sentence carries operational content, though the run of error/limit clauses in the back half reads as a compressed list rather than fully structured guidance.

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 two-param, deeply nested evaluator with an output schema already handling return values, the description covers the gaps an agent needs: prerequisites, idempotency and billing, conflict/expiry/rate-limit recovery, and explicit scope exclusions. Nothing material is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that operation_id must be preserved with the complete input, that reuse is only valid for identical-input retries, and that a new ID must never be used to bypass pending work or limits. It also glosses the verdict vocabulary used in outcomes.

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?

States a specific verb and resource ('Evaluate supplied Rulebook rules and facts; save an immutable account-owned decision') and immediately defines the yes/no/review outcome semantics. It explicitly distinguishes itself from both siblings by naming decide_prepaid_get_record and decide_prepaid_export_record, so an agent can route without opening any schema.

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?

Names the alternatives and the condition that selects each ('get_record for its summary', 'export_record for signed evidence'), plus prerequisites ('Require approved policy and trusted facts'). It also gives operational when-to guidance for retries, pending state, expiry, and 429 handling, including explicit when-not actions ('never replace IDs', 'stop automatic retries').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources