Skip to main content
Glama
VZilvinskus

mcp-system-monitor

by VZilvinskus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

MCP System Monitor

A production-grade Model Context Protocol (MCP) server that provides Claude with comprehensive system monitoring and diagnostics capabilities.

What It Does

This MCP server gives Claude direct access to system metrics and diagnostics, enabling it to:

  • Monitor CPU, memory, and disk usage in real-time

  • Analyze running processes and resource consumption

  • Inspect network connections and listening ports

  • Monitor Docker containers and images

  • Access system logs via journalctl (Linux)

Perfect for system diagnostics, performance troubleshooting, DevOps automation, and infrastructure monitoring.

Related MCP server: System Monitor MCP Server

Features

Available Tools

  1. get_system_resources - Real-time system resource monitoring

    • CPU usage, cores, and load

    • Memory usage and swap statistics

    • Disk usage and filesystem info

    • System uptime and OS details

  2. list_processes - Process monitoring and analysis

    • Top processes by CPU or memory usage

    • Process state and resource consumption

    • Command line and user information

    • Sortable and filterable results

  3. get_network_connections - Network connection analysis

    • Active network connections

    • Listening ports and services

    • Connection states (ESTABLISHED, LISTEN, etc.)

    • Process-to-port mapping

  4. get_docker_status - Docker container monitoring

    • Running and stopped containers

    • Container status and health

    • Image inventory

    • Port mappings and resource usage

  5. get_system_logs - System log analysis (Linux only)

    • Recent journalctl entries

    • Filterable by priority level

    • Filterable by systemd unit

    • Structured log output

Installation

cd mcp-system-monitor
npm install
npm run build

Configuration

Claude Code Configuration

Add to your Claude Code MCP settings (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

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

Permissions

Some features require elevated permissions:

  • Docker status: User must be in the docker group

  • System logs: May require sudo access to journalctl (depending on system configuration)

  • Process details: Full process info may require elevated privileges

Example Usage with Claude Code

Once configured, you can ask Claude:

"What's my current CPU and memory usage?"

"Show me the top 10 processes by CPU usage"

"List all listening ports and which processes are using them"

"What Docker containers are running right now?"

"Show me the last 100 error-level system logs"

"Which process is using port 8080?"

"Is my disk usage getting high?"

Platform Support

  • CPU/Memory/Disk/Processes: All platforms (Linux, macOS, Windows)

  • Network connections: All platforms

  • Docker status: Requires Docker installation

  • System logs: Linux only (requires systemd/journalctl)

Gracefully degrades on platforms where features aren't available.

Development

# Watch mode for development
npm run dev

# Build for production
npm run build

# Start the server
npm start

Security Considerations

This server provides read-only access to system information. It does not:

  • Modify system configuration

  • Kill or start processes

  • Change permissions

  • Execute arbitrary commands

However, it does expose system information including:

  • Running processes and their arguments

  • Network connections

  • System logs

Only use in trusted environments and be mindful of what information you share.

Error Handling

The server includes comprehensive error handling for:

  • Missing system utilities (docker, journalctl)

  • Permission denied errors

  • Platform-specific features

  • Malformed data

  • Schema validation errors

Features that aren't available will return clear messages instead of errors.

Tech Stack

  • TypeScript for type safety

  • @modelcontextprotocol/sdk for MCP protocol

  • systeminformation for cross-platform system metrics

  • Zod for runtime schema validation

  • Native child_process for Docker and journalctl integration

Use Cases

  • DevOps: Automated system health checks

  • Troubleshooting: Quick diagnostics without leaving Claude

  • Monitoring: Resource usage tracking and alerting

  • Documentation: Generate system reports and inventories

  • Development: Debug resource leaks and performance issues

License

MIT

Available Tools

5 tools
get_docker_statusA

Get status of Docker containers (if Docker is available)

ParametersJSON Schema
NameRequiredDescriptionDefault
includeAllNoInclude stopped containers (default: false)

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It adds the important caveat that Docker may not be available, but it does not describe what happens when Docker is missing, what the returned status looks like, or that stopped containers are excluded by default beyond the schema hint.

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 entire description is one short, front-loaded sentence that communicates the action, resource, and key availability caveat. Every word earns its place with no redundant elaboration.

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?

This is a simple one-parameter read-only tool, and the description plus schema cover the core usage: what it does, when it applies, and the only parameter. With no output schema, a bit more detail about return format or failure behavior would improve completeness, but the missing information is minor given the tool's simplicity.

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 schema already provides 100% coverage for the single optional boolean parameter includeAll and documents its default value. The description adds no additional parameter-level meaning, so the baseline score of 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?

The description states a specific verb ('Get') and resource ('status of Docker containers'), making the tool's purpose immediately clear. It is naturally distinguished from sibling host-level tools like get_system_resources and list_processes.

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 includes a clear precondition: use it if Docker is available. It does not explicitly name alternatives or list when-not-to-use conditions, but the Docker-specific scope makes selection among the sibling tools straightforward.

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

get_network_connectionsB

Get active network connections and listening ports

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of connections to return (default: 50)

TDQS

B3.3/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 the full behavioral burden. It indicates read-only intent and scopes to 'active' connections, but does not explain output fields, privilege requirements, or how the tool behaves beyond the basic query.

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, front-loaded sentence with no redundancy. Every word contributes to purpose, making it an efficient and well-structured definition.

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 read-only tool with one optional parameter, the description is adequate but incomplete: it omits what fields each connection entry contains and provides no usage context. Since there is no output schema, a bit more detail on return structure would help an agent use results effectively.

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 fully covers the single parameter (limit) with a description and default value, so the tool description adds no additional parameter meaning. Baseline 3 applies because schema coverage is 100%.

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?

States a specific action (get) and precise resource ('active network connections and listening ports'). This clearly separates it from sibling tools like get_system_resources or list_processes, which target different system domains.

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?

Provides no guidance on when to choose this tool over alternatives or any exclusion criteria. The 'Get' phrasing implies a read operation, but there is no explicit context or comparison with sibling tools.

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

get_system_logsA

Get recent system logs from journalctl (Linux only)

ParametersJSON Schema
NameRequiredDescriptionDefault
unitNoFilter by systemd unit (e.g., 'docker', 'nginx')
linesNoNumber of log lines to return (default: 50)
priorityNoMinimum log priority level

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It communicates a read-only intent ('Get'), the source ('journalctl'), and the platform limitation ('Linux only'), but it does not mention potential permission requirements, large output, or behavior if journald is unavailable. Adequate but not detailed.

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 one short, front-loaded sentence with no filler. The parenthetical 'Linux only' adds a valuable constraint without wasted words, and every element contributes to understanding the tool.

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 read-only log tool with three optional, fully documented parameters, the description plus schema is mostly complete. It identifies the source and platform, and the schema covers defaults and filters; however, without an output schema, the exact return shape is left slightly implicit.

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 explains unit, lines, and priority, including the priority enum. The description adds no parameter-level meaning beyond the vague word 'recent', which does not clarify the default line count or filter semantics.

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 names a specific action ('Get'), resource ('system logs'), and mechanism ('journalctl'), plus the platform constraint ('Linux only'). This clearly differentiates it from siblings like list_processes and get_docker_status, which address different system aspects.

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 the tool is for retrieving systemd journal logs and restricts usage to Linux, but it does not explicitly explain when to choose this tool over the sibling tools or when not to use it. The usage context is inferable but not directly stated.

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

get_system_resourcesA

Get current CPU, memory, and disk usage statistics

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral transparency burden. 'Get' strongly implies a read-only operation, and the tool has no parameters or side-effect indicators, but the description does not disclose platform dependencies, potential permission requirements, or retry behavior. This is adequate for a simple status read but not rich.

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, front-loaded sentence with no filler. Every word contributes to specifying what the tool returns, making it easy for an agent to parse quickly.

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 zero-parameter tool, the description is largely complete: it names the metric domains and implies a current snapshot. However, it does not specify return units or output structure, and there is no output schema to compensate, leaving minor ambiguity for the agent about expected response formatting.

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 zero parameters, so the baseline is 4. The description adds useful meaning by naming the exact metric categories (CPU, memory, disk) that the agent can expect, which is valuable even though no input is required.

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 states a specific verb ('Get') and a precise resource scope: current CPU, memory, and disk usage statistics. It clearly distinguishes this tool from siblings like get_network_connections and list_processes, leaving no ambiguity about what resource domain it covers.

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 clearly implies when to use it: whenever current system resource usage is needed. It does not explicitly name alternatives or exclusion conditions, but the sibling list and the specific resource scope make the intended usage context obvious.

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

list_processesA

List running processes with CPU and memory usage, sorted by resource consumption

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of processes to return (default: 20)
sortByNoSort processes by (default: cpu)

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the sorting behavior and the reported metrics, but does not state whether this is a point-in-time snapshot, whether it covers all users' processes, or whether elevated permissions are needed. This is adequate but has clear gaps.

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, tight sentence with no wasted words. It front-loads the core action and then adds the key details about output and ordering.

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 operation with two self-documented parameters, the description is largely sufficient. However, the lack of an output schema and annotations leaves some ambiguity about exact return fields and process visibility scope, though this is a minor gap for this tool.

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%, with both 'limit' and 'sortBy' already documented including defaults and enum values. The description adds no new parameter semantics beyond implying that sorting relates to resource consumption, so the baseline score of 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?

The description uses a specific verb ('List'), a specific resource ('running processes'), and the data returned ('CPU and memory usage'), which makes the tool's purpose immediately clear. It is also clearly differentiated from siblings like get_system_resources and get_network_connections, which target different resources.

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 provides clear context for when this tool is appropriate: inspecting running processes and their resource consumption. It does not explicitly name alternatives or exclusion criteria, but the sibling names make the distinction apparent, and the intended use is unambiguous.

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.

  1. 5 tool updatesv1.0.0
    • First observedget_docker_status
    • First observedget_network_connections
    • First observedget_system_logs
    • First observedget_system_resources
    • First observedlist_processes
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct monitoring domain: system resources, network, processes, Docker, and logs. There is no overlap or ambiguity between the tools.

Naming Consistency5/5

All tool names follow the same get_<object> pattern, using snake_case consistently. The naming is predictable and easy to navigate.

Tool Count5/5

Five tools is a well-scoped size for a system monitoring server, covering the primary monitoring surfaces without unnecessary bloat.

Completeness4/5

The tool surface covers the main system monitoring areas: resources, network, processes, containers, and logs. Minor gaps like disk I/O statistics or service management exist, but the core monitoring workflows are well supported.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • System Monitor MCP Server

    PraveerT
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides system monitoring and management capabilities for Claude CLI, allowing users to view system information, track resource usage, and manage processes through natural language commands.
    -

  • System Info MCP Server

    srirama7
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables comprehensive system monitoring and diagnostics through 18 tools that provide detailed information about CPU, memory, disk usage, network interfaces, running processes, battery status, hardware details, and temperature monitoring. Allows users to query system information and performance metrics through natural language interactions.
    7 npm
    ISC

  • log-analyzer-mcp

    yufeizhou666
    F
    license
    B
    quality
    D
    maintenance
    Enables log analysis, searching, counting, and system metrics retrieval (CPU, memory, disk) via natural language, using 5 tools that can be integrated with Claude Code.
    5
    -