로컬 Linux 머신에서 Claude에게 터미널, 파일 시스템 및 백그라운드 작업 액세스 권한을 부여하는 Claude Desktop 확장 프로그램입니다.
이 확장 프로그램은 claude_desktop_config.json 방식의 MCP 서버가 로드되지 않는 Linux Claude Desktop의 공백을 해결합니다(해당 메커니즘은 macOS/Windows 전용입니다). Linux에서는 설치 가능한 확장 프로그램을 통해서만 도구를 추가할 수 있습니다.
이 확장 프로그램을 설치하면 Claude에게 사용자 계정에 대한 제한 없는 셸 액세스 권한이 부여됩니다. 사용자가 터미널에서 할 수 있는 모든 작업(사용자가 읽을 수 있는 파일 읽기, 수정 가능한 모든 것 수정, 소프트웨어 설치, 네트워크 연결 열기 등)을 Claude가 이 도구를 통해 수행할 수 있습니다.
이 설치를 누군가에게 내 머신에 대한 SSH 세션을 제공하는 것과 동일하게 취급하십시오. Claude가 보지 않았으면 하는 민감한 데이터가 있는 머신이나 공유 시스템에는 설치하지 마십시오.
명백히 파괴적인 몇 가지 한 줄 명령(rm -rf /, rm -rf ~, 포크 폭탄, 원시 디스크 장치에 대한 dd/mkfs, shutdown/reboot)을 거부하는 최소한의 내장 안전 거부 목록이 있습니다. 이는 최후의 수단인 안전망일 뿐, 샌드박스가 아닙니다. 의도적인 명령은 이를 쉽게 우회할 수 있습니다. 이는 잠시 부주의하더라도 홈 디렉토리가 삭제되지 않도록 하기 위해 존재합니다.
제한을 강화하려면 server.js 상단의 DENYLIST 배열을 편집하고 다시 빌드하십시오. 완전히 제거하려면 DENYLIST = []로 설정하고 다시 빌드하십시오.
Related MCP server: claude-linux-mcp
Claude에게 8가지 도구를 제공합니다:
도구 | 목적 |
|
|
| 선택적 행 범위 슬라이싱을 사용하여 텍스트 파일을 읽습니다. |
| 유형(파일/디렉토리), 크기 및 수정 시간(mtime)이 포함된 항목을 나열합니다. |
| 텍스트 파일을 생성하거나 덮어씁니다. 상위 디렉토리가 생성됩니다. |
| 분리된 하위 프로세스를 생성하고 |
| 백그라운드 작업의 상태와 stdout/stderr의 마지막 N줄을 읽습니다. |
| 모든 작업(실행 중, 종료됨, 강제 종료됨)을 나열합니다. |
| 작업에 SIGTERM을 보냅니다. 5초 후에도 살아있으면 SIGKILL을 보냅니다. |
실행 상태(기록, 작업 임시 파일)는 /tmp/claude-term-mcp/ 아래에 저장되며 재부팅 시 삭제됩니다.
Releases 페이지에서 최신 Terminal.mcpb를 다운로드합니다.
Claude Desktop → Settings → Extensions를 엽니다.
하단의 Extension Developer 섹션으로 스크롤합니다. Install Extension을 클릭하고 다운로드한 Terminal.mcpb 파일을 선택합니다.
Claude Desktop에 "developer info not verified by Anthropic"이라는 빨간색 경고와 함께 확장 프로그램 세부 정보가 표시됩니다. 소스를 신뢰하는지 확인한 후 Install을 클릭합니다.
설치 시 Claude Desktop에서 Default working directory를 묻습니다. 이는 Claude가 별도로 지정하지 않을 때 셸 명령이 실행되는 위치입니다. 주요 프로젝트 폴더를 선택하거나 비워두어 홈 디렉토리를 기본값으로 설정하십시오.
All extensions에서 Terminal이 켜져 있는지 확인합니다.
채팅에서 커넥터/도구 선택기를 열고 해당 대화에 Terminal을 활성화합니다.
기본 작업 디렉토리는 나중에 Settings → Extensions → Terminal에서 변경할 수 있습니다.
Linux용 Claude Desktop ≥ 0.10.0 (macOS에서도 테스트됨)
Node.js ≥ 16 (Claude Desktop은 확장 프로그램 실행에 사용하는 최신 Node를 번들로 제공하므로 시스템 Node는 필요하지 않습니다)
PATH에 bash 필요
npm install 단계가 없습니다. 이 확장 프로그램은 의존성이 없는 순수 Node입니다.
모든 구성은 설치 시 또는 Settings → Extensions → Terminal에서 Claude Desktop의 UI를 통해 수행됩니다.
필드 | 유형 | 목적 |
Default working directory | 디렉토리 | Claude가 별도로 지정하지 않을 때 셸 명령이 실행되는 위치입니다. |
거부 목록이나 기타 동작을 사용자 지정하려면 server.js를 편집하고 다시 빌드하십시오(아래 참조).
노란색 배너: "Tool result could not be submitted. The request may have expired or the connection was interrupted." 이 메시지는 Claude의 동적 도구 로딩 단계를 트리거하는 모든 턴에서 발생합니다. 404 오류는 Anthropic 백엔드에 대한 도구 검색 결과 제출 시 발생하는 것이며 MCP 도구 자체의 오류가 아닙니다. 도구 호출은 배너 직후에 올바르게 실행되고 반환됩니다. 이는 시각적인 문제입니다. 동일한 문제가 기본 파일 시스템 확장 프로그램에서도 발생합니다. 향후 Claude Desktop 릴리스에서 수정될 클라이언트↔백엔드 프로토콜 불일치로 보입니다.
git clone https://github.com/LukeLamb/claude-terminal-mcp
cd claude-terminal-mcp
# Edit whatever you want in server.js / manifest.json.
# If you change the tool surface, update both places.
# Bump the version in manifest.json so Claude Desktop treats the install as an update.
# Build the bundle:
zip -j Terminal.mcpb manifest.json package.json server.js
# Then install Terminal.mcpb via Claude Desktop → Settings → Extensions → Install Extension.Settings → Extensions → All extensions → Terminal → Remove.
데이터는 머신을 떠나지 않습니다. 이 확장 프로그램은 완전히 로컬에서 실행됩니다:
데이터 수집: 없음. 확장 프로그램은 외부로 데이터를 전송하거나, 원격 측정을 수행하거나, 자체적으로 네트워크 요청을 하지 않습니다. 관찰되는 모든 네트워크 호출은 사용자가 Claude에게 실행하도록 요청한 것(예: curl, wget, git push)입니다.
데이터 사용 및 저장: 명령 기록(stdin 제외, stdout + stderr + exit code)은 /tmp/claude-term-mcp/runs/<timestamp>.log에 기록되어 Claude가 나중에 동일한 대화에서 참조할 수 있습니다. 백그라운드 작업 상태(명령, pid, stdout/stderr 로그 파일, exit code, 상태)는 /tmp/claude-term-mcp/jobs/<job-id>/에 기록됩니다.
제3자 공유: 없음. 이 확장 프로그램에 의해 Anthropic, 확장 프로그램 작성자 또는 제3자에게 전송되는 데이터는 없습니다. (Claude Desktop 자체는 일반적인 채팅 흐름의 일부로 도구 입력/출력을 Anthropic에 전송합니다. 이는 사용자와 Anthropic 간의 관계이며 이 확장 프로그램과는 무관합니다.)
보관: /tmp/claude-term-mcp/는 재부팅할 때마다 삭제됩니다. 수동으로 삭제하려면 rm -rf /tmp/claude-term-mcp를 실행하십시오.
권한 범위: 명령은 터미널에 직접 입력하는 것과 동일하게 사용자의 권한으로 실행됩니다.
문의 / 질문: https://github.com/LukeLamb/claude-terminal-mcp/issues에서 이슈를 생성하십시오.
MIT. 자유롭게 사용하십시오. 출처 표기를 권장하며 보증은 제공되지 않습니다.
Terminate a running background job (SIGTERM, then SIGKILL after 5s).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, and the description adds specific behavioral details (SIGTERM then SIGKILL after 5s), which goes beyond the annotation. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core purpose and key details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, destructiveHint annotation), the description covers the main behavior but lacks information on error handling, return values, or what happens if the job_id is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (job_id) with no description (0% coverage), and the description does not elaborate on this parameter or its format. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('terminate') and the resource ('running background job'), and explicitly mentions the signal sequence (SIGTERM then SIGKILL after 5s). This distinguishes it from sibling tools like list_background and run_background.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for forceful termination but does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites. The context of sibling names provides some guidance, but it is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all background jobs (running, exited, killed).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description confirms this is a list operation. It adds behavioral context by specifying the job states included (running, exited, killed), which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with 8 words, front-loading the purpose. Every word adds value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description covers what the tool does and the states returned. However, it lacks details on the output structure (e.g., fields like job ID or status), which would help an agent interpret results without schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage. The description correctly omits parameter details as none exist. No additional parameter info is needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all background jobs' with specific states (running, exited, killed). The verb 'List' and resource 'background jobs' are unambiguous, and the states differentiate it from siblings like kill_background or run_background.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs to view all background jobs, but it does not provide explicit guidance on when to use this tool versus alternatives like read_background for job details or kill_background for termination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List entries in a directory with type, size, and mtime.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by explicitly listing the fields returned (type, size, mtime), which is beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear and to the point, front-loading the purpose and output fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, the description covers the basics but lacks details about error handling, recursion, symlinks, or output structure. Given the low complexity, it is minimally viable but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' has no description in the schema (0% coverage), and the tool description does not clarify the expected format (absolute/relative), allowed values, or behavior for missing paths. The parameter name is self-explanatory, but the description should compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and resource ('directory entries') and specifies the output fields (type, size, mtime), which distinguishes it from siblings like read_file that read file contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines on when to use vs alternatives. While the function is straightforward, the description does not mention when not to use or provide context about prerequisites (e.g., path must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read status and last N lines of stdout/stderr for a background job. tail=0 returns full logs.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| tail | No | Number of trailing lines to return. Default 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating safety. Description adds detail about reading stdout/stderr and the tail=0 behavior for full logs, enhancing transparency without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loaded with verb and resource, efficiently conveying core functionality and a key parameter behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should clarify return format. It mentions 'status and last N lines' but lacks specifics on structure, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only tail has description). The description adds value for tail ('tail=0 returns full logs') but does not describe job_id beyond context of 'background job'. Partially compensates for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read status and last N lines of stdout/stderr for a background job', specifying the verb and resource. It distinguishes from sibling tools like kill_background (kill) and run_background (start).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for reading background job output but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives like read_file for non-job outputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a text file with optional line-range slicing.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| offset | No | 0-indexed starting line. Default 0. | |
| limit | No | Max lines to return. Default 2000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, indicating non-destructive behavior. The description adds the line-range slicing behavior, which is not covered by annotations. However, it does not disclose other behavioral traits like encoding assumptions, file existence errors, or output format. With annotations covering safety, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, with no unnecessary verbiage. It is front-loaded with the core action and concisely adds scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's simplicity, the description covers the input and basic behavior. However, it omits details like return format (list of strings?), error handling (e.g., file not found), or constraints (e.g., file must be UTF-8). It is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (offset and limit have descriptions, path does not). The description mentions 'line-range slicing', which reinforces offset and limit, but does not explicitly describe the path parameter beyond implying it refers to a text file. It adds some context but does not fully compensate for the missing schema description on path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read a text file with optional line-range slicing' uses a specific verb (Read) and resource (text file), and adds the line-range slicing detail that distinguishes it from sibling tools like write_file or list_directory. It clearly communicates the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading text files, optionally with line-range slicing. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., using run_command with cat). The context is clear but lacks exclusion guidance, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a long-running command in the background. Returns a job_id you can poll with read_background.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| cwd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'long-running' context and return of job_id beyond annotations (destructiveHint, openWorldHint). Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but could benefit from structured listing of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks mentions of kill_background for cancellation or list_background for querying. No output schema so return format (job_id type) is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description provides no additional meaning for 'command' or 'cwd' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Start', resource 'long-running command in the background', and output 'job_id' for polling. Distinguishes from siblings like read_background.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions polling via read_background, guiding usage. Could explicitly contrast with run_command for foreground tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a shell command via bash -lc on the user's machine. Returns stdout/stderr/exit_code. Default cwd is the user-configured default working directory (or $HOME if unset). Output capped at 100KB per stream; full transcript saved to log_path.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Shell command to run. Pipes, redirects, `source venv/bin/activate && …` all work. | |
| cwd | No | Working directory. Defaults to the user-configured default working directory (or the user's home directory if unset). | |
| timeout | No | Timeout in seconds. Default 120. | |
| env | No | Extra environment variables to set for this command. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful behavioral details beyond annotations: output capped at 100KB, full transcript saved to log_path, default cwd behavior, and use of bash -lc. Does not contradict destructiveHint or openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, execution method, defaults, and output limits. Front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality, defaults, and output limits. Could mention blocking nature or security implications, but given no output schema and good annotations, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage). Description adds minor value for 'command' parameter (notes pipes/redirects work) but otherwise repeats schema info. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs a shell command via bash -lc, returns stdout/stderr/exit_code. Distinguishes from sibling tools like list_directory or kill_background by focusing on command execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives like run_background or read_file. The description only states what it does, not when to prefer it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or overwrite a text file. Parent directories are created.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes | ||
| overwrite | No | Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true. The description adds that parent directories are created, providing useful behavioral context beyond the annotation. It does not mention file size limits or encoding, but for a simple write tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with no unnecessary words. The key action and side effect (parent directory creation) are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality but omits edge cases (e.g., behavior when overwrite is false and file exists). With no output schema, the side effects and return values are not disclosed. Overall minimal viable but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only overwrite has a description). The tool description does not elaborate on path or content parameters, failing to compensate for the low coverage. The description only implies content is text, no parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create or overwrite a text file' with a specific verb and resource. The additional detail about parent directories being created distinguishes it from siblings like read_file and run_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as run_command or read_file. The description omits when not to use it or mention of trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0kill_backgroundlist_backgroundlist_directoryread_backgroundread_filerun_backgroundrun_commandwrite_fileScored across 8 tools
Each tool has a distinct purpose: run_command for synchronous commands, run_background for long-running, and separate tools for file operations and background job management. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., kill_background, list_directory, read_file), making the set predictable.
With 8 tools, the server covers essential terminal operations (command execution, file read/write, listing, background jobs) without excessive tool count.
Core operations are present, but missing file deletion, rename, and persistent directory change tools; however, these can be accomplished via run_command, so only minor gaps.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
