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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is known; the description adds the crucial non-obvious fact that the tool performs no action and opens nothing, only returning screen/button/field instructions. That is real value beyond the structured fields. It does not say what the returned instructions look like in structure or what happens if the user is not logged in to Bokio.

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 behavior an agent most needs (this returns instructions, it does not send) is buried in the second clause after a contradictory imperative lead. The final third is an off-topic essay on Bokio's REST API, price plans, private tokens and OAuth 2.0 registration that has no bearing on invoking this zero-parameter tool.

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 no-param, no-output-schema, read-only guide tool, the essentials are present: it returns step-by-step instructions and the actual work must be done via cotlet_browser_*. Missing is any statement of prerequisites, failure modes, or how the agent should confirm which invoice the returned steps refer to.

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?

Zero parameters with an empty object schema, so there is nothing for the description to disambiguate; baseline is 4. It could still have said that the target invoice is inferred from session/browser state, but no parameter gap exists.

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 first sentence says 'Send invoice in the user's own Bokio account,' which reads as an execution action, but the second sentence reverses that: 'Returns how to do it in Bokio step by step ... and opens nothing by itself.' The real purpose (a knowledge/guide tool) is only revealed after the misleading opening, so an agent skimming the lead could misfire. It does distinguish itself from the cotlet_browser_* executors, but not from bokio_create_invoice or cotlet_app_guide.

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 gives a clear next-step path: use the cotlet_browser_* tools in the user's Bokio Cloud Browser to actually perform the send. However, it never states when to call this versus bokio_create_invoice, bokio_list_unpaid_invoices, or the generic cotlet_app_guide, and gives no preconditions (e.g., an invoice must already exist and be in draft).

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