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

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, which already convey that it is a safe, non-mutating operation. The description adds valuable context by explicitly stating that it does not ingest raw prompts, outputs, credentials, or logs, and that it converts hash-only references. This goes beyond the annotations by clarifying the input constraints and non-ingestion behavior, which is important for an agent to understand. No contradiction.

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 a single, well-structured sentence that conveys the purpose, input scope, and constraints in an efficient manner. It avoids repetition and includes the key differentiator (no ingestion of sensitive data) upfront. It is concise and front-loaded with the action.

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?

The tool is complex with a nested object schema containing many optional fields. The description covers the main purpose and non-ingestion, but it doesn't explain the structure of the output wrapper or how the hashes are combined. An output schema exists, which may carry some of that burden, but the description still leaves ambiguity about the exact inputs required beyond the required fields. For example, it references 'payment context' but doesn't clarify how that maps to payment_context_hash. It is adequate but not exhaustive.

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%, so the description does not compensate for parameter semantics. The description mentions 'tool request, response, schema, authority, and payment context references', which maps to the fields in the schema (request_hash, response_hash, tool_schema_hash, authority_hash, payment_context_hash). However, it does not detail the structure of the tool_evidence object or the meaning of optional fields like verifier_response_hash or identity_reference_hash. Since the schema has a nested object with many properties, the description provides only a high-level overview, not full parameter semantics. The baseline is 3 because the schema itself is rich even without descriptions.

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 clearly states the verb 'Convert' and the resource 'hash-only MCP tool request, response, schema, authority, and payment context references' into a 'portable ProofRelay evidence wrapper'. It also specifies what is not ingested (raw prompts, outputs, credentials, logs), which helps distinguish it from potentially similar tools. However, it does not explicitly differentiate from sibling tools like normalize_payment_proof or adapt_x402_payment_proof, but given the unique wrapper concept, it is adequately 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?

The description implies the tool is used when you have hash-only references and need to create a portable wrapper without ingesting sensitive data. This gives a clear context for when to use it, but it does not explicitly state when not to use it or name alternatives. Sibling names like normalize_payment_proof suggest alternatives but the description doesn't mention them, so there is a minor gap in explicit usage guidance.

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