Skip to main content
Glama
Sign In
bad-ass-mcp

bad-ass-mcp

by HoldMyBeer-gg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

press_key

Inject key presses or shortcuts into a focused element or specific window to navigate dropdowns, dismiss dialogs, and control apps directly.

Instructions

Inject a key press into the focused element or a specific window. key: 'Down', 'Up', 'Left', 'Right', 'Return', 'Escape', 'Tab', 'Home', 'End', 'PageUp', 'PageDown', 'BackSpace', or any single character. Useful for navigating combo box dropdowns, dismissing dialogs, etc.

Combinations: 'Cmd+A', 'Ctrl+Shift+G', 'Alt+F4', 'Cmd+Shift+G'. 'Cmd' is the platform's shortcut key (Command on macOS, Ctrl on Windows/Linux), so 'Cmd+A' selects all everywhere; 'Super'/'Win' is the literal Windows key. Combinations need window_id and use real input, so that window is brought to the front first. On Linux they need X11 or an XWayland app.

Pass window_id. Without it the key goes to whatever app is in front, which is often your own terminal, and still returns ok.

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
keyYes
window_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does unusually well: it discloses that combinations use real input and force the target window to the front, that Linux requires X11/XWayland, and that omitting window_id still returns ok — a genuine silent-failure warning. What it does not disclose is the return payload or whether the call blocks until the key is delivered.

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 one-line purpose, then key vocabulary, then usage, then the window_id caveat — a sensible progression. The multi-line key enumeration is long but every token is load-bearing; only the mid-paragraph placement of the combination constraints slightly interrupts the flow.

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 two-parameter tool with no annotations and no output schema, everything an agent needs to invoke it correctly is present: allowed values, modifier syntax, platform caveats, and the consequence of omitting window_id. Nothing material is missing.

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

Parameters4/5

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

Schema coverage is 0%, so the description must define both parameters, and it largely does: 'key' is enumerated by example (arrows, Return, Escape, Tab, Home/End/PageUp/PageDown, BackSpace, any single char) and the modifier syntax ('Cmd+A', 'Ctrl+Shift+G') is explained with platform semantics for Cmd vs Super/Win. 'window_id' has its omission consequence explained but its format (string handle from list_windows) is left implicit.

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?

"Inject a key press into the focused element or a specific window" is a precise verb+resource statement, and the key list plus the note about single characters ('or any single character') separates it from the text-typing sibling type_text. An agent can pick this over click/type_text 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 concrete when-to-use cases ("navigating combo box dropdowns, dismissing dialogs") and a hard routing rule via "Pass window_id. Without it the key goes to whatever app is in front." It never explicitly names the alternative tool for typing strings, so the boundary with type_text is inferred rather than stated.

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

Deploy Server

Other Tools