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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description does add real behavioral context beyond them — "Free, no browser session" tells the agent it consumes no browser state and can be called freely before acting, which is genuinely useful. It does not describe the shape or size of the returned guidance, though, so the addition is modest given the lower bar set by annotations.

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?

Content is front-loaded with the purpose and the call-before-first-step rule, and the trailing action list is concrete. The opening sentence is long and run-on with a heavy colon list, which costs some readability, but no sentence is wasted.

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 output schema, the description carries the burden of describing the return content, and it does enumerate the returned pieces (browser choice, sign-in link, method, screens/menus/actions, notes, dedicated tools). It also handles the unknown-app fallback. What remains unstated is the response format or length and whether results are cached or app-specific, which keeps it just short of complete.

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?

Schema coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description obliquely clarifies the task parameter by listing example actions covered for DusterBook (Create quote, Schedule job, Create invoice, List booking requests, Add customer), but it does not explain how 'task' shapes the returned method or how 'app' matching behaves beyond the catalog note.

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 names a specific resource (guidance for working in a web app via Cotlet's Cloud Browser) and enumerates exactly what it returns: which browser to use, the sign-in link, the step-by-step method, app screens/menus/actions, notes, and the app's dedicated tools. That distinguishes it clearly from the cotlet_browser_* action tools and the dusterbook_* dedicated action tools named in the sibling list.

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?

"Call it before the first browser step in an app" is an explicit when-to-use trigger, and "Works for any web app; one outside Cotlet's catalog gets the general method" sets scope boundaries. It stops short of explicitly saying to prefer dusterbook_create_quote over browser clicking when a dedicated tool exists, so the alternatives relationship is only implied.

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