veilbrowser

veil_drag

Drag UI elements that require real mouse events (not HTML5 drag). Specify source via ref or coordinates, and destination coordinates.

Instructions

Drag from one point to another — real mousedown -> mousemove(button held) -> mouseup, not the HTML5 drag events. Use this for 'drag a card onto a canvas' UIs (site/page builders, Kanban boards, sortable lists) whose drop targets don't respond to a plain click. Pass ref for the source if it has a snapshot ref, otherwise fromX/fromY; the destination is almost always a plain div with no ref, so give toX/toY read off a veil_screenshot.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "toX": "<toX>",
      "toY": "<toY>"
    },
    "name": "veil_drag"
  }
}

Input Schema

Name	Required	Description	Default
`ref`	No
`toX`	Yes
`toY`	Yes
`fromX`	No
`fromY`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.5.0Jul 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool simulates real mouse events (mousedown->mousemove->mouseup) rather than HTML5 drag events, and explains parameter choices (ref vs fromX/Y). It does not mention timing, error behavior, or response, but covers core behavioral traits well.

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?

Three sentences, front-loaded with main action and key distinction. The last sentence is slightly wordy but packs parameter guidance. Every sentence adds value; no redundancy.

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

Completeness3/5

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

Given 5 parameters, 2 required, no output schema, and no annotations, the description covers purpose, usage, and parameter mapping. However, it lacks return value/behavior, error cases (e.g., conflicting ref and coordinates), and assumes domain knowledge (snapshot ref). It is adequate but not fully self-contained.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It explains the meaning of ref (snapshot ref), fromX/fromY (alternative source coordinates), and toX/toY (destination from screenshot). It adds context missing from schema, though assumes knowledge of 'snapshot ref'. Overall, it provides significant value beyond parameter names.

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

Purpose5/5

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

The description clearly states the tool drags from one point to another using real mouse events (mousedown, mousemove, mouseup), distinguishing it from HTML5 drag events and plain click. It provides concrete use cases (site/page builders, Kanban boards, sortable lists) and specifies parameter logic. This makes the purpose highly specific and distinct from siblings like veil_click.

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

Usage Guidelines4/5

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

The description explains when to use: for drag interactions in UIs where drop targets don't respond to click. It gives examples but does not explicitly list when not to use or name alternative tools beyond implied click. The guidance is clear but could be more explicit about exclusions.

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