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

Annotations already cover readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is set. The description still adds real context: it 'opens nothing by itself', it returns a UI walkthrough, and the actual state change must be done through the browser tools. The closing note about Trengo having a REST API but no official MCP server is background justification rather than behavioral information.

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 first two sentences are front-loaded and earn their place by correcting the misleading name and routing to the browser tools. The third sentence enumerates Trengo's REST API surface (conversations, messages, contacts, labels, WhatsApp templates, reporting) and a check date, which does not help an agent decide or invoke anything.

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, no-output-schema, read-only guidance tool, the description covers what is returned and what to do next, which is the necessary core. The remaining gap is scope: it does not say whether the returned steps are generic or tied to a conversation the agent must first identify, nor how it relates to cotlet_app_guide.

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 nothing for the description to disambiguate. Baseline 4 applies. One minor consequence of the parameterless design — that the guidance is generic and not scoped to a specific conversation or assignee — goes unstated.

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 makes the real behavior explicit: it returns step-by-step instructions (screens, buttons, fields) for assigning a conversation rather than performing the assignment, and it names the cotlet_browser_* tools as the actors. That correction is valuable because the name alone would lead an agent to expect a mutation. It loses a point because it never distinguishes itself from the sibling cotlet_app_guide, which plausibly offers overlapping how-to content.

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: read the guidance here, then execute with cotlet_browser_* in the user's Trengo Cloud Browser. What is missing is the negative case — when to use cotlet_app_guide instead, or whether this is needed at all if the agent already knows Trengo's UI.

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