Skip to main content
Glama
deenesjakoruzh
LukeLamb

claude-terminal-mcp

by LukeLamb
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Terminal — Claude Desktop extension for Linux

A Claude Desktop extension that gives Claude terminal, filesystem, and background-job access on your local Linux machine.

Addresses a gap on Linux Claude Desktop where claude_desktop_config.json-style MCP servers aren't loaded (that mechanism is macOS/Windows only); on Linux, the only way to add tools is via installable extensions.

⚠️ Security — read this first

Installing this extension grants Claude unrestricted shell access on your user account. Anything your user can do from a terminal, Claude can do through this tool: read any file your user can read, modify anything they can modify, install software, open network connections, etc.

Treat installing this the same way you'd treat giving someone an SSH session to your machine. Don't install it on machines with sensitive data you wouldn't want Claude to see or on shared systems.

There is a minimal built-in safety denylist that refuses a handful of obviously-destructive one-liners (rm -rf /, rm -rf ~, fork bombs, dd/mkfs on raw disk devices, shutdown/reboot). This is a last-resort safety net, not a sandbox. A determined command can trivially bypass it. It exists so that a moment's inattention doesn't wipe your home directory.

To tighten the rails, edit the DENYLIST array at the top of server.js and rebuild. To remove them entirely, set DENYLIST = [] and rebuild.

Related MCP server: claude-linux-mcp

What it does

Exposes 8 tools to Claude:

Tool

Purpose

run_command(command, cwd?, timeout?, env?)

Run a shell command via bash -lc. Pipes, redirects, source venv/bin/activate && … all work. Returns stdout/stderr/exit_code. Output is capped at 100KB per stream; full transcript is always saved to a file and the path returned as log_path.

read_file(path, offset?, limit?)

Read a text file with optional line-range slicing.

list_directory(path)

Entries with type (file/dir), size, and mtime.

write_file(path, content, overwrite?)

Create or overwrite a text file. Parent directories are created.

run_background(command, cwd?)

Spawn a detached subprocess; returns a job_id. Use for long-running work you don't want to block the chat on (builds, training runs, servers).

read_background(job_id, tail?)

Status and last N lines of stdout/stderr for a background job.

list_background()

All jobs (running, exited, killed).

kill_background(job_id)

SIGTERM the job; SIGKILL after 5 seconds if it's still alive.

Run state (transcripts, job scratch files) lives under /tmp/claude-term-mcp/ and is wiped at reboot.

Install

  1. Download the latest Terminal.mcpb from the Releases page.

  2. Open Claude Desktop → Settings → Extensions.

  3. Scroll to the Extension Developer section at the bottom. Click Install Extension and pick the Terminal.mcpb file you downloaded.

  4. Claude Desktop shows the extension details with a red "developer info not verified by Anthropic" warning. Verify you trust the source, then click Install.

  5. At install time Claude Desktop will ask for a Default working directory — this is where shell commands run when Claude doesn't specify one. Pick your main projects folder, or leave empty to default to your home directory.

  6. Back on All extensions, make sure Terminal is toggled on.

  7. In a chat, open the connector/tools picker and enable Terminal for that conversation.

You can change the default working directory later from Settings → Extensions → Terminal.

Requirements

  • Claude Desktop ≥ 0.10.0 on Linux (also tested on macOS)

  • Node.js ≥ 16 (Claude Desktop bundles a recent Node it uses to run the extension, so a system Node isn't required)

  • bash on PATH

No npm install step — the extension is zero-dependency pure Node.

Configuration

All configuration is done through Claude Desktop's UI at install time or under Settings → Extensions → Terminal.

Field

Type

Purpose

Default working directory

Directory

Where shell commands run when Claude doesn't specify one. Leave blank for $HOME.

To customize the denylist or other behavior, edit server.js and rebuild (see below).

Known issues

Yellow banner: "Tool result could not be submitted. The request may have expired or the connection was interrupted." This fires on every turn that triggers Claude's dynamic tool-loading step. The 404 is on the tool-search result submission to the Anthropic backend, not on the MCP tool itself — your tool call runs and returns correctly immediately after the banner. It's cosmetic. Same issue also hits the stock Filesystem extension. Likely a client↔backend protocol mismatch that will be fixed in a future Claude Desktop release.

Build from source

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.

Uninstall

Settings → Extensions → All extensions → Terminal → Remove.

Privacy policy

No data leaves your machine. This extension runs entirely locally:

  • Data collection: None. The extension does not phone home, emit telemetry, or make any network requests of its own. All network calls you observe will be ones you ask Claude to run (e.g. curl, wget, git push).

  • Data usage & storage: Command transcripts (stdin excluded, stdout + stderr + exit code) are written to /tmp/claude-term-mcp/runs/<timestamp>.log so Claude can reference them later in the same conversation. Background job state (command, pid, stdout/stderr log files, exit code, status) is written to /tmp/claude-term-mcp/jobs/<job-id>/.

  • Third-party sharing: None. Nothing is ever transmitted to Anthropic, to the extension author, or to any third party by this extension. (Claude Desktop itself separately sends tool inputs/outputs to Anthropic as part of the normal chat flow — that's Anthropic's relationship with you, not this extension's.)

  • Retention: /tmp/claude-term-mcp/ is cleared at every reboot. To clear it manually: rm -rf /tmp/claude-term-mcp.

  • Permissions scope: Commands run with your own user's permissions — the same as if you typed them into a terminal.

  • Contact / questions: Open an issue at https://github.com/LukeLamb/claude-terminal-mcp/issues.

License

MIT. Use freely, attribution appreciated, no warranty.

Available Tools

8 tools
kill_backgroundA
Destructive

Terminate a running background job (SIGTERM, then SIGKILL after 5s).

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_backgroundA
Read-only

List all background jobs (running, exited, killed).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_directoryA
Read-only

List entries in a directory with type, size, and mtime.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_backgroundA
Read-only

Read status and last N lines of stdout/stderr for a background job. tail=0 returns full logs.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes
tailNoNumber of trailing lines to return. Default 100.

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_fileA
Read-only

Read a text file with optional line-range slicing.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
offsetNo0-indexed starting line. Default 0.
limitNoMax lines to return. Default 2000.

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

run_backgroundA
Destructive

Start a long-running command in the background. Returns a job_id you can poll with read_background.

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYes
cwdNo

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_commandA
Destructive

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesShell command to run. Pipes, redirects, `source venv/bin/activate && …` all work.
cwdNoWorking directory. Defaults to the user-configured default working directory (or the user's home directory if unset).
timeoutNoTimeout in seconds. Default 120.
envNoExtra environment variables to set for this command.

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

write_fileA
Destructive

Create or overwrite a text file. Parent directories are created.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
contentYes
overwriteNoDefault true.

TDQS

A3.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv0.1.0
    • First observedkill_background
    • First observedlist_background
    • First observedlist_directory
    • First observedread_background
    • First observedread_file
    • First observedrun_background
    • First observedrun_command
    • First observedwrite_file
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

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.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., kill_background, list_directory, read_file), making the set predictable.

Tool Count5/5

With 8 tools, the server covers essential terminal operations (command execution, file read/write, listing, background jobs) without excessive tool count.

Completeness4/5

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.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • claude-linux-mcp

    LukeLamb
    A
    license
    A
    quality
    C
    maintenance
    Give Claude Desktop full desktop control on Linux/X11: screenshot, mouse, keyboard, windows, clipboard, app launch. Zero-dependency MCP extension, MIT-licensed.
    15
    MIT

  • mcp2term

    soobik
    A
    license
    Not graded
    quality
    B
    maintenance
    Exposes an interactive terminal over MCP, enabling remote shell command execution, file operations, and directory management via ChatGPT or Claude Desktop.
    2
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LukeLamb/claude-terminal-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server