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

Annotations already mark this read-only, idempotent, closed-world and non-destructive, so the safety bar is low; the description nevertheless adds the non-obvious detail that it 'opens nothing by itself' and returns screens, buttons and fields as instructions. That is genuine behavioral value beyond the annotations. The closing sentence about Autotask's REST API and Kaseya's alpha MCP server is context rather than behavior disclosure.

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, establishing scope, return format and the follow-up browser step. The third sentence about the official API and Kaseya's alpha MCP server does not help an agent decide to call or invoke this tool and reads as filler.

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 full annotation coverage, the description only needs to explain what comes back and what to do next—both of which it does (step-by-step screens/buttons/fields, then browser tools). It is complete enough to call correctly, with only the missing sibling differentiation as a 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 the baseline is 4. There is nothing parameter-related the description could add, and it correctly implies no input is required.

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?

States a specific verb and resource ('Find company in the user's own Autotask account') and scopes it to the user's own tenant. It also qualifies the operation by explaining the tool returns step-by-step guidance rather than data, which reduces the ambiguity created by the 'find' verb, though the name/behavior mismatch costs a point.

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?

The description supplies a workflow—call this, then perform the action with the cotlet_browser_* tools in the Autotask Cloud Browser—which implies when to use it. It never states when not to use it or how it differs from siblings like cotlet_browser_find or the ticket-oriented autotask_* tools, so selection still requires inference.

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