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

readOnlyHint is already declared by annotations, so the safety profile is covered. The description adds genuinely useful context beyond the structured fields – the template_id/create_invoice linkage and the paging pattern (pass next_offset as offset) – though it omits auth and rate-limit details.

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 tight sentences, front-loaded with the purpose and followed by filters and paging. Nothing is wasted and the endpoint is noted compactly.

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?

With no output schema and a readOnly annotation, the description does enough: it names the filtering options and states that the key returned value is template_id. Minor gaps remain on exact return shape, but the essential call contract is covered.

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 100%, so the schema already documents all six parameters (name, type, match, active, limit, offset). The description restates the name/type/active filters and pagination mechanics without adding syntax or semantics beyond what the schema provides, so the baseline 3 applies.

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 (List) and resource (invoice templates) and further anchors it by explaining it supplies the template_id consumed by eboekhouden_create_invoice. This clearly separates it from siblings like list_invoices and list_email_templates.

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?

Gives clear context: use it to obtain template_id for create_invoice, and it enumerates the optional filters (name, type, active). It stops short of explicit when-not guidance or alternative routing, but the intended use is unambiguous.

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