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

Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety burden is light. The description still earns credit by disclosing the non-obvious behavior that the tool returns human-style UI instructions (screens, buttons, fields) and performs no action itself. It stops short of describing the shape or length of the returned guidance, which matters given there is no output schema.

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 core handoff (get steps here, execute with browser tools) is front-loaded and clear, but the text is padded with marketing framing ("from ChatGPT, Claude or any AI agent") and an ungrammatical fragment about the official API. Trimming those would sharpen it without losing information.

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 zero-parameter guidance tool with no output schema, the description should clarify what the returned procedure looks like and what state (account selected, Cloud Browser open) is needed before the browser step. It hints at the content of the steps but leaves prerequisites and the handoff mechanics underspecified.

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 no parameters and the schema is fully described, so there is nothing further a description could meaningfully add here. Baseline of 4 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?

The description names a specific verb and resource (export ledger in the user's own e-Boekhouden account) and, unusually, clarifies that the tool's actual output is a step-by-step procedure rather than the exported data. It also distinguishes itself from the cotlet_browser_* siblings by naming them as the execution layer. The trailing fragment "e-Boekhouden's official API: Yes" adds noise and slightly blurs whether the tool itself performs an API export.

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 two-phase workflow: call this first to get instructions, then act with the cotlet_browser_* tools in the e-Boekhouden Cloud Browser. It also explicitly rules out side effects ("opens nothing by itself"), which is useful for deciding whether it is safe to call speculatively. What is missing is disambiguation from other e_boekhouden_* or cotlet_app_guide tools for overlapping guidance needs.

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