Skip to main content
Glama

A2A Grocery — the agentic hub for retail grocery procurement

Create Order Intent

create_order_intent

Open an order between two agents: an order intent for a cleared item after the gate; the intent carries reason_code + rule_set_version and settles by x402 on a2a-x402.ai.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gtinYes
marketNo
ship_toNo
quantityYes
decision_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, so the write-safety profile is covered. The description usefully adds that the intent 'settles by x402', disclosing a financial settlement side effect not visible in the annotations, but it does not clarify reversibility, auth requirements, or failure behavior.

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?

A single dense sentence that front-loads the core action ('Open an order between two agents'), though the trailing clause about x402 settlement and the stray field names make it read as slightly run-on.

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

Completeness2/5

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

An output schema exists so return values need not be described, but for a five-parameter creation tool with 0% schema coverage the description leaves the required inputs (gtin, quantity, decision_id) entirely unexplained and cites fields that are not parameters.

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% and none of the five parameters (gtin, market, ship_to, quantity, decision_id) are explained in the description. Worse, it references 'reason_code + rule_set_version', which do not map to any actual parameter, so it adds no usable meaning for the real inputs.

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 description opens with a clear verb+resource ('Open an order between two agents') and differentiates itself from siblings by tying the intent to 'a cleared item after the gate', which positions it downstream of gate_transaction. It is somewhat jargon-laden ('order intent', 'a2a-x402.ai') but an agent can tell it creates a new order rather than reading or verifying one.

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?

Usage is only implied: the phrase 'after the gate' signals a precondition relative to gate_transaction, and 'for a cleared item' implies the item must already be cleared. No alternatives are named and no explicit when-not-to-use is given.

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.