Skip to main content
Glama

Compare expected versus actual state — $0.001

prepare_state_deviation_purchase
Read-only

Browse the $0.001 primitive catalog. Create a purchase intent and pay only when /market.primitive_entry.paid_execution_enabled is true; otherwise paid execution is unavailable. Prepare a machine-payable x402 request. Check whether an observed state materially differs from an expected state. Compare expected versus actual system state for exact text equality or explicit boolean and configuration polarity mismatch, such as enabled versus disabled. Binary 0/1 when decidable; abstains before billing otherwise. Current deterministic scope: exact normalized text equality returns 0; true/false, yes/no, enabled/disabled, present/absent, required/not required and allowed/not allowed return 1. Other inputs abstain before billing. This is not general language interpretation, diagnosis or a similarity score.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "EXPECTED_STATE": "<EXPECTED_STATE>",
      "OBSERVED_STATE": "<OBSERVED_STATE>"
    },
    "name": "prepare_state_deviation_purchase"
  }
}

Input Schema

NameRequiredDescriptionDefault
EXPECTED_STATEYes
OBSERVED_STATEYes

Output Schema

NameRequiredDescriptionDefault
methodYes
endpointYes
price_usdYes
request_bodyYes
payment_protocolYes
required_headersYes
purchase_intent_methodYes
purchase_intent_endpointYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3/5.0
Behavior1/5

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

The description states the tool will 'Create a purchase intent and pay,' which is a state-changing, monetary action, while the annotations declare readOnlyHint=true (tool does not modify its environment). That is a direct conflict between the description and the structured safety metadata. This is an Annotation Contradiction, so the score is 1 regardless of the otherwise useful billing/abstention details.

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

Conciseness2/5

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

The description opens with irrelevant catalog/billing boilerplate ('Browse the $0.001 primitive catalog… Prepare a machine-payable x402 request') before reaching the actual purpose. The deterministic scope is restated twice ('Binary 0/1 when decidable; abstains before billing otherwise' and the later 'Current deterministic scope' list), so sentences do not all earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the 0/1/abstain return need not be re-explained, and the description does cover decidable scope, abstention, and the paid-execution gate. However, for a tool with 0% parameter description coverage and a billing flow, the description leaves unclear what the actual arguments should look like and what the purchase-intent/payment side effects are, and its payment claims conflict with the read-only annotation.

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?

Schema description coverage is 0% for both required params, so the description must compensate. It partially does, by indicating that the two inputs are text or boolean-like configuration values (true/false, enabled/disabled, present/absent) and that comparison is exact normalized text equality. It still does not define the normalization rules, casing, or accepted value syntax for EXPECTED_STATE/OBSERVED_STATE.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The core purpose is stated with a specific verb and resource: 'Check whether an observed state materially differs from an expected state,' further narrowed to exact text equality and boolean/config polarity mismatch. It also implicitly differentiates from its sibling by stating 'This is not general language interpretation, diagnosis or a similarity score,' which routes interpretation-style work to prepare_interpretation_delta_purchase. The signal is clear, though it is buried under catalog/billing preamble rather than front-loaded.

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 explicit inclusion criteria (decidable exact-equality and polarity cases) and explicit exclusion criteria ('Other inputs abstain before billing,' 'not general language interpretation, diagnosis or a similarity score'). The precondition for paid execution (/market.primitive_entry.paid_execution_enabled must be true) is also stated. It never names the sibling tool directly, so routing is inferred rather than instructed.

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