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

Annotations already declare readOnlyHint and destructiveHint=false, but the description adds genuinely new behavioral facts: the tool 'opens nothing by itself' and produces human-readable steps covering screens, buttons, and fields. It also explains why the official Meevo Public API is not a shortcut (credential request form, vendor outreach). The odd future-dated '(checked 11 Oct 2026)' stamp is noise, but the disclosure value is real.

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 essential facts are present but not front-loaded: the key disclosure that the tool returns instructions only arrives mid-sentence, buried in a comma splice after an action-sounding opener. The final sentence about the Meevo Public API and a verification date is tangential and verbose relative to a zero-parameter guidance 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?

With no parameters, no output schema, and read-only annotations, the description covers what an agent needs: what it returns (step-by-step screens, buttons, fields), that it performs no action, and which tools carry out the actual work. The API caveat is extra rather than necessary, but nothing essential about invoking this tool is missing.

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 per the baseline there is nothing parameter-wise for the description to explain. It does imply the lookup scope is 'the user's own Meevo account,' which is the only scoping information an agent could need 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 description identifies the resource (client lookup in the user's Meevo account) and, crucially, clarifies that the tool itself only returns step-by-step instructions rather than performing the lookup. The opening phrasing 'Find client' reads as an action until the third clause corrects it, so the agent must read past the first clause to understand what actually happens. It is distinguishable from the cotlet_browser_* executers, which it explicitly hands off to.

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 workflow: call this to get screens/buttons/fields, then execute 'with the cotlet_browser_* tools in the user's Meevo Cloud Browser.' However, it never states when NOT to use it, how it relates to guidance siblings like cotlet_app_guide or cotlet_browser_find, or whether it should be skipped when a direct browser flow would suffice. Usage is implied by the hand-off sentence rather than explicitly scoped.

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