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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the description does not need to restate safety. It adds two genuinely new facts: the required `payments:read` scope and the fact that user-written text arrives in `untrusted_fields` and must be treated as display-only data, which is important prompt-injection context. Missing only error/not-found behavior for an unknown or foreign payment_id.

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?

Two short sentences, front-loaded with the purpose and then the access and safety constraints. The first sentence duplicates the title nearly verbatim, which is a small amount of waste, but nothing else is padded.

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?

For a simple single-parameter read with rich annotations and no output schema, the description covers the key non-obvious concerns (auth scope, untrusted text). It is still thin on the one input that matters — the identifier — and does not say what happens if the payment does not exist or belongs to someone else.

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 single required parameter `payment_id` is documented nowhere. The description says nothing about its format (opaque ID vs. prefixed string), where to obtain it, or whether it can reference a payment the caller did not make — a real ambiguity given the 'I made' framing.

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?

States a specific verb ('Get') and resource ('a payment I made'), and the phrase 'I made' implicitly separates it from the sibling get_received_payment. It does not explicitly name that sibling or list_payments, so the differentiation is inferred 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?

Usage is only implied: fetch a single payment the caller initiated. There is no explicit guidance on when to use this instead of list_payments, get_received_payment, get_transfer, or get_payout_summary, all of which sit in the same money-related cluster.

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