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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, and the description's 'Read-only' restates that. Its real value is the pre-condition: it errors for accounts that haven't finished onboarding in the web app, a failure mode not captured by any annotation, plus the note that these values are the defaults applied to invoice creation.

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 what is returned, then the use cases, then the read-only and error caveats. The long parenthetical field list is dense but each item is a concrete datum the agent may need to reference; the only mild waste is repeating 'Read-only' where annotations already say so.

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?

No output schema exists, so the description carries the burden of describing return contents, and it does so field-by-field, plus documents the onboarding error. An agent knows what it will get, why to call it, and how it can fail.

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 tool takes zero parameters, which is the baseline-4 case: there is nothing for the description to disambiguate, and the empty input schema is unambiguous.

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 (Returns) and resource (the account's sender settings), then enumerates the domains covered: company/address, tax IDs, bank details, invoice defaults, reminders, DATEV numbers. This clearly separates it from update_sender_settings and from invoice-level siblings like get_invoice, which read per-document data.

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 three concrete reasons to call it: learn the date format accepted by invoiceDate/dueDate in create_invoice and create_invoice_from_previous, inspect defaults applied to omitted fields, and show the user what appears on invoices. Ties directly to named siblings. Missing only an explicit negative case, e.g. 'use update_sender_settings to change these values.'

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