Skip to main content
Glama
kitepon
by kitepon

pty_key

Send control keys (Ctrl+C, Ctrl+D, Enter, Tab, arrows) to a live terminal session. In Claude-correlated sessions, restrict to Ctrl+C only to respect turn boundaries, while approvals are managed through the claude_approval UI.

Instructions

制御キーを送る(C-c, C-d, Enter, Tab, Up, Down... の別名に対応)。aiterm相関付きClaude sessionではturn相関を守るためC-cだけを許可し、承認UIはclaude_approvalで操作する。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesキー名(例 "C-c", "Enter", "Up")
remoteNo別端末のAitermで実行する時のSSH接続情報。hostだけならssh_configの接続名として使う。Aitermは接続情報を保存・管理しない。passphraseは会話記録に残るため、ssh-agentかpassphrase_env(環境変数名)を推奨する。
session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.39.1
    • addedInput schema / properties / remote
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "別端末のAitermで実行する時のSSH接続情報。hostだけならssh_configの接続名として使う。Aitermは接続情報を保存・管理しない。passphraseは会話記録に残るため、ssh-agentかpassphrase_env(環境変数名)を推奨する。",
      +  "properties": {
      +    "host": {
      +      "pattern": "^(?!-)[A-Za-z0-9._%:\\[\\]-]{1,255}$",
      +      "type": "string"
      +    },
      +    "identity_file": {
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "passphrase": {
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "passphrase_env": {
      +      "pattern": "^[A-Za-z_][A-Za-z0-9_]*$",
      +      "type": "string"
      +    },
      +    "port": {
      +      "maximum": 65535,
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    "ssh_options": {
      +      "items": {
      +        "pattern": "^[A-Za-z][A-Za-z0-9]*=[^\\r\\n]*$",
      +        "type": "string"
      +      },
      +      "maxItems": 32,
      +      "type": "array"
      +    },
      +    "user": {
      +      "pattern": "^(?!-)[A-Za-z0-9._@\\\\-]{1,128}$",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "host"
      +  ],
      +  "type": "object"
      +}
  2. Addedv0.22.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses a key behavioral restriction (only C-c allowed in aiterm-associated sessions) and indicates that approval UI is not handled here. However, it does not explain what happens when other keys are sent in restricted contexts, potential side effects, or the overall effect of sending keys. Some transparency is present, but significant behavioral details are missing.

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

Conciseness5/5

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

The description is extremely concise, consisting of two sentences. It front-loads the primary function and then adds a critical usage caveat. Every word contributes; there is no redundancy or filler.

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

Completeness2/5

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

Given the tool has a nested remote object, no output schema, and no annotations, the description is notably incomplete. It fails to mention the remote parameter's role, return values, error behavior, or how session_id is used. While the key restriction is valuable, an agent lacks sufficient information to use the tool correctly in all intended scenarios.

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 coverage is 67% (key and remote have descriptions; session_id lacks one). The description adds value for the key parameter by listing examples of valid aliases, which goes beyond the schema's generic 'key name'. It does not address session_id or remote, but remote already has a thorough schema description. The description partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sends control keys with aliases like C-c, C-d, Enter, etc. It distinguishes itself from pty_send (which likely sends text) by focusing on control keys. While it doesn't explicitly name a sibling, the purpose is specific and unambiguous.

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?

The description provides explicit usage guidance: in aiterm-associated Claude sessions, only C-c is permitted to preserve turn correlation, and approval UI should be handled via claude_approval. This tells the agent when to use and when not to use the tool, and names an alternative (claude_approval) for related operations.

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