browser_hover_element

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

Strong disclosure given no annotations: explains the technical implementation ('Dispatches a realistic pointer/mouse event sequence matching real browser behavior'), lists specific event types triggered, and critically notes the '[Disabled]' status. Lacks only error behavior (what happens if selector not found) to be a 5.

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?

Four sentences with zero waste: 1) Status + core action, 2) Functional outcome, 3) Technical mechanism, 4) Usage recommendation. Information-dense and logically sequenced from what/why to how/then.

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?

Appropriate for a 2-parameter interaction tool with no output schema. Covers the essential behavioral contract (events dispatched, UI changes) and operational status. Absence of return value documentation is acceptable for a side-effect-focused browser action, though noting success/failure indicators would elevate to 5.

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% (both tabId and selector fully described), establishing baseline 3. Description implies parameter usage ('hover over an element') but adds no additional semantic context beyond the schema (e.g., no CSS selector examples or tab lifecycle notes). Adequate but not additive.

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?

Excellent specificity: states the exact action (hover), target (element), mechanism (trigger hover events like mouseenter/mouseover), and outcome (reveals dropdowns/tooltips). The '[Disabled]' prefix immediately signals availability status. Clearly distinguishes from browser_click_element by emphasizing hover-specific UI revelation rather than activation.

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?

Provides clear workflow guidance ('Suggest taking a screenshot after hovering') and identifies specific use cases (dropdown menus, tooltips, hidden UI). Implicitly distinguishes from click operations. Could be improved by explicitly contrasting with browser_click_element for cases where either might apply.

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