aiterm-mcp

Overview Schema Source Related Servers Discussions Admin

claude_approval

Inspect and respond to approval prompts during active turns. Verify the current digest and operation before sending approve or deny, ensuring safe single-shot responses.

Instructions

aiterm相関付きClaudeのactive turn中に表示された権限確認UIを、turn相関を保ったまま検査・応答する専用面。inspectで画面digestと安全な単発Yes/Noだけを取得し、respondは同じoperation・同じdigestが現在も表示中の場合だけ送信する。

Input Schema

TableJSON Schema

Name	Required	Description
`action`	Yes
`remote`	No	別端末のAitermで実行する時のSSH接続情報。hostだけならssh_configの接続名として使う。Aitermは接続情報を保存・管理しない。passphraseは会話記録に残るため、ssh-agentかpassphrase_env（環境変数名）を推奨する。
`session_id`	Yes
`operation_id`	No	durable operationのID。通常pty_send由来の匿名turnでは省略する
`approval_choice`	No	respondだけに指定する
`observed_prompt_digest`	No	直前のinspectが返したdigest。respondだけに指定する

Output Schema

TableJSON Schema

Name	Required	Description	Default
`at`	Yes
`action`	Yes
`schema`	Yes
`status`	Yes
`choices`	Yes
`session_id`	Yes
`operation_id`	Yes
`prompt_digest`	Yes
`selected_choice`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.39.1Sep 26, 2026

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"
+}

First observedv0.20.2Jul 26, 2026

TDQS

A4.3/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 burden. It discloses key behavioral constraints: inspect only retrieves a digest and safe one-shot Yes/No options, and respond is only sent when both operation and digest match the current display. This gives the agent a clear safety model, though it does not detail error handling or side effects beyond these conditions.

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?

The description is a single dense sentence that front-loads the purpose and then explains the two actions' constraints. It is concise but packs a lot of information; every clause contributes to the tool's usage, though it could be split for readability.

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

Completeness4/5

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

Given the tool's complexity (6 params, nested remote object, output schema present), the description is fairly complete. It explains the core workflow and conditions for safe use, and the output schema covers return details. Minor gaps remain about what happens on digest mismatch or connection issues, but these are not critical for correct invocation.

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 67%, and the description adds meaning by explaining the action flow and which parameters apply to each action (e.g., approval_choice and observed_prompt_digest are for respond only). The remote parameter also gets detailed guidance in the schema, and the tool description reinforces the conditional use of these params.

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?

The description clearly states the tool's purpose: inspecting and responding to Claude's permission-confirmation UI during an active turn, while preserving turn correlation. It specifies the two actions (inspect for a digest and safe one-shot Yes/No, respond only when the same operation/digest is displayed) and distinguishes itself from siblings by focusing on Claude and aiterm correlation.

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?

The description conveys when to use the tool (during Claude's active turn) and when to respond (only when the digest matches). It implies this is the specialized surface for Claude, but it does not explicitly name alternatives like agent_approval or contrast them. Clear context, but no explicit exclusions.

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

Deploy Server