Skip to main content
Glama

drag

Drag an element onto another element

Instructions

Drag an element onto another element

Input Schema

NameRequiredDescriptionDefault
pageIdYesTargets a specific page by ID.
to_uidYesThe uid of the element to drop into
from_uidYesThe uid of the element to drag
includeSnapshotNoWhether to include a snapshot in the response. Default is false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • changedInput schema / additionalProperties
      Previous value: -{}New value: +false
  2. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations only declare readOnlyHint=false, so the description carries the burden of explaining the mutation, yet it says nothing about how the drag is performed (native HTML5 drag events vs. synthesized mouse move sequences), what side effects occur, or what happens if the drop target rejects the element. With only one annotation bit and a very terse sentence, this is a significant disclosure gap for an interaction tool prone to silent failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero waste. It is concise without being a tautology, though the brevity borders on under-specification for a browser interaction tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Four parameters, a mutation annotation only, and no output schema; the description does not cover viewport/visibility requirements, drag-mechanism caveats, or result expectations. An agent could invoke it but has little basis for predicting or diagnosing behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and every parameter (pageId, from_uid, to_uid, includeSnapshot) is documented in the schema itself. The description adds no meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear specific verb ('Drag') plus resource ('an element onto another element'), so the agent knows exactly what action is performed. It does not differentiate itself from nearby siblings such as click, hover, or fill, but the drag semantics are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this over click/hover/fill, and no prerequisites such as elements needing to be visible or dragged into the viewport first. Nothing says when drag will fail or what alternative to use instead.

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