Send a key or keyboard shortcut such as Enter, Escape, or Control+A to the active browser tab, optionally returning a fresh snapshot so you can verify the result.
Press a key or shortcut in the active tab, e.g. Enter, Escape, ArrowDown, Control+A.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| snapshot | No | Return a fresh snapshot after the action. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether an element must be focused first, whether the press is dispatched to the active tab's focused element, or what happens on failure. The 'active tab' phrase gives only minimal scoping context.
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 efficient sentence with the core scope front-loaded and examples appended. Nothing is wasted, though it is quite thin for a tool with no annotation coverage.
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 an input-action tool with zero annotations and no output schema, the description omits focus requirements, target element resolution, and error behavior. The absence of an output schema means return values needn't be explained, but the behavioral gaps remain.
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?
'snapshot' is documented in the schema, but 'key' has no schema description; the description supplies useful example values (Enter, Escape, ArrowDown, Control+A) that compensate partially. At 50% schema coverage the description adds value but does not fully describe key syntax or modifier combinations.
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 ('Press') and resource ('key or shortcut in the active tab'), with concrete examples (Enter, Escape, ArrowDown, Control+A). It implicitly distinguishes itself from 'type' (text entry) and 'click', though it never names those siblings 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?
No statement of when to use this versus the very similar 'type' tool, nor any prerequisites about focus or which element receives the event. Only the examples hint at intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.