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 adds real value beyond them: it 'opens nothing by itself', it returns screen/button/field-level guidance, and a follow-up browser session is required — preventing the false assumption that calling it mutates anything. It stops short of describing the response format or length.

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?

Three sentences, each doing work: what it returns, how to act on it, and why no API path exists. The lead sentence mirrors the name and is mildly misleading before the second sentence corrects it, so the key fact ('opens nothing by itself') would be better front-loaded.

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 annotations covering safety, the definition supplies what an agent needs: the tool is advisory, the next step is the cotlet_browser_* family, and the target is the user's own Milanote Cloud Browser session. It could note whether a browser session must already be open, but the picture is otherwise 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?

The tool takes zero parameters, so the schema carries no semantic burden and the baseline is 4. The description appropriately spends its words on behavior and follow-up workflow instead of inventing parameter detail.

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 states a specific verb (move and edit cards) and resource, then crucially clarifies that the tool actually returns step-by-step instructions rather than performing the action. That correction makes the real function clear, but it never distinguishes itself from siblings like move_card, edit_note, or set_card_color, which sound like they do the same thing directly.

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 workflow pointer ('then do it with the cotlet_browser_* tools in the user's Milanote Cloud Browser'), which implies the usage context: no API exists, so use this to learn the steps and drive the UI. However, it never says when to prefer this over move_card or edit_note, nor when not to use it, leaving the agent to guess among near-identical siblings.

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