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

Annotations only declare destructive/openWorld/non-idempotent; the description adds substantial context beyond that: the email goes out externally, there is a per-invoice-per-day rate limit, the reminder fee only applies if it was on the invoice and is capped at 60 kr, interest follows invoice terms or the interest act, and the recipient is persisted as the customer e-mail only when save_customer_email=true. It also discloses the response shape and the caveat note about invoices never sent from Kvickd.

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?

Front-loaded with the action and scope, then side effects, constraints, and argument recap; nearly every clause carries operational information. It is a dense single paragraph, so the confirmation requirement and rate limit are slightly buried rather than set apart.

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 destructive, externally visible mutation with no output schema, the description covers side effects, legal/fee limits, idempotency-adjacent rate limiting, the confirmation step, and what the response contains. An agent has everything needed to call it safely.

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?

With only 14% schema description coverage, the description carries the burden well: it explains include_fee, include_interest, and save_customer_email semantics and constraints, and frames 'to' as a recipient to be confirmed. The 'message' parameter is listed but never explained, and invoice_id is only implied, leaving a small gap.

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?

Names a specific verb and resource (send a payment reminder by e-mail) and narrows the scope precisely to an overdue, unpaid customer invoice, listing what the reminder contains (remaining amount, new due date, PDF). It is clearly distinguishable from siblings such as send_customer_invoice or register_customer_payment.

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 explicit preconditions: confirm recipient and fee/interest with the user first, and a hard limit of one reminder per invoice per day. It also constrains when fee and interest may be applied. It does not name alternative tools (e.g. what to use for a non-overdue invoice), so it falls short of a full when/when-not routing statement.

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