Skip to main content
Glama
Gwakko

agent-in-browser

by Gwakko
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

hover

Move the real mouse pointer over an element or viewport point without clicking to open menus, tooltips, or lazy content, scroll it into view, and report the element under the pointer.

Instructions

Move the real mouse pointer over an element or a viewport point without clicking, to open hover menus, tooltips or lazy content. The element is scrolled into view and its centre is used. Returns what is being hovered (and warns if another element covers it). Take a snapshot or screenshot afterwards to see what appeared. Give one of ref, selector, match or x+y; use click to press instead.

Input Schema

NameRequiredDescriptionDefault
xNoViewport x in CSS px, used instead of an element.
yNoViewport y in CSS px.
refNoElement ref from the latest snapshot or find, e.g. "e12". Preferred: unambiguous and fastest; stale after navigation.
tabNoTab id from tabs_list. Defaults to the current tab.
matchNoVisible text or accessible name to match (case-insensitive substring), e.g. "Sign up"; use when you have no ref.
selectorNoCSS selector; the first matching element is used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.2
    • changedInput schema / properties / match / description
      Previous value: -"Visible text / accessible name to match (case-insensitive substring)."New value: +"Visible text or accessible name to match (case-insensitive substring), e.g. \"Sign up\"; use when you have no ref."
    • changedInput schema / properties / ref / description
      Previous value: -"Element ref from snapshot/find, e.g. \"e12\". Preferred."New value: +"Element ref from the latest snapshot or find, e.g. \"e12\". Preferred: unambiguous and fastest; stale after navigation."
    • changedInput schema / properties / selector / description
      Previous value: -"CSS selector (first match)."New value: +"CSS selector; the first matching element is used."
    • changedInput schema / properties / x / description
      Previous value: -"Viewport x."New value: +"Viewport x in CSS px, used instead of an element."
    • changedInput schema / properties / y / description
      Previous value: -"Viewport y."New value: +"Viewport y in CSS px."
  2. First observedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Goes well past the thin annotation set (readOnlyHint=false, openWorldHint=true) by disclosing that the element is scrolled into view, that its centre is targeted, that the return value reports what is hovered, and that an occlusion warning is emitted. The "real mouse pointer" phrasing signals this is a genuine input-device event rather than a synthetic DOM dispatch, which matters for triggering CSS/JS hover handlers.

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

Conciseness5/5

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

Five short sentences, front-loaded with what the tool does and why, then mechanics, then the alternate targeting modes and the anti-recommendation. No filler and nothing repeated from the schema.

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

Completeness5/5

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

There is no output schema, and the description compensates by describing the return payload and its warning case. Combined with the follow-up snapshot advice and the pointing-input rules, an agent has everything needed to call this correctly on the first attempt.

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 100%, so the per-parameter docs already carry the baseline burden and the score starts at 3. The description adds the cross-parameter constraint (choose one of ref/selector/match/x+y) and the behavioural note that element coordinates come from a scroll-into-view centre rather than the raw viewport, which is not in the schema.

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?

States a specific verb (move the pointer over) and resource (an element or viewport point) plus the absence of clicking, which sharply separates it from the sibling `click`. The stated purpose (open hover menus, tooltips, lazy content) tells an agent exactly what outcome it buys.

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

Usage Guidelines5/5

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

Explicitly routes away from the tool: "use click to press instead", and gives the follow-up step "Take a snapshot or screenshot afterwards to see what appeared" so the agent does not rely on the return value alone. It also states the selection rule among targeting inputs ("Give one of ref, selector, match or x+y").

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

Deploy Server

Other Tools