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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false), so the description's job is to add context, and it does: "Answers the page after it: the elements and text in view, with the same numbers" tells the agent the call returns a fresh page read with stable element numbering, which prevents a redundant cotlet_browser_read follow-up. It does not disclose drag mechanics such as press-move-release timing, whether it waits for animations, or what happens if the drop misses a target, so it is valuable but not complete.

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?

Two sentences, front-loaded with the action and its accepted endpoint forms, then the return behavior. The colon-list of examples does real disambiguating work rather than padding, and there is no redundant restatement of the title or name.

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 correctly covers the return value (elements and text in view with matching numbers), and the destructive/open-world annotations cover risk. For a nested-object, drag-and-drop tool the remaining gaps are edge behavior (invalid drop targets, drag during navigation, whether the page read reflects post-animation state), which are meaningful but secondary.

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 description coverage is 100%, including per-field notes distinguishing element numbers from screenshot pixels and documenting the dialog/dialog_text enum, so the schema carries the parameter burden and baseline 3 applies. The description reinforces that "from" and "to" each accept an element or a point, but adds no syntax, format, or interaction detail beyond what the schema already states.

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?

"Drags from one element or point to another" names a specific verb and both endpoint forms, and the three examples (card between columns, board piece, slider handle) make the operation concrete. Against siblings like cotlet_browser_click, cotlet_browser_hover and cotlet_browser_press, the verb itself carves out a distinct action, so an agent can select it without opening the schema.

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 example scenarios (reordering a card, moving a board piece, sliding a handle) give a clear sense of the situations this tool is for, which is real usage context rather than a bare restatement. It stops short of explicit exclusions or pointing at alternatives such as cotlet_browser_click for a simple press, so it lands at clear-context-without-routing rather than full when/when-not guidance.

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