Move the mouse pointer to precise screen coordinates on a target browser page using Playwright automation. Enables UI interactions requiring cursor placement at exact positions.
Move mouse to target coordinates via the backend Playwright page.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | Destination X coordinate | |
| y | Yes | Destination Y coordinate | |
| target_id | Yes | Target ID from interceptor_browser_launch |
Changes observed during successful MCP inspections.
v3.5.3Input schema / properties / target_id / descriptionPrevious value: -"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"New value: +"Target ID from interceptor_browser_launch"v3.3.2Input schema / properties / target_id / descriptionPrevious value: -"Browser target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"v2.3.0Input schema / properties / duration_msRemoved value: -{
- "default": 600,
- "description": "Base duration in ms before Fitts scaling (default: 600)",
- "type": "number"
-}Input schema / properties / target_id / descriptionPrevious value: -"Chrome target ID from interceptor_chrome_launch"New value: +"Browser target ID from interceptor_browser_launch"v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the movement happens 'via the backend Playwright page' but does not say whether the movement is humanized/animated, whether it blocks until complete, or what happens on invalid coordinates or a missing browser target.
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?
A single sentence with no filler; the action, object, and destination are all front-loaded. Every word contributes meaningfully.
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 a straightforward pointer-move tool, the description plus fully documented schema is minimally viable. However, it leaves implicit the coordinate space (viewport vs page), the need for a previously launched browser, and any return/error behavior, which would be useful given there is no output schema or annotations.
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%, so x, y, and target_id are already well documented. The description's 'target coordinates' phrase adds no new parameter detail beyond what the schema provides, so the baseline score of 3 is appropriate.
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 uses a specific verb ('move') with a clear object ('mouse') and destination ('target coordinates'), making the action unambiguous. It is easily distinguishable from siblings like humanizer_click, humanizer_type, and humanizer_scroll, which involve different UI interactions.
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?
No guidance is given about when to use this tool versus alternatives such as humanizer_click, which likely also involves mouse movement before clicking. Prerequisites, such as requiring an active Playwright page from interceptor_browser_launch, are not mentioned beyond the schema's target_id reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.