Skip to main content
Glama
DustinTrap

kvm-pilot

by DustinTrap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

press_key

Destructive

Presses and releases a single key on the managed host's console, such as Enter, Escape, or F2. Use it to submit forms or navigate firmware menus.

Instructions

Press and release one key on the managed host's console. DESTRUCTIVE (HID).

For a single non-text key: Enter to submit, Escape, F2/F12 at POST, arrows and Tab in firmware menus. For a chord use send_shortcut; for words use type_text; for Ctrl+Alt+Del use ctrl_alt_delete (power gate). Nothing echoes back — snapshot after. Same gating as type_text: KVM_PILOT_MCP_ALLOW_HID + per-invocation approval. Returns the typed act outcome (receipt, or the denial reason).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesOne kvmd key code, case-sensitive: Enter, Escape, Tab, F2, ArrowDown, Space, KeyA, Digit1... Not a chord.
confirmNoPer-invocation approval when the client cannot prompt a human: set true to approve this exact call under the operator's standing policy. Leave false when the client supports elicitation (a human is asked). Never pre-set it speculatively; a denial returns outcome=not_confirmed.
profileNoProfile name from ~/.config/kvm-pilot/config.toml selecting which KVM/BMC (and its managed host) this call targets. Omit to use the server's default (KVM_PILOT_PROFILE).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.0
    • addedInput schema / properties / confirm / description
      Added value: +"Per-invocation approval when the client cannot prompt a human: set true to approve this exact call under the operator's standing policy. Leave false when the client supports elicitation (a human is asked). Never pre-set it speculatively; a denial returns outcome=not_confirmed."
    • addedInput schema / properties / key / description
      Added value: +"One kvmd key code, case-sensitive: Enter, Escape, Tab, F2, ArrowDown, Space, KeyA, Digit1... Not a chord."
    • addedInput schema / properties / profile / description
      Added value: +"Profile name from ~/.config/kvm-pilot/config.toml selecting which KVM/BMC (and its managed host) this call targets. Omit to use the server's default (KVM_PILOT_PROFILE)."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive/non-idempotent, but the description adds non-structured context: no echo-back so 'snapshot after', the required env gate KVM_PILOT_MCP_ALLOW_HID plus per-invocation approval, and the return shape (receipt or denial reason). This goes well beyond what the annotations declare.

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?

Purpose and destructive warning are front-loaded, then routing guidance and behavioral notes follow in an ordered, skimmable block. Slightly dense with backticked literals, and 'DESTRUCTIVE (HID)' partly restates the annotation, but every sentence carries weight.

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?

Despite no output schema, the description states what comes back (receipt or denial reason), documents the gating and approval flow, and covers the no-feedback follow-up. Nothing an agent needs to invoke it safely is missing.

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% and each parameter is fully documented there (key code format, confirm semantics, profile selection), so the baseline is 3. The description adds the 'not a chord' constraint for key but nothing new about confirm or profile.

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+resource ('Press and release one key on the managed host's console') and explicitly distinguishes itself from three siblings (send_shortcut for chords, type_text for words, ctrl_alt_delete for Ctrl+Alt+Del). An agent can route to it without opening any 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 concrete when-to-use examples ('Enter to submit, Escape, F2/F12 at POST, arrows and Tab in firmware menus') and names the alternative for each neighboring case, so the boundary with siblings is fully specified.

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