Skip to main content
Glama

Cursor (navigate, move, hover and click)

cursor

Move a visible overlay pointer to an element by ref, selector, text, or coordinates, then click or hover automatically for in-page navigation.

Instructions

Control the visible glowing cursor and execute clicks or hovers. This is the single, primary tool for in-page navigation and clicking. Target an element by ref (preferred), selector, visible text, or x/y coordinates without needing manual coordinates — the cursor will automatically move to the element and click it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cursor"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNoViewport X coordinate (optional fallback if not using ref/selector/text).
yNoViewport Y coordinate.
refNoElement ref from snapshot (e.g. "f0_e4"). Cursor moves to its center automatically.
textNoVisible text or accessible name to match. Cursor moves to its center automatically.
humanNoMove the mouse along a human-like path. Default false.
stepsNoAnimation steps. Default 6.
tabIdNo
actionNo"click" (default): moves cursor to element/coords and clicks it. "move": moves cursor to element/coords and inspects it. "hover": moves and hovers. "hide": removes cursor overlay.click
buttonNoleft
animateNoAnimate cursor movement. Default true.
frameIdNo
timeoutNo
trustedNotrue = real CDP input; false = DOM events.
selectorNoCSS selector to target. Cursor moves to its center automatically.
exactTextNo
modifiersNo
waitUntilNodomcontentloaded
clickCountNo
delayAfterNo
switchToNewTabNo
detectNavigationMsNoHow long to watch for navigation after clicking. Default 700.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. It usefully explains that the cursor auto-moves to the element's center and that coordinates are unnecessary, but it never mentions that clicks can submit forms, trigger navigation, or open new tabs, and it omits the trusted (CDP input) versus synthetic DOM event distinction that materially affects outcomes.

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 short sentences with the identity claim front-loaded and the targeting methods immediately after. The clause "without needing manual coordinates" slightly restates the auto-move behavior, but overall there is very little waste.

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?

For a 21-parameter, zero-required, unannotated interaction tool, the description covers only the targeting path. It says nothing about the action variants (move, hover, show, hide), timing and navigation-wait options, or what happens on failure or timeout, so an agent must read the schema to use most of its capability.

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 only 52%, so the description must compensate, and it does add real value: it establishes a priority order among ref, selector, text, and coordinates and explains why coordinates are unnecessary. It still leaves roughly half the parameters (trusted, waitUntil, modifiers, clickCount, timeout, tabId/frameId) untouched, which is a meaningful gap for a 21-param tool.

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?

States a specific verb and resource: it controls the cursor and executes clicks or hovers, and it names the four targeting methods (ref, selector, text, x/y). It does not explicitly differentiate itself from siblings like drag, select, or type, though "in-page navigation and clicking" narrows the scope considerably.

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?

It positions itself as "the single, primary tool for in-page navigation and clicking," which routes agents away from alternatives, and it explicitly marks ref as the preferred targeting method. It stops short of stating when not to use it (e.g., for typing, dragging, or selecting), leaving that to be inferred from sibling names.

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