browser_drag

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

With no annotations, the description carries the load and does well: it discloses a known limitation (HTML5 drag may not respond), the return behavior (updated page snapshot), and a security caveat about untrusted page content. It does not cover permissions or failure/rollback semantics, so not a 5.

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 dense sentences, front-loaded with the action, followed by the caveat and the return/security note. No 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?

For an 8-parameter tool with no output schema and no annotations, the description covers action, return value, and security context. The main gap is not clarifying how the coordinate parameters interact with the ref parameters, but overall it is sufficient to invoke correctly.

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 only 25% on 8 parameters, so the description should compensate more than it does. 'One element/point, move to another' hints at the fromRef/toRef vs fromX/fromY duality, but the coordinate-vs-reference relationship is never made explicit.

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 precise verb sequence (press, move, release) on a clear resource, and names concrete use cases (sliders, sortable lists, canvas) that separate it from browser_click and browser_hover. An agent can tell immediately what this does.

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 parenthetical use cases and the warning that 'Native HTML5 drag-and-drop may not respond' give real context for when this tool applies versus a plain click or hover. It stops short of explicitly naming an alternative tool or stating exclusion conditions, so not a 5.

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