OmniSnap MCP

Hover and photograph

hover

Idempotent

Moves a real pointer over an element and captures a screenshot of revealed dropdowns, tooltips, and styling without clicking, so agents can inspect states synthetic events miss.

Instructions

Puts the pointer on an element and returns a screenshot of what that reveals: dropdowns, tooltips, hover styling. These states cannot be reached any other way: a synthetic event fires the page handlers but leaves the CSS untouched, so this uses a real pointer move. Nothing is clicked.

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": "hover"
  }
}

Input Schema

Name	Required	Description	Default
`element`	No	A number from the most recent annotate_interactive on this tab. Easier and safer than retyping a selector.
`selector`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.3Nov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare idempotent, non-destructive, open-world behavior; the description adds real value by disclosing the implementation mechanism (a genuine pointer move rather than a synthetic event) and the fact that the page state is left hovering but unclicked. It stops short of saying how long the hover persists, what happens if the element isn't found, or the screenshot's format.

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?

Three tight sentences, front-loaded with the action and result, then the justification for the mechanism. No filler and nothing repeated from the schema or annotations.

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

Completeness4/5

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

No output schema exists, and the description covers the return value (a screenshot of the revealed state) as well as the core behavioral caveat. It is nearly complete for a two-parameter tool, with the only real gap being the unresolved element/selector choice and failure behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description says nothing about 'element' vs 'selector', yet both are optional (required: 0), so an agent gets no guidance on which to supply, whether they are mutually exclusive, or how conflicts are resolved. With only 50% schema coverage and no parameter discussion in the description, the ambiguity is left unaddressed.

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 and resource ('puts the pointer on an element') plus the observable result ('returns a screenshot of what that reveals: dropdowns, tooltips, hover styling'). It also separates itself from click-style siblings with 'Nothing is clicked.' An agent can identify the tool without opening the schema.

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?

Gives a clear condition for use — reaching hover-only states — and explains why the obvious alternative (synthetic events) is insufficient. It does not name a concrete sibling (e.g. capture_element) as the fallback for static screenshots, so routing is implied rather than explicit.

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