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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false; the description is consistent and adds that the tool 'opens nothing by itself', which is the key behavioral fact an agent needs before chaining to browser tools. It also explains why browser automation is required (no official MCP server for Agile CRM) and mentions a per-plan daily API call cap. The API/plan detail is more contextual color than behavior of this specific tool, keeping it from a 5.

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?

Purpose and the read-only caveat are front-loaded, which is good. The closing sentence about Agile CRM's REST API, daily call caps and the Oct 2026 check date is generic context that does not help an agent select or invoke this tool, and it dilutes an otherwise tight definition.

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?

Safety is fully covered by annotations and the description correctly says what is returned (step-by-step instructions), so the essentials are present without an output schema. What is missing is how the deal/milestone are identified and what happens if the named milestone does not exist, leaving the agent to improvise at the handoff to the browser tools.

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?

With zero parameters the baseline is 4, but the description never explains how the deal and target milestone are conveyed to the browser step that follows, which is the obvious question the empty schema raises. The schema (additionalProperties: false, no properties) gives the agent nothing, so a sentence such as 'the deal and milestone are chosen in the browser steps' would have closed the gap. Slightly below baseline for that omission.

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 opens with a specific verb+resource ('Move deal to milestone in the user's own Agile CRM account') and clarifies that the tool does not perform the move itself but returns step-by-step instructions. That distinction is what separates it from the cotlet_browser_* executors. It stops short of 5 because 'milestone' and deal identity are never defined, so the agent can't tell exactly what operation is being described.

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 an explicit workflow: call this tool to get the screens/buttons/fields, then perform the action with cotlet_browser_* tools in the Cloud Browser. The 'opens nothing by itself' clause prevents the agent from assuming the action is already done. It does not state when to prefer this over cotlet_app_guide or what to do if the user lacks Cloud Browser access, so no full when-not guidance.

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