Which integrations are available for this server?

Provides tools for listing Docker containers, checking port conflicts, tailing system and container logs, monitoring disk usage, and CPU/RAM usage.

How do I use MCP Terminal Monitor?

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 Monitor show me disk usage on root" 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 Monitor

by pavanvzm

Overview Schema Related Servers Score Discussions

JavaScript

Local

🔧 MCP Terminal Monitor

demo

License: MIT npm version

Production-ready Model Context Protocol (MCP) Server for system monitoring. Provides AI agents with real-time access to Docker containers, system resources, ports, and logs.

🚀 Quick Start

npx mcp-terminal-monitor

Or install globally:

npm install -g mcp-terminal-monitor
mcp-terminal-monitor

Related MCP server: docker-mcp-server

📋 Available Tools

Tool	Description
`list_docker_containers`	List Docker containers with status, ports, and health
`check_port_conflicts`	Check if a specific port is in use on the system
`tail_system_logs`	Retrieve recent system or Docker container logs
`get_disk_usage`	Get disk usage statistics for filesystems
`monitor_cpu_ram`	Monitor CPU and RAM usage with configurable sampling

🔧 Features

🐳 Docker Integration - List containers, fetch logs, monitor health
🔌 Port Monitoring - Detect port conflicts before deployment
📊 System Metrics - Real-time CPU, RAM, and disk usage
📝 Log Access - System and container log streaming
🔒 Read-Only Safety - All operations are non-destructive
⚡ Low Latency - Optimized system calls for fast responses
🛡️ Strict Validation - Zod schemas ensure safe argument parsing
🌐 Cross-Platform - Works on Linux, macOS, and Windows

🏗 Architecture

graph TD
    A[AI Client] -->|MCP Protocol| B[MCP Terminal Monitor Server]
    B -->|Docker API| C[Docker Daemon]
    B -->|System Calls| D[OS Kernel]
    B -->|Network Stats| E[Netstat/Lsof]
    B -->|Process Info| F[SystemInformation]
    
    C --> G[Containers]
    D --> H[CPU/RAM/Disk]
    E --> I[Port Conflicts]
    F --> J[System Metrics]

📖 Usage Examples

List Docker Containers

{
  "name": "list_docker_containers",
  "arguments": {
    "all": true,
    "limit": 10
  }
}

Check Port Conflicts

{
  "name": "check_port_conflicts",
  "arguments": {
    "port": 3000,
    "host": "0.0.0.0"
  }
}

Tail System Logs

{
  "name": "tail_system_logs",
  "arguments": {
    "service": "nginx",
    "lines": 50,
    "follow": false
  }
}

Get Disk Usage

{
  "name": "get_disk_usage",
  "arguments": {
    "path": "/"
  }
}

Monitor CPU & RAM

{
  "name": "monitor_cpu_ram",
  "arguments": {
    "interval": 1000,
    "samples": 3
  }
}

🔌 MCP Configuration

Add to your MCP client configuration:

{
  "mcpServers": {
    "terminal-monitor": {
      "command": "npx",
      "args": ["mcp-terminal-monitor"]
    }
  }
}

🛠 Development

# Clone repository
git clone https://github.com/yourusername/mcp-terminal-monitor.git
cd mcp-terminal-monitor

# Install dependencies
npm install

# Run in development mode
npm start

# Build for production
npm run build

📦 Requirements

Node.js >= 18.0.0
Docker daemon (for Docker-related tools)
Root/sudo access may be required for some system calls

📄 License

MIT © Your Name

Built with @modelcontextprotocol/sdk

Available Tools

5 tools

check_port_conflictsC

Check if a specific port is in use on the system. Helps identify port conflicts.

ParametersJSON Schema

Name	Required	Description	Default
`host`	No	Host address to check	0.0.0.0
`port`	Yes	Port number to check (1-65535)

TDQS

C2.9/5.0

Behavior2/5

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

Without annotations, the description carries the full burden. It only says 'check' implying a read operation, but does not disclose what happens if the port is in use (e.g., returns a boolean or error), or any side effects. No permissions or limitations are mentioned.

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 very short (two sentences) with no wasted words. It is front-loaded with the core action.

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 tool, the description covers the basics, but it lacks explanation of the return value or error behavior. Since there is no output schema, the description should clarify what the agent can expect to receive.

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 already describes both parameters (host and port) with default and constraints. The description adds no additional meaning beyond 'check a specific port'.

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 ('check') and the resource ('if a specific port is in use'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools which deal with disk, Docker, CPU/RAM, or logs.

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 given on when to use this tool versus alternatives. It does not mention scenarios where port conflict checking is appropriate or when other tools should be preferred.

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

get_disk_usageB

Get disk usage statistics for filesystems. Shows size, used, available space.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Mount point or path to check	/

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It states what data is shown (size, used, available) but omits important traits like whether it is read-only, permission requirements, error behavior for invalid paths, or whether it reports on all filesystems or just the specified path.

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 efficiently communicates the purpose and output. It is front-loaded with the action and resource, and every word contributes meaning. No extraneous content.

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 tool with one optional parameter and no output schema, the description provides essential information. However, it lacks details such as what happens when path is omitted (defaults to root, per schema) and whether multiple filesystems are reported. 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 100%, so the baseline is 3. The description does not add any new meaning beyond the schema's description of the 'path' parameter ('Mount point or path to check'). The parameter is simple and well-defined by schema.

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 gets disk usage statistics for filesystems, which is specific and distinct from sibling tools that focus on ports, containers, CPU/RAM, and logs. The verb 'get' and resource 'disk usage statistics' are precise, though it could explicitly state that it shows all filesystems or just one.

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. The description does not mention when not to use it or suggest alternatives like other monitoring tools. Usage context is only implied by the tool name and siblings.

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

list_docker_containersA

List Docker containers with their status, ports, and health. Read-only operation.

ParametersJSON Schema

Name	Required	Description	Default
`all`	No	Include stopped containers
`limit`	No	Maximum number of containers to return

TDQS

A4.2/5.0

Behavior4/5

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

The description explicitly states the operation is read-only, which is key behavioral information. It also describes the data returned (status, ports, health). Without annotations, the description provides adequate transparency for safe 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 highly concise with two sentences. The first sentence covers purpose and scope, the second reinforces the read-only nature. No redundant 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?

The description covers the main purpose and return fields, which is sufficient for a list operation without output schema. It could mention pagination or sorting but is otherwise complete for typical use.

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?

Both parameters have full schema descriptions (100% coverage), so the description does not need to add extra meaning. It does not provide additional context beyond the schema, hence baseline score.

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 verb ('List'), resource ('Docker containers'), and the specific information included ('status, ports, and health'). It also distinguishes from siblings by focusing on container listing, while siblings address other system monitoring tasks.

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 indicates it is a read-only operation, implying safe usage. While it doesn't explicitly state when to use this over alternatives, the sibling tools are sufficiently different that the purpose is clear.

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

monitor_cpu_ramB

Monitor CPU and RAM usage with configurable sampling. Returns current load and memory stats.

ParametersJSON Schema

Name	Required	Description	Default
`samples`	No	Number of samples to collect
`interval`	No	Sampling interval in milliseconds

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavior. It mentions returning 'current load and memory stats' but does not clarify side effects, permissions, or whether it is read-only. Minimal transparency.

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?

Single sentence that is front-loaded and to the point. 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?

Simple tool with no output schema; description could specify return format (e.g., CPU%, RAM used/total). Adequate but not fully complete given lack of output schema.

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 both parameters (samples, interval) are documented. Description adds 'configurable sampling' but doesn't surpass schema detail. Baseline 3.

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

Purpose5/5

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

The description clearly states the tool monitors CPU and RAM usage with configurable sampling. It distinguishes from sibling tools like check_port_conflicts, get_disk_usage, etc., which cover different system resources.

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. Does not specify context for use or exclusions. For a monitoring tool, this is a gap.

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

tail_system_logsB

Retrieve recent system or Docker container logs. Supports filtering by service name.

ParametersJSON Schema

Name	Required	Description
`lines`	No	Number of log lines to retrieve
`follow`	No	Follow logs in real-time (not recommended for MCP)
`service`	No	Service/container name to filter logs (optional for system logs)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral burden. It only says 'retrieve' (implies read) but does not disclose safety, auth needs, rate limits, or warnings like the schema's note that 'follow' is not recommended for MCP.

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 concise with two sentences, front-loading the purpose. However, it omits important details that could be included without verbosity.

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?

With no output schema and no annotations, the description is incomplete. It does not explain what 'recent' means, log format, difference between system and Docker logs, or default behavior. Leaves gaps for an agent.

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 100% with parameter descriptions. The description adds only that filtering by service is supported, which is already in the schema. No additional 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 tool retrieves recent system or Docker container logs with filtering by service name. It distinctly differs from sibling tools like check_port_conflicts or get_disk_usage.

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 usage for log retrieval but does not explicitly state when to choose this tool over siblings or when not to use it (e.g., needing real-time monitoring). No alternatives are mentioned.

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.0Jul 8, 2026
- First observedcheck_port_conflicts
- First observedget_disk_usage
- First observedlist_docker_containers
- First observedmonitor_cpu_ram
- First observedtail_system_logs

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct system resource or aspect: ports, disk usage, Docker containers, CPU/RAM, and logs. No two tools have overlapping purposes, making it clear which to use for a given monitoring task.

Naming Consistency5/5

All tool names follow the consistent 'verb_noun' pattern using lowercase with underscores, e.g., 'check_port_conflicts', 'get_disk_usage'. The verbs are appropriate and uniform.

Tool Count5/5

With 5 tools, the server provides a focused yet comprehensive set for system monitoring. It covers essential areas (CPU, RAM, disk, ports, Docker, logs) without being overwhelming or too sparse.

Completeness4/5

The tool set covers core monitoring tasks, but lacks network usage and process monitoring. These are minor gaps for a general monitoring server; agents can still accomplish many common tasks.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

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
HivePulse B
io.github.srotzin
Real-time health monitoring and heartbeat tracking for agent services
Monitoring Observability Agent Orchestration
2
Netdata
io.github.netdata
Real-time infrastructure monitoring with metrics, logs, alerts, and ML-based anomaly detection.
Monitoring Observability
277,495
runvouch B
com.runvouch
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
Monitoring Observability
71

Related MCP Servers

System Monitor MCP Server
Monitoring Observability
Dev-Herni
F
license
Not graded
quality
D
maintenance
Gives AI agents real-time access to system metrics, process management, and container orchestration.
Updated 3 months ago (2026-05-22 09:17 UTC)
-
docker-mcp-server
Virtualization Developer Tools
friendlygeorge
A
license
B
quality
A
maintenance
Enables AI agents to manage Docker containers, images, Compose stacks, health checks, and logs through a unified MCP interface, ensuring containers stay running with self-healing capabilities.
Updated 2 months ago (2026-06-24 09:04 UTC)
31
91
5
MIT
mcp-system-monitor
Monitoring Observability
VZilvinskus
F
license
A
quality
D
maintenance
Enables Claude to monitor CPU, memory, disk, processes, network connections, Docker containers, and system logs for system diagnostics and troubleshooting.
Updated 5 months ago (2026-04-03 20:14 UTC)
5
-
mcp-homelab-server
Virtualization AI & Machine Learning Command Line
Proto-labs-rnd
A
license
Not graded
quality
D
maintenance
Enables AI agents to manage a homelab by providing tools for Docker, Ollama, and system monitoring through the Model Context Protocol.
Updated 5 months ago (2026-03-29 23:55 UTC)
MIT

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/pavanvzm/Build-a-Developer-Workflow-MCP-Server'

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