Which integrations are available for this server?

Enables management of long-running terminal processes on Linux, allowing AI agents to start, stop, and monitor processes with real-time log capture and search capabilities. Enables management of long-running terminal processes on macOS, allowing AI agents to start, stop, and monitor processes with real-time log capture and search capabilities.

How do I use MCP Terminal?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Terminal start npm run dev for the backend process" 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.

MCP Terminal

by h004888

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP Terminal

MCP server for managing long-running processes and logs. Enables AI agents (Claude Code) to start, stop, and monitor processes with real-time log capture.

Tiếng Việt

Tính năng

Khởi động/Dừng Process - Chạy các process dài và tắt chúng một cách an toàn
Ghi Log thời gian thực - Tất cả stdout/stderr được tự động ghi vào file log
Tìm kiếm Log - Tìm log theo từ khóa hoặc regex
Quản lý Process - Liệt kê các process đang chạy
Log Rotation - Tự động xoay log khi đạt 10MB để tránh đầy ổ đĩa
Tắt an toàn - Tất cả process được dọn dẹp khi server dừng

Cài đặt

Yêu cầu

Node.js >= 18
npm

Các bước

# Clone repository
git clone https://github.com/h004888/mcp_terminal_process.git
cd mcp-terminal

# Cài đặt dependencies
npm install

# Build
npm run build

Cấu hình Claude Code

Thêm vào file .claude.json của Claude Code:

Windows: %USERPROFILE%\.claude.json macOS/Linux: ~/.claude.json

{
  "mcpServers": {
    "mcp-terminal": {
      "command": "node",
      "args": ["C:/đường-dẫn/đến/mcp-terminal/dist/index.js"]
    }
  }
}

Cấu hình OpenCode

Thêm vào file opencode.json của OpenCode:

Đường dẫn mặc định: ~/.config/opencode/opencode.json

{
  "mcp": {
    "mcp-terminal": {
      "type": "local",
      "command": ["node", "/đường-dẫn/đến/mcp-terminal/dist/index.js"],
      "environment": {},
      "timeout": 5000
    }
  }
}

Related MCP server: Background Process MCP

English

Features

Start/Stop Processes - Launch long-running processes and terminate them gracefully
Real-time Log Capture - All stdout/stderr automatically written to log files
Log Search - Search logs by keyword or regex
Process Management - List all running processes
Log Rotation - Automatic rotation at 10MB to prevent disk exhaustion
Graceful Shutdown - All processes cleaned up when server stops

Installation

Prerequisites

Node.js >= 18
npm

Steps

# Clone the repository
git clone https://github.com/h004888/mcp_terminal_process.git
cd mcp-terminal

# Install dependencies
npm install

# Build
npm run build

Claude Code Configuration

Add to your Claude Code .claude.json:

Windows: %USERPROFILE%\.claude.json macOS/Linux: ~/.claude.json

{
  "mcpServers": {
    "mcp-terminal": {
      "command": "node",
      "args": ["C:/path/to/mcp-terminal/dist/index.js"]
    }
  }
}

After configuration, restart Claude Code to load the MCP server.

OpenCode Configuration

Add to your OpenCode opencode.json:

Default location: ~/.config/opencode/opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mcp-terminal": {
      "type": "local",
      "command": ["node", "/path/to/mcp-terminal/dist/index.js"],
      "environment": {},
      "timeout": 5000,
      "enabled": true
    }
  }
}

Example with full path (Windows):

{
  "mcp": {
    "mcp-terminal": {
      "type": "local",
      "command": ["node", "C:/Users/ADMIN/Downloads/mcp-terminal/dist/index.js"],
      "environment": {},
      "timeout": 5000,
       "enabled": true
    }
  }
}

Example using npx (if published to npm):

{
  "mcp": {
    "mcp-terminal": {
      "type": "local",
      "command": ["npx", "-y", "mcp-terminal"],
      "timeout": 5000,
       "enabled": true
    }
  }
}

After configuration, restart OpenCode to load the MCP server.

Tools

start_process

Start a long-running process.

{
  "id": "backend",
  "command": "npm run dev",
  "cwd": "C:/path/to/project"
}

Parameters:

id (required) - Unique process identifier
command (required) - Command to execute
cwd (optional) - Working directory

stop_process

Stop a running process.

{
  "id": "backend"
}

get_logs

Retrieve logs from a process.

{
  "id": "backend",
  "lines": 100
}

Parameters:

id (required) - Process identifier
lines (optional) - Return last N lines only

search_logs

Search logs for a keyword or regex.

{
  "id": "backend",
  "keyword": "ERROR",
  "regex": false
}

Parameters:

id (required) - Process identifier
keyword (required) - Search term
regex (optional) - Use regex search (default: false)

list_processes

List all running processes.

{}

Returns all currently running processes with their IDs, status, command, and log file paths.

Usage Examples

Start a backend server

/mcp start_process {"id": "backend", "command": "npm run dev", "cwd": "C:/my-project"}

Check logs

/mcp get_logs {"id": "backend"}

Search for errors

/mcp search_logs {"id": "backend", "keyword": "Exception"}

List all processes

/mcp list_processes {}

Stop a process

/mcp stop_process {"id": "backend"}

Architecture

User (Claude Code) → MCP Protocol → MCP Server → Process Manager → logs/*.log

Components:

MCP Server - Handles MCP protocol and exposes tools
Process Manager - Spawns, tracks, and kills child processes
Log Service - File-based log storage with 10MB rotation

Log Files

Logs are stored in the logs/ directory:

logs/{id}.log - Current active log
logs/{id}.1.log - Rotated log (oldest)
etc.

Logs are rotated when they exceed 10MB. Maximum 5 rotated files kept per process.

License

MIT

Available Tools

5 tools

get_logsC

Get logs from a process

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Process identifier
`lines`	No	Number of lines to return (optional)

TDQS

C2.6/5.0

Behavior2/5

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 states 'Get logs' but doesn't specify if this is read-only, requires permissions, has rate limits, returns structured or raw data, or handles errors. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.

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, efficient sentence with no wasted words, making it easy to parse. However, it could be more front-loaded with key details (e.g., scope or differentiation), but its brevity is appropriate for basic clarity.

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

Completeness2/5

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

Given the tool's complexity (2 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the logs contain, how they're formatted, or any behavioral traits, leaving the agent under-informed for proper invocation and result handling.

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?

The input schema has 100% description coverage, clearly documenting 'id' as 'Process identifier' and 'lines' as 'Number of lines to return (optional)'. The description adds no additional meaning beyond this, such as format examples or constraints, but the schema provides adequate baseline information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get logs from a process' clearly states the verb ('Get') and resource ('logs from a process'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_logs' or specify what type of logs or scope (e.g., recent, all, error logs), leaving it somewhat vague compared to alternatives.

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?

The description provides no guidance on when to use this tool versus alternatives like 'search_logs' or 'list_processes'. It doesn't mention prerequisites (e.g., needing a process ID from 'list_processes') or exclusions (e.g., not for real-time monitoring), leaving the agent with minimal context for tool selection.

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

list_processesB

List all running processes managed by this MCP server

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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 states the action ('List all running processes') but lacks details on permissions, rate limits, output format, or whether it's a safe read operation. This is insufficient for a tool with no annotation coverage.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.

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 tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic action but lacks details on behavior and output, which are important for completeness even in simple tools.

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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any, earning a baseline score near the top of the scale.

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?

The description clearly states the verb ('List') and resource ('running processes managed by this MCP server'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_logs' or 'search_logs', which prevents 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'get_logs' or 'search_logs'. The description implies usage for listing processes but offers no context on prerequisites, timing, or exclusions.

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

search_logsC

Search logs for a keyword or regex

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Process identifier
`keyword`	Yes	Keyword or regex to search for
`regex`	No	Use regex search (optional)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While 'search' implies a read operation, the description doesn't disclose important behavioral traits like whether this requires authentication, has rate limits, returns paginated results, or what happens with invalid inputs. It provides minimal context beyond the basic operation.

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, efficient sentence with zero wasted words. It's appropriately sized for a search tool and front-loads the essential information. Every word earns its place by contributing to understanding the tool's purpose.

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

Completeness2/5

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

Given no annotations, no output schema, and a search operation that likely returns complex results, the description is insufficient. It doesn't explain what format results come in, whether they're filtered/ranked, error conditions, or performance characteristics. For a search tool with 3 parameters and no structured output documentation, more context is needed about the operation's behavior and results.

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 100%, so the schema already documents all three parameters thoroughly. The description mentions 'keyword or regex' which aligns with the 'keyword' parameter description, but adds no additional semantic context beyond what's in the schema. With complete schema coverage, the baseline of 3 is appropriate as the description doesn't significantly enhance parameter understanding.

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?

The description clearly states the tool's purpose with a specific verb ('search') and resource ('logs'), and specifies the search target ('keyword or regex'). It distinguishes from sibling 'get_logs' by implying filtering/searching rather than retrieval, but doesn't explicitly differentiate. The description is not tautological and provides meaningful information about what the tool does.

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?

The description provides no guidance on when to use this tool versus alternatives like 'get_logs' or 'list_processes'. There's no mention of prerequisites, context for usage, or exclusions. The agent must infer usage from the tool name and description alone without any explicit guidance.

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

start_processC

Start a long-running process and capture its output to a log file

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Unique process identifier
`command`	Yes	Command to execute
`cwd`	No	Working directory (optional)

TDQS

C2.9/5.0

Behavior2/5

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 the process is 'long-running' and output is captured to a log file, but fails to address critical aspects like permissions required, whether the process runs asynchronously, how errors are handled, or if there are rate limits. This leaves significant gaps for safe and effective tool invocation.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and outcome, making it easy to understand at a glance.

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

Completeness2/5

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

Given the complexity of starting a process (which involves execution, logging, and potential side-effects) and the absence of annotations and output schema, the description is insufficient. It does not explain what the tool returns (e.g., process status, log file path), error conditions, or interaction with sibling tools like 'get_logs', leaving the agent with incomplete operational context.

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 100%, so the schema already documents all parameters (id, command, cwd). The description does not add any additional meaning or context beyond what the schema provides, such as examples of valid commands or log file naming conventions. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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?

The description clearly states the action ('Start a long-running process') and the outcome ('capture its output to a log file'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'stop_process' or 'list_processes', which would require mentioning process lifecycle management or monitoring aspects.

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?

The description provides no guidance on when to use this tool versus alternatives such as 'stop_process' or 'get_logs'. It lacks context about prerequisites, error handling, or typical use cases, leaving the agent to infer usage from the tool name alone.

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

stop_processC

Stop a running process

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Process identifier to stop

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('stop') but doesn't clarify what 'stop' entails—whether it's a graceful shutdown, force termination, or reversible. It also omits critical details like permissions required, side effects (e.g., data loss), error handling, or confirmation prompts. This is inadequate for a mutation tool with zero annotation coverage.

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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving maximum efficiency.

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

Completeness2/5

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

Given the tool's complexity (a mutation operation to stop processes), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like safety, reversibility, or response format, leaving significant gaps for an AI agent to understand how to invoke it correctly in context with its siblings.

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?

The input schema has 100% description coverage, with the single parameter 'id' documented as 'Process identifier to stop'. The description adds no additional meaning beyond this, such as format examples (e.g., numeric ID, name) or where to obtain the ID (e.g., from 'list_processes'). Baseline 3 is appropriate since the schema does the heavy lifting.

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?

The description clearly states the action ('stop') and target resource ('a running process'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'start_process' beyond the obvious verb difference, nor does it specify what type of process (e.g., system process, background job) it operates on.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the process must be running), when not to use it (e.g., for system-critical processes), or how it relates to siblings like 'list_processes' (to identify processes to stop) or 'start_process' (to restart after stopping).

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.

5 tool updatesv1.0.0Mar 19, 2026
- First observedget_logs
- First observedlist_processes
- First observedsearch_logs
- First observedstart_process
- First observedstop_process

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: get_logs retrieves logs, list_processes enumerates processes, search_logs filters logs, start_process initiates processes, and stop_process terminates them. The descriptions reinforce these boundaries, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., get_logs, list_processes, search_logs, start_process, stop_process), using snake_case throughout. This predictability aids agent comprehension and tool selection.

Tool Count5/5

With 5 tools, the set is well-scoped for terminal/process management, covering core operations (list, start, stop processes, and get/search logs). Each tool earns its place without bloat or thinness.

Completeness4/5

The tools provide strong coverage for process lifecycle (start, stop, list) and log handling (get, search), but minor gaps exist, such as no tool for restarting processes or managing log files (e.g., delete/rotate). Agents can work around this with existing tools.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

LastPing A
dev.lastping
Monitoring that agents set up for themselves — cron jobs, CI/CD pipelines and AI agent runs.
Monitoring CI/CD & DevOps Autonomous Agents
3611
mcp
ai.orgsdk
Hosted runtime for persistent agent teams, durable workflows, memory, schedules, and goals.
Agent Orchestration Autonomous Agents Knowledge & Memory
2
agentbay-mcp AOAuth
io.github.thomasjumper
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Knowledge & Memory Autonomous Agents Agent Orchestration
21
JustDeployOAuth
ai.justdeploy
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Cloud Platforms CI/CD & DevOps App Automation
2

Related MCP Servers

MCP Process Server
OS Automation Shell Access Command Line
Digital-Defiance
A
license
Not graded
quality
C
maintenance
Enables AI agents to launch and manage system processes with strict security controls through executable allowlists, resource monitoring, and output capture capabilities.
Updated 5 months ago (2026-03-28 19:00 UTC)
89
1
MIT
Background Process MCP
Command Line Shell Access
waylaidwanderer
A
license
Not graded
quality
D
maintenance
Enables LLMs to start, stop, and monitor long-running command-line processes in the background.
Updated 10 months ago (2025-11-07 09:29 UTC)
22
11
MIT
Background Process Management
Shell Access Command Line OS Automation
mizunashi-mana
F
license
Not graded
quality
D
maintenance
Enables AI agents to efficiently manage and monitor background processes, with features like process startup, termination, log retrieval, and resource management.
Updated 9 months ago (2025-11-25 19:30 UTC)
21
-
Terminal Capture MCP Server
Command Line Shell Access
zsCommander
F
license
Not graded
quality
B
maintenance
Enables AI agents to run commands, capture outputs, and manage background processes with filtering capabilities for debugging and monitoring.
Updated 2 months ago (2026-07-17 08:00 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/h004888/mcp_terminal_process'

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