Terminal MCP Server
The Terminal MCP Server enables AI models and applications to execute commands on local or remote systems with advanced session management and integration capabilities.
Local & Remote Execution: Run commands directly on the host machine or on remote systems via SSH
Session Persistence: Maintain consistent terminal environments using named sessions that auto-close after 20 minutes of inactivity
Environment Variables: Set custom environment variables for tailored execution contexts
Flexible Connectivity: Connect via stdio for local integration or Server-Sent Events (SSE) for remote HTTP-based communication
AI Assistant Integration: Configure with tools like Claude Desktop, Roo Code, and Cline for AI-driven command execution
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Terminal MCP Serverlist files in the current directory and show their sizes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Terminal MCP Server
Notice 注意事项
Current Project not in maintance anymore. I recommend you guys to use more advanced command tool —— Desktop Commander
当前项目已经不在维护。我建议大家用更先进的终端MCP工具 Desktop Commander
Terminal MCP Server is a Model Context Protocol (MCP) server that allows executing commands on local or remote hosts. It provides a simple yet powerful interface for AI models and other applications to execute system commands, either on the local machine or on remote hosts via SSH.
Related MCP server: mcp-remote-ssh
Features
Local Command Execution: Execute commands directly on the local machine
Remote Command Execution: Execute commands on remote hosts via SSH
Session Persistence: Support for persistent sessions that reuse the same terminal environment for a specified time (default 20 minutes)
Environment Variables: Set custom environment variables for commands
Multiple Connection Methods: Connect via stdio or SSE (Server-Sent Events)
Installation
Installing via Smithery
To install terminal-mcp-server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @weidwonder/terminal-mcp-server --client claudeManual Installation
# Clone the repository
git clone https://github.com/weidwonder/terminal-mcp-server.git
cd terminal-mcp-server
# Install dependencies
npm install
# Build the project
npm run buildUsage
Starting the Server
# Start the server using stdio (default mode)
npm start
# Or run the built file directly
node build/index.jsStarting the Server in SSE Mode
The SSE (Server-Sent Events) mode allows you to connect to the server remotely via HTTP.
# Start the server in SSE mode
npm run start:sse
# Or run the built file directly with SSE flag
node build/index.js --sseYou can customize the SSE server with the following command-line options:
Option | Description | Default |
| The port to listen on | 8080 |
| The endpoint path | /sse |
| The host to bind to | localhost |
Example with custom options:
# Start SSE server on port 3000, endpoint /mcp, and bind to all interfaces
node build/index.js --sse --port 3000 --endpoint /mcp --host 0.0.0.0This will start the server and listen for SSE connections at http://0.0.0.0:3000/mcp.
Testing with MCP Inspector
# Start the MCP Inspector tool
npm run inspectorThe execute_command Tool
The execute_command tool is the core functionality provided by Terminal MCP Server, used to execute commands on local or remote hosts.
Parameters
Parameter | Type | Required | Description |
command | string | Yes | The command to execute |
host | string | No | The remote host to connect to. If not provided, the command will be executed locally |
username | string | Required when host is specified | The username for SSH connection |
session | string | No | Session name, defaults to "default". The same session name will reuse the same terminal environment for 20 minutes |
env | object | No | Environment variables, defaults to an empty object |
Examples
Executing a Command Locally
{
"command": "ls -la",
"session": "my-local-session",
"env": {
"NODE_ENV": "development"
}
}Executing a Command on a Remote Host
{
"host": "example.com",
"username": "user",
"command": "ls -la",
"session": "my-remote-session",
"env": {
"NODE_ENV": "production"
}
}Configuring with AI Assistants
Configuring with Roo Code
Open VSCode and install the Roo Code extension
Open the Roo Code settings file:
~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.jsonAdd the following configuration:
For stdio mode (local connection)
{
"mcpServers": {
"terminal-mcp": {
"command": "node",
"args": ["/path/to/terminal-mcp-server/build/index.js"],
"env": {}
}
}
}For SSE mode (remote connection)
{
"mcpServers": {
"terminal-mcp-sse": {
"url": "http://localhost:8080/sse",
"headers": {}
}
}
}Replace localhost:8080/sse with your actual server address, port, and endpoint if you've customized them.
Configuring with Cline
Open the Cline settings file:
~/.cline/config.jsonAdd the following configuration:
For stdio mode (local connection)
{
"mcpServers": {
"terminal-mcp": {
"command": "node",
"args": ["/path/to/terminal-mcp-server/build/index.js"],
"env": {}
}
}
}For SSE mode (remote connection)
{
"mcpServers": {
"terminal-mcp-sse": {
"url": "http://localhost:8080/sse",
"headers": {}
}
}
}Configuring with Claude Desktop
Open the Claude Desktop settings file:
~/Library/Application Support/Claude/claude_desktop_config.jsonAdd the following configuration:
For stdio mode (local connection)
{
"mcpServers": {
"terminal-mcp": {
"command": "node",
"args": ["/path/to/terminal-mcp-server/build/index.js"],
"env": {}
}
}
}For SSE mode (remote connection)
{
"mcpServers": {
"terminal-mcp-sse": {
"url": "http://localhost:8080/sse",
"headers": {}
}
}
}Best Practices
Command Execution
Before running commands, it's best to determine the system type (Mac, Linux, etc.)
Use full paths to avoid path-related issues
For command sequences that need to maintain environment, use
&&to connect multiple commandsFor long-running commands, consider using
nohuporscreen/tmux
SSH Connection
Ensure SSH key-based authentication is set up
If connection fails, check if the key file exists (default path:
~/.ssh/id_rsa)Make sure the SSH service is running on the remote host
Session Management
Use the session parameter to maintain environment between related commands
For operations requiring specific environments, use the same session name
Note that sessions will automatically close after 20 minutes of inactivity
Error Handling
Command execution results include both stdout and stderr
Check stderr to determine if the command executed successfully
For complex operations, add verification steps to ensure success
Important Notes
For remote command execution, SSH key-based authentication must be set up in advance
For local command execution, commands will run in the context of the user who started the server
Session timeout is 20 minutes, after which the connection will be automatically closed
Available Tools
1 toolexecute_commandB
Execute commands on remote hosts or locally (This tool can be used for both remote hosts and the current machine)
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Command to execute. Before running commands, it's best to determine the system type (Mac, Linux, etc.) | |
| env | No | Environment variables | |
| host | No | Host to connect to (optional, if not provided the command will be executed locally) | |
| session | No | Session name, defaults to 'default'. The same session name will reuse the same terminal environment for 20 minutes, which is useful for operations requiring specific environments like conda. | default |
| username | No | Username for SSH connection (required when host is specified) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that commands can be executed remotely or locally and hints at session reuse for 20 minutes, but it lacks critical details such as security implications, error handling, output format, or potential side effects. This leaves significant gaps for a tool that executes arbitrary commands.
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, efficient sentence that front-loads the core functionality. It avoids unnecessary details and stays focused on the tool's scope, though it could be slightly more structured by explicitly separating remote and local use cases.
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 complexity of executing commands (which can have security and system impacts), the lack of annotations, and no output schema, the description is insufficient. It fails to address critical aspects like return values, error conditions, or safety warnings, making it incomplete for informed tool usage.
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 100% description coverage, so the baseline is 3. The description does not add any meaningful parameter semantics beyond what is already documented in the schema, such as explaining the 'command' parameter's system dependencies or the 'session' parameter's environmental implications in more depth.
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 tool's purpose as executing commands on remote hosts or locally, specifying both the verb ('execute') and the resource ('commands'). It distinguishes between remote and local execution contexts. However, without sibling tools, it cannot demonstrate differentiation from alternatives, preventing a perfect score.
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 by mentioning both remote and local contexts, but it does not provide explicit guidance on when to choose one over the other or any prerequisites. For example, it notes host is optional for local execution but does not clarify when remote execution is preferable or what conditions might affect it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'execute_command' has a clear, singular purpose that cannot be confused with any other tool in the set.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'execute_command' follows a standard verb_noun pattern, and there are no other tools to cause inconsistency.
A single tool for a terminal server is too few for the apparent scope, as terminal operations typically involve multiple commands and actions. This minimal set may cause agents to struggle with complex tasks that require more granular control.
The tool surface is severely incomplete for a terminal server domain. It lacks essential operations such as listing files, navigating directories, managing processes, or handling input/output streams, making it inadequate for typical terminal workflows.
Maintenance
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
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for building and testing AI agents with multi-model experimentation and insights.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that gives AI assistants full SSH/SFTP remote operations — session management, command execution, interactive shells, file transfers, port forwarding, and system diagnostics.2MIT
- AlicenseAqualityAmaintenanceMCP server giving AI agents full SSH access with persistent sessions, structured command output, SFTP file transfer, and port forwarding.189MIT
- AlicenseAqualityCmaintenanceAn MCP server that gives AI agents SSH access to remote machines through your local OpenSSH client, enabling remote command execution, file transfer, persistent shell sessions, and port forwarding.1716MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that gives AI agents SSH capabilities to execute commands, transfer files, and inspect remote systems through a preconfigured host list.84MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/weidwonder/terminal-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server