wafeq_invoices_download_retrieve

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

The annotations already establish read-only, idempotent, non-destructive behavior, and the description reinforces this with 'Nothing is modified.' It also adds valuable detail about the response: base64-encoded PDF bytes, size, and content type, which goes beyond structured fields.

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 short and front-loaded with safety and format signals. There is some redundancy ('Download invoice PDF' appears in the title, first line, and endpoint sentence), but it remains compact and scannable.

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 one-parameter, read-only download tool, the description covers everything essential: what it does, how the resource is identified, what the response contains, and that no data is modified. No output schema exists, so the explicit return-format detail is especially valuable.

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 schema only defines a bare string `id` with zero description coverage, but the endpoint path /invoices/{id}/download/ and the phrase 'Download invoice PDF' make it clear that `id` is the invoice identifier. This gives the parameter enough meaning for correct invocation.

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 verb and resource: downloading invoice PDFs, reinforced by the explicit endpoint GET /invoices/{id}/download/. It clearly separates this from other invoice operations and from similar download tools for other document types.

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 conveys a clear purpose: use this endpoint when you need a PDF of a specific invoice. It does not explicitly name alternatives like wafeq_invoices_retrieve for JSON retrieval, nor does it state when not to use it, but the usage context is unambiguous.

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