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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description is consistent with them ('opens nothing by itself'). It adds useful behavior beyond the annotations: the return value is a step-by-step screen/button/field guide, nothing is opened automatically, and the official REST API cannot simply be enabled. What it does not say is whether a Cloud Browser session must already exist before calling.

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?

Only three sentences, but the most important one (what the tool actually returns) is buried in second position behind a misleading opener. The closing sentence about the Procountor REST API is long and tangential, and the 'checked 14 Oct 2026' date adds noise rather than clarity.

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 no parameters and no output schema, the description carries most of the burden and does cover the essentials: what comes back (a step-by-step guide), that nothing is executed, and which tools perform the actual work. Missing is any statement about prerequisites (an open Cloud Browser / logged-in session) needed before the returned steps can be executed.

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 with an empty, fully closed schema, so there is nothing for the description to disambiguate. The baseline of 4 applies; the description's silence on inputs is appropriate here.

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 opening sentence ('Create invoice in the user's own Procountor account') describes the overall task, not the tool — the tool itself only returns instructions. The real function is revealed only in the second sentence ('Returns how to do it in Procountor step by step ... and opens nothing by itself'). An agent that stops reading after sentence one will expect a creation tool, so the purpose is stated but badly ordered and partly contradicted by the name and title.

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 does route the agent forward ('then do it with the cotlet_browser_* tools in the user's Procountor Cloud Browser'), which is genuine usage guidance. However it never says when NOT to use it, nor distinguishes it from siblings like procountor_create_receipt, procountor_add_partner or cotlet_app_guide. The API aside explains why the browser route is used but reads as justification rather than guidance.

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