Receipts: get receipt by id_by_customer

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description's READ-ONLY banner matches them. Beyond the annotations, it adds the per-customer counter semantics, the endpoint, and the fact that the response contains an array. No contradiction with annotations.

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 text is reasonably compact and front-loads the read-only and single-receipt behavior, but it restates the same idea in the title-like line and in 'Use to fetch a single receipt...' after already saying it. A couple of redundant sentences could be merged without losing content.

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 one-optional-parameter tool with an output schema and strong annotations, the description is nearly complete: it gives the endpoint, the id semantics, the file-return behavior via schema, and how to retrieve the id. The only minor gap is not explicitly stating how id_by_customer is passed in the request, though the endpoint path implies it.

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?

The only schema parameter, get_file, is fully described in the schema with enum-type behavior for e_invoice_type values, so the description need not repeat it. It adds useful context about id_by_customer as a UI counter, but that is path/id context rather than schema parameter detail. Baseline 3 applies because schema coverage is 100%.

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 specific verb 'get' and resource 'single receipt for a specified customer account by id_by_customer', and explicitly distinguishes itself from receipts_list by saying it fetches a single receipt. The endpoint line reinforces exactly what operation is invoked. This is enough for an agent to know what the tool does.

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?

It explicitly says 'Use to fetch a single receipt whose id you already have' and 'To search or page through receipts, use receipts_list.' It also tells the agent how to obtain id_by_customer first via /receipts/get. That is strong when-to-use vs alternative guidance.

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