Drag and drop page element

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate that. It adds valuable context beyond annotations by mentioning bounded timeout and strict ambiguity errors, which inform error handling. It also clarifies that source and target must be on the same explicitly addressed page, a behavioral constraint not present in annotations. No contradiction with 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?

The description is a concise two-sentence statement that leads with the core action and immediately provides essential scope and behavior details. Every phrase earns its place, with no fluff or redundant information. It front-loads the purpose and adds constraints efficiently.

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?

Given the tool's complexity (drag and drop across frames, multiple locator strategies), the description provides a solid high-level overview: it covers the operation type, page scoping, session binding, timeout behavior, and ambiguity handling. It doesn't mention iframe support or the details of source/target resolution, but those are captured in the schema, and with an output schema present, return values needn't be described. The description is adequately complete for orientation, though a mention of iframe capability would improve completeness.

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 0%, so the description carries full responsibility for parameter explanation, but it only vaguely references 'semantic or CSS-located' elements. It doesn't mention sessionId, pageId, timeoutMs, or the structure of source/target. The schema itself is rich, but the description fails to bridge that gap for an agent that might not parse the JSON schema deeply. This falls short of compensating for the low coverage.

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 clearly states the action: dragging a semantically or CSS-located element onto another, which directly distinguishes it from other browser interaction tools like click, hover, or fill. It also specifies the scope (one explicitly addressed page) and adds useful qualifiers (same page/session, bounded timeout, strict ambiguity errors), making the purpose unambiguous.

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 description conveys when to use this tool (when dragging is required) and sets expectations about resolution (same page/session, timeout, ambiguity). It doesn't explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to infer that this is the drag-and-drop operation among the sibling set.

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