get_receipt

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

With no annotations, the description carries the full burden: it discloses that receipts are audit-log anchored and that finished intents are the ones with anchored receipts, which hints at availability constraints. It does not state side-effect profile, permission requirements, or what happens when the intent is unknown or unfinalized.

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

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

One front-loaded sentence led by the resource identity, followed by an enumerated list of contents. Dense but no filler; the comma-separated inventory is slightly hard to scan but every element is substantive.

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

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

An output schema exists, so return-field documentation is not strictly required, yet the description spends most of its length on receipt contents rather than on how to call the tool correctly. It lacks the key operational detail of where intent_id comes from and how unfinalized intents behave.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single intent_id parameter, so the description must compensate. It establishes that an intent has an execution receipt and can be audit-anchored, but never explains what an intent_id is, where to obtain it (e.g., from submit_order), or its format.

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

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

The description names a specific resource (the execution receipt of an intent) and enumerates its contents: child orders and fills with venue ids, exchange and builder fees, cost vs arrival mid, self-checks, and a sha256 receipt_hash. That post-trade detail distinguishes it from siblings like order_status or approval_status, though the retrieval verb is only implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no mention of alternatives (e.g., order_status for live state), and no prerequisites. The only contextual hint is that a finished intent's receipt is anchored in the audit log, which hints at post-execution use but does not state it as a selection rule.

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