verify_receipt
Reads an on-chain settlement and returns a signed attestation.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| quote | Yes | ||
| tx_hash | Yes |
Reads an on-chain settlement and returns a signed attestation.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| quote | Yes | ||
| tx_hash | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Reads' implies a read-only operation, which is a useful safety signal, and 'returns a signed attestation' indicates the output behavior. However, it does not disclose failure modes, permissions, or the nature/validity guarantees of the attestation, so transparency is only partial.
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?
The description is one compact sentence with no filler and front-loads the action. It is appropriately concise for the minimal information it conveys, though the brevity contributes to the overall incompleteness.
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?
There is no output schema, no annotations, and a required nested quote object with an ambiguous schema. The description does not explain the input structure, output shape, or failure behavior, so an agent cannot reliably construct a correct call or interpret the result.
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%, and the description does not explain any of the three required parameters (chain, tx_hash, quote). The phrase 'on-chain settlement' vaguely maps to chain and tx_hash, but quote is entirely undefined, leaving an agent without the information needed to fill the nested quote object correctly.
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 uses a specific verb 'Reads' and a clear resource ('an on-chain settlement') plus an outcome ('returns a signed attestation'), so an agent understands the core function. It does not explicitly contrast with siblings like get_quote or get_index, but the distinct resource and output make the purpose reasonably clear.
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 guidance on when to use this tool versus alternatives such as get_quote or get_index. It does not state prerequisites, workflow position, or conditions that would make verify_receipt the appropriate choice, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.