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

Annotations already declare readOnlyHint=true, idempotentHint=true and non-destructive, so the safety profile is covered. The description adds real context beyond them: it returns guidance text rather than performing the send, it opens nothing on its own, and the actual write must go through the cotlet_browser_* tools. The trailing API-availability note adds background but no behavioral information the agent needs to invoke the tool.

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 operational content is front-loaded in the first two clauses: what it returns and that it opens nothing. However, the third sentence about Fatture in Cloud's REST API and lack of an MCP server is irrelevant to invoking this tool and consumes roughly a third of the text, plus a stale 'checked 14 Oct 2026' date that adds no value.

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 zero parameters, no output schema and a full annotation set, the description covers what an agent needs: that the result is a screen-level walkthrough and that execution happens elsewhere via browser tools. A brief statement of the return shape (text guide vs. structured steps) or of any precondition like an open, authenticated Cloud Browser session would close the remaining gap.

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, so there is no schema semantics to compensate for; the baseline for a no-param tool applies. Nothing in the description implies hidden inputs the agent should supply.

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 resource and action (sending e-invoices to SDI in Fatture in Cloud) and then clarifies the real behavior: it returns a step-by-step walkthrough rather than executing anything. That clarification is what rescues an otherwise misleading opening sentence ('Send to SDI...'), which reads like a mutation. It distinguishes itself from the cotlet_browser_* siblings by naming them as the execution path, but does not distinguish itself from cotlet_app_guide, which could plausibly overlap.

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 usage sequence: call this to get screens/buttons/fields, then perform the action with cotlet_browser_* tools in the user's Cloud Browser. It also implicitly rules out direct execution ('opens nothing by itself'). It stops short of explicit exclusions, e.g. when to prefer cotlet_app_guide, and does not state preconditions such as the user having an authenticated browser session.

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