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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: it "opens nothing by itself" and its return value is procedural guidance covering screens, buttons and fields. The only gap is that it does not say how much guidance comes back or what happens if the customer does not exist.

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 action and its non-acting nature are front-loaded in the first two sentences, which is the right ordering. The closing sentence about Salonized having no public API, webhooks or MCP server is contextual justification for the browser-based approach, but its dated parenthetical makes it the least load-bearing part of the text. Overall tight with minor drift.

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 guidance tool with no output schema, the description covers the essentials: what it returns, that it performs no side effects, and which tools carry out the actual work. The absence of an output schema means the description reasonably explains the return shape. It is not fully complete only because it does not address failure or not-found behavior.

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, which sets the baseline at 4. However, the description also never explains how the customer to find is conveyed without inputs, leaving a small conceptual gap for an agent wondering where the search term goes. It adds no parameter meaning because there are none to explain, but the omission of that clarification keeps it at 3.

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 uses a specific verb and resource ("Find customer in the user's own Salonized account") and then corrects an important ambiguity: this tool returns step-by-step instructions rather than performing the lookup. That distinction is what an agent needs in order to not mistake it for an action tool. It does not explicitly contrast itself with siblings such as salonized_list_appointments or cotlet_browser_find, so it stops short of a 5.

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 clear downstream workflow: get the instructions here, then execute them with the cotlet_browser_* tools in the Salonized Cloud Browser. What it lacks is when-not-to-use guidance or an explicit alternative for cases where the agent already knows the UI, or where a different salonized_* tool is the better entry point. Usage is implied through the workflow rather than stated as a decision rule.

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