Skip to main content
Glama

Press key

press_key
Destructive

Press a named key with optional modifiers in the focused app to trigger shortcuts or navigate; use text typing tools for literal input.

Instructions

Press one named key, optionally with modifiers held, e.g. key='s' modifiers=['cmd'] to save or key='return' to submit. Use it for shortcuts and navigation keys; use type_text for literal text. Never use it for a Chrome tab the agent works in: it goes to whichever Chrome window is in front, which can be the user's; use browser_press_key, browser_type or browser_fill there. The key goes to the app you are working in (the one you last clicked or focused); on macOS and Windows the user can keep typing elsewhere meanwhile, so call activate_app only when nothing has targeted the app yet. Shortcuts can close windows or delete content, so confirm the target before pressing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "key": "<key>"
    },
    "name": "press_key"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyYesKey name: a single character such as 's' or '/' (resolved through the current keyboard layout), or a named key: return, tab, escape, space, delete, backspace, forwarddelete, up, down, left, right, home, end, pageup, pagedown, insert, f1 to f20, punctuation names (minus, equal, leftbracket, rightbracket, backslash, semicolon, quote, comma, period, slash, grave), numpad0 to numpad9, numpadadd, numpadsubtract, numpadmultiply, numpaddivide, numpaddecimal, numpadenter
modifiersNoModifier keys to hold while pressing: any of cmd, shift, alt, ctrl, fn. cmd maps to the Windows/Super key off macOS.
state_queryNoWith return_state, list only elements whose role, label or value contains this text, like get_app_state's query
return_stateNoAfter acting, wait for the app to finish reacting (up to 2 s) and append a fresh get_app_state of the app you last read, so you can check the result and pick the next target in the same call. Its ids replace every earlier id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.1
    • changedInput schema / properties / return_state / description
      Previous value: -"After acting, wait briefly for the UI to settle and append a fresh get_app_state of the app you last read, so you can check the result and pick the next target in the same call. Its ids replace every earlier id."New value: +"After acting, wait for the app to finish reacting (up to 2 s) and append a fresh get_app_state of the app you last read, so you can check the result and pick the next target in the same call. Its ids replace every earlier id."
  2. Changed2 schema fields changedv0.5.2
    • addedInput schema / properties / return_state
      Added value: +{
      +  "description": "After acting, wait briefly for the UI to settle and append a fresh get_app_state of the app you last read, so you can check the result and pick the next target in the same call. Its ids replace every earlier id.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / state_query
      Added value: +{
      +  "description": "With return_state, list only elements whose role, label or value contains this text, like get_app_state's query",
      +  "type": "string"
      +}
  3. Changed1 schema field changedv0.4.0
    • changedInput schema / properties / key / description
      Previous value: -"Key name: a single character such as 's', or a named key such as return, tab, escape, space, delete, backspace, up, down, left, right, home, end, pageup, pagedown"New value: +"Key name: a single character such as 's' or '/' (resolved through the current keyboard layout), or a named key: return, tab, escape, space, delete, backspace, forwarddelete, up, down, left, right, home, end, pageup, pagedown, insert, f1 to f20, punctuation names (minus, equal, leftbracket, rightbracket, backslash, semicolon, quote, comma, period, slash, grave), numpad0 to numpad9, numpadadd, numpadsubtract, numpadmultiply, numpaddivide, numpaddecimal, numpadenter"
  4. Changed2 schema fields changedv0.3.1
    • addedInput schema / properties / key / description
      Added value: +"Key name: a single character such as 's', or a named key such as return, tab, escape, space, delete, backspace, up, down, left, right, home, end, pageup, pagedown"
    • changedInput schema / properties / modifiers / description
      Previous value: -"Any of cmd, shift, alt, ctrl, fn. cmd maps to the Windows/Super key off macOS."New value: +"Modifier keys to hold while pressing: any of cmd, shift, alt, ctrl, fn. cmd maps to the Windows/Super key off macOS."
  5. First observedv0.3.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only flag destructiveHint=true and readOnlyHint=false; the description adds the substantive behavior behind that risk: keys go to the last-clicked/focused app, the user can keep typing elsewhere concurrently, and shortcuts may close windows or delete content. It also warns that in browser contexts the keystroke can land in the user's own Chrome window, which is not derivable from any structured field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action, then ordering the highest-stakes caveat (browser targeting) before the softer activate_app note and the destructive-action warning. Every sentence carries a distinct constraint, though the key='s'/modifiers=['cmd'] example partly duplicates the schema's key and modifiers descriptions.

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

Completeness5/5

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

For a four-parameter mutation tool with no output schema, the description covers targeting semantics, cross-app concurrency, correct sibling routing, and the risk of destructive shortcuts. The schema already explains return_state, so the absence of return-value discussion in the description is not a gap.

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

Parameters3/5

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

Schema description coverage is 100%, so the key-name list, modifier set, state_query and return_state semantics are already fully documented in the schema. The description's inline examples illustrate a key/modifier combination but add no syntax or constraint beyond what the schema states, so the baseline 3 applies.

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 ("Press one named key, optionally with modifiers held") and immediately grounds it with concrete examples (key='s' plus modifiers=['cmd'] to save, key='return' to submit). It explicitly distinguishes itself from type_text for literal text and from browser_press_key for browser tabs, so an agent can route correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (shortcuts and navigation keys), when-not-to-use (never for a Chrome tab the agent works in, because input goes to whichever Chrome window is frontmost), and names the concrete alternatives: browser_press_key, browser_type, browser_fill, type_text, and activate_app. The condition for calling activate_app (only when nothing has targeted the app yet) is spelled out rather than implied.

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