hover_index

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It says it hovers an element but doesn't state whether this requires the page to be loaded, whether it triggers events, whether it scrolls into view first, or how errors are handled (e.g., if the index is out of range). For an action tool with zero annotation coverage, the behavioral details are thin.

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?

The description is a single terse line, which is efficient and front-loaded with the core action. No wasted words. However, it's arguably under-specified rather than well-condensed — while brief, it sacrifices essential context for brevity.

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?

As an action tool with 2 params, no annotations, no output schema, and 0% schema coverage, the description must carry substantial load. It explains the core intent but leaves the 'tab' parameter undocumented, doesn't describe preconditions (must call state() first), and offers no error/edge-case context. This is inadequate for a tool that depends on another tool's output.

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%, so the description must compensate for both params (index, tab). It explains index as '第 N 个元素' (Nth element), which partially maps to that param. But 'tab' is never mentioned at all in the description, leaving its semantics unexplained. With 0% coverage, the description should document both params more thoroughly.

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 it hovers the Nth element of a state() list, which gives a specific verb (hover) and resource (state list element). However, it's quite terse and doesn't clarify what 'state()' refers to or how index maps to elements. The purpose is understandable but under-specified relative to siblings like click_index or hover (which likely hover by selector), and it doesn't distinguish itself from those alternatives.

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?

No guidance is given on when to use this vs alternatives. The '悬停 state() 列表的第 N 个元素' implies it operates on a list returned by state(), but there's no explanation of how this differs from the sibling 'hover' tool, what state() is, or what prerequisites must exist (e.g., must state() have been called first, must the tab be active). No exclusions or when-not-to-use context is provided.

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