cotlet_browser_hoverRests the pointer on an element or a point, to open a hover menu, a tooltip or a preview. Answers the page after it: the elements and text in view, with the same numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Instead of `element`: pixels from the left of the screenshot. | |
| y | No | With `x`: pixels from the top of the screenshot. | |
| element | No | The element's number from the last read or step answer. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world and non-destructive, so the bar is lower; the description still adds real value by disclosing that the call returns the page state afterward ('the elements and text in view, with the same numbers'), which is important since there is no output schema. It does not explain what happens if no target is supplied or whether the pointer moves away.
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?
Two tight sentences with the action first and the return behavior second. The phrase 'with the same numbers' is slightly cryptic but refers back to element numbering, so no sentence is wasted.
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 zero-required-parameter, non-destructive hover tool this is mostly adequate, and the absence of an output schema is partly compensated by the return-value sentence. Gaps remain: no default targeting behavior when no argument is given, and only a vague sketch of what the returned page answer contains.
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 coverage is 100%, so the baseline is 3, and the description adds the element-or-point framing that tells the agent the three parameters form two mutually exclusive targeting modes. It does not address defaults or what happens when all three are omitted, which the schema also leaves open.
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 states a specific verb and target: rests the pointer on an element or a point, and names concrete outcomes (hover menu, tooltip, preview). That is far more informative than the title 'Point at the page' and distinguishes it from cotlet_browser_click by implication (hover, not activate), though no sibling is named explicitly.
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?
Saying it opens hover menus, tooltips or previews implies when to reach for it, but there is no explicit when-not guidance and no pointer to cotlet_browser_click for actual activation. The agent must infer the click-vs-hover boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.