Simulates a pointer hover over a specified webpage element to reveal hover-triggered menus, tooltips, or other UI.
鼠标悬停到元素上(触发悬浮菜单/tooltip)。
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": "browser_hover"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | ||
| selector | No | ||
| timeoutMs | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full behavioral burden and only discloses the hover effect. It does not say whether the call waits for the element, whether it scrolls into view, what happens if the element is missing, or whether the call itself can change page state (opening a menu).
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 short sentence with the action front-loaded and the effect in a parenthetical; nothing is wasted. Its brevity is efficient, though it borders on under-specification for a three-parameter interaction tool.
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?
No annotations, no output schema, and three undocumented parameters mean the description must do more than it does. An agent can guess the intent but cannot tell how to target the element or what state the page will be in afterward.
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 0% across three parameters (ref, selector, timeoutMs), and the description says nothing about them beyond the generic notion of an 'element'. The critical question of whether to pass ref or selector — and that all parameters are optional — is left entirely unresolved.
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?
States a specific verb (hover) acting on a specific resource (element) and adds the observable effect (triggering hover menus/tooltips). It does not explicitly contrast itself with siblings like browser_click, so an agent must infer the difference from the verb alone.
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?
The parenthetical '触发悬浮菜单/tooltip' implies when the tool is appropriate (revealing hover-only UI before acting), but there is no guidance on when not to use it, no prerequisites such as needing a prior snapshot, and no mention of the sibling tools that often follow a hover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.