Skip to main content
Glama
Sign In
aiterm-mcp

aiterm-mcp

by kitepon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

pty_key

Sends named control keys such as Ctrl-C, Enter, Tab, and arrow keys to a tmux-backed PTY session so Claude Code can navigate and control interactive terminal programs.

Instructions

制御キーを送る（C-c, C-d, Enter, Tab, Up, Down... の別名に対応）。acceptedは入力受付であり処理中断/会話維持の確認ではない。aiterm相関付きClaudeではC-cだけを許可し、承認UIはclaude_approvalで操作する。

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": {
      "session_id": "<session_id>",
      "key": "<key>"
    },
    "name": "pty_key"
  }
}

Input 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.6/5.0
Behavior3/5

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

With no annotations at all, the description carries the full burden, and it does disclose two non-obvious traits: that the returned 'accepted' means only keystroke acceptance rather than confirmed interruption, and that the tool is permission-restricted to C-c in one context. It stops short of describing what the tool does when the key is rejected, whether input is buffered/echoed, or how the call behaves against the remote SSH target.

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?

Three tight sentences with the core action and alias list front-loaded, zero filler. The middle caveat about 'accepted' is dense and somewhat cryptic on first read, but it earns its place as a real semantic warning.

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

Completeness3/5

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

Adequate for a 3-parameter mutation-style tool with no output schema and no annotations, given it explains the return-value caveat and the approval routing. It leaves the session_id relationship and any failure behavior unspecified, which matters because nothing else in the definition compensates for the missing annotations.

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% and the nested remote object is richly documented in-schema, so the baseline is 3. The description adds genuine value for `key` by cataloguing alias forms and flagging the C-c-only restriction, but says nothing about `session_id` or how the remote path interacts with key delivery.

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?

States a specific verb and resource ('sends a control key') and enumerates the accepted alias forms (C-c, C-d, Enter, Tab, Up, Down), which tells an agent exactly what class of input this tool handles. It never names pty_send as the contrasting sibling for plain text input, so the boundary with the other input-injection tool must be inferred.

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 an explicit usage constraint and an explicit alternative: under aiterm-correlated Claude only C-c is permitted, and approval UI must go through claude_approval instead. That is real when/when-not routing. The pty_key-vs-pty_send split for ordinary typing is left implicit.

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