Skip to main content
Glama
dknell

System Information MCP Server

by dknell
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

System Information MCP Server

A Model Context Protocol (MCP) server that provides real-time system information and metrics. This server exposes CPU usage, memory statistics, disk information, network status, and running processes through a standardized MCP interface.

Features

🛠️ Tools Available

  • get_cpu_info - Retrieve CPU usage, core counts, frequency, and load average

  • get_memory_info - Get virtual and swap memory statistics

  • get_disk_info - Disk usage information for all mounts or specific paths

  • get_network_info - Network interface information and I/O statistics

  • get_process_list - Running processes with sorting and filtering options

  • get_system_uptime - System boot time and uptime information

  • get_temperature_info - Temperature sensors and fan speeds (when available)

📚 Resources Available

  • system://overview - Comprehensive system overview with all metrics

  • system://processes - Current process list resource

⭐ Key Features

  • Real-time metrics with configurable caching

  • Cross-platform support (Windows, macOS, Linux)

  • Security-focused with sensitive data filtering

  • Performance optimized with intelligent caching

  • Comprehensive error handling

  • Environment variable configuration

Related MCP server: DeviceMCP

Installation

Using uvx (Recommended)

The easiest way to install and use this MCP server is with uvx:

uvx install mcp-system-info

Then configure it in your MCP client (like Claude Desktop):

{
  "mcpServers": {
    "system-info": {
      "command": "uvx",
      "args": ["mcp-system-info"]
    }
  }
}

Development Installation

For local development:

  1. Clone the repository:

    git clone <repository-url>
cd mcp-system-info

  2. Install dependencies:

    uv sync

  3. Run the server:

    uv run mcp-system-info

Development

Project Structure

mcp-system-info/
├── src/
│   └── system_info_mcp/
│       ├── __init__.py
│       ├── server.py          # Main FastMCP server
│       ├── tools.py           # Tool implementations
│       ├── resources.py       # Resource handlers
│       ├── config.py          # Configuration management
│       └── utils.py           # Utility functions
├── tests/                     # Comprehensive test suite
├── pyproject.toml            # Project configuration
└── README.md

Development Setup

  1. Install development dependencies:

    uv sync --dev

  2. Run tests:

    uv run pytest

  3. Run tests with coverage:

    uv run pytest --cov=system_info_mcp --cov-report=term-missing

  4. Format code:

    uv run black src/ tests/

  5. Lint code:

    uv run ruff check src/ tests/

  6. Type checking:

    uv run mypy src/

Building and Publishing

Build the Package

# Build distribution files
uv build

This creates distribution files in the dist/ directory:

  • mcp_system_info-*.whl (wheel file)

  • mcp_system_info-*.tar.gz (source distribution)

Local Testing with uvx

Test the package locally before publishing:

# Test running the command directly from wheel file
uvx --from ./dist/mcp_system_info-*.whl mcp-system-info

# Test with environment variables
SYSINFO_LOG_LEVEL=DEBUG uvx --from ./dist/mcp_system_info-*.whl mcp-system-info

Publishing to PyPI

# Publish to PyPI (requires PyPI account and token)
uv publish

# Or publish to TestPyPI first
uv publish --repository testpypi

Note: You'll need to:

  1. Create a PyPI account at https://pypi.org

  2. Generate an API token in your account settings

  3. Configure uv with your credentials or use environment variables

Environment Configuration

The server supports configuration through environment variables:

Core Settings

  • SYSINFO_CACHE_TTL - Cache time-to-live in seconds (default: 5)

  • SYSINFO_MAX_PROCESSES - Maximum processes to return (default: 100)

  • SYSINFO_ENABLE_TEMP - Enable temperature sensors (default: true)

  • SYSINFO_LOG_LEVEL - Logging level (default: INFO)

Transport Configuration

  • SYSINFO_TRANSPORT - Transport protocol: stdio, sse, or streamable-http (default: stdio)

  • SYSINFO_HOST - Host to bind to for HTTP transports (default: localhost)

  • SYSINFO_PORT - Port to bind to for HTTP transports (default: 8001)

  • SYSINFO_MOUNT_PATH - Mount path for SSE transport (default: /mcp)

Transport Modes

1. STDIO (Default)

# Uses standard input/output - no network port
uv run mcp-system-info

2. SSE (Server-Sent Events)

# HTTP server with real-time streaming
SYSINFO_TRANSPORT=sse SYSINFO_PORT=8001 uv run mcp-system-info
# Server will be available at http://localhost:8001/mcp

3. Streamable HTTP

# HTTP server with request/response
SYSINFO_TRANSPORT=streamable-http SYSINFO_PORT=9000 uv run mcp-system-info

Complete Example:

SYSINFO_TRANSPORT=sse \
SYSINFO_HOST=0.0.0.0 \
SYSINFO_PORT=8001 \
SYSINFO_CACHE_TTL=10 \
SYSINFO_LOG_LEVEL=DEBUG \
uv run mcp-system-info

Usage Examples

Tool Usage

Get CPU Information

# Basic CPU info
{
  "name": "get_cpu_info_tool",
  "arguments": {
    "interval": 1.0,
    "per_cpu": false
  }
}

Get Process List

# Top 10 processes by memory usage
{
  "name": "get_process_list_tool", 
  "arguments": {
    "limit": 10,
    "sort_by": "memory",
    "filter_name": "python"
  }
}

Get Disk Information

# All disk usage
{
  "name": "get_disk_info_tool",
  "arguments": {}
}

# Specific path
{
  "name": "get_disk_info_tool",
  "arguments": {
    "path": "/home"
  }
}

Resource Usage

System Overview

# Request comprehensive system overview
{
  "uri": "system://overview"
}

Process List Resource

# Get top processes resource
{
  "uri": "system://processes" 
}

Integration with Claude Desktop

Adding to Claude Desktop

  1. Locate your Claude Desktop config file:

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

  2. Add the MCP server configuration:

Using uvx (Recommended)

{
  "mcpServers": {
    "system-info": {
      "command": "uvx",
      "args": ["mcp-system-info"],
      "env": {
        "SYSINFO_CACHE_TTL": "10",
        "SYSINFO_LOG_LEVEL": "INFO"
      }
    }
  }
}

For Local Development

{
  "mcpServers": {
    "system-info": {
      "command": "uv",
      "args": [
        "--directory", 
        "/path/to/mcp-system-info", 
        "run", 
        "mcp-system-info"
      ],
      "env": {
        "SYSINFO_TRANSPORT": "stdio",
        "SYSINFO_CACHE_TTL": "10",
        "SYSINFO_LOG_LEVEL": "INFO"
      }
    }
  }
}

For HTTP Transport (SSE)

{
  "mcpServers": {
    "system-info-http": {
      "command": "uvx",
      "args": ["mcp-system-info"],
      "env": {
        "SYSINFO_TRANSPORT": "sse",
        "SYSINFO_HOST": "localhost",
        "SYSINFO_PORT": "8001",
        "SYSINFO_MOUNT_PATH": "/mcp"
      }
    }
  }
}

  1. Restart Claude Desktop to load the new server.

Using with Claude

Once configured, you can ask Claude to:

  • "What's my current CPU usage?"

  • "Show me the top 10 processes using the most memory"

  • "How much disk space is available?"

  • "What's my system uptime?"

  • "Give me a complete system overview"

Testing

Running Tests

# Run all tests
uv run pytest

# Run with verbose output
uv run pytest -v

# Run specific test file
uv run pytest tests/test_tools.py

# Run with coverage report
uv run pytest --cov=system_info_mcp --cov-report=html

Test Structure

  • tests/test_config.py - Configuration validation tests

  • tests/test_tools.py - Tool implementation tests

  • tests/test_resources.py - Resource handler tests

  • tests/test_utils.py - Utility function tests

All tests use mocked dependencies for consistent, fast execution across different environments.

Performance Considerations

  • Caching: Intelligent caching reduces system calls and improves response times

  • Configurable intervals: Adjust cache TTL based on your needs

  • Lazy loading: Temperature sensors and other optional features load only when needed

  • Async support: Built on FastMCP for efficient async operations

Security Features

  • Read-only operations: No system modification capabilities

  • Sensitive data filtering: Command-line arguments are filtered for passwords, tokens, etc.

  • Input validation: All parameters are validated before processing

  • Error isolation: Failures in one tool don't affect others

Platform Support

  • macOS - Full support including temperature sensors on supported hardware

  • Linux - Full support with hardware-dependent sensor availability

  • Windows - Full support with platform-specific optimizations

Troubleshooting

Common Issues

  1. Permission errors: Some system information may require elevated privileges

  2. Missing sensors: Temperature/fan data availability varies by hardware

  3. Performance impact: Reduce cache TTL or limit process counts for better performance

Debug Mode

Enable debug logging for troubleshooting:

SYSINFO_LOG_LEVEL=DEBUG uv run mcp-system-info

Verifying Installation

Test that tools work correctly:

uv run python -c "from system_info_mcp.tools import get_cpu_info; print(get_cpu_info())"

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes with tests

  4. Run the full test suite

  5. Submit a pull request

Code Standards

  • Follow PEP 8 style guidelines

  • Add type hints to all functions

  • Write tests for new functionality

  • Update documentation as needed

License

[Add your license information here]

Support

[Add support information here]

Available Tools

7 tools
get_cpu_info_toolA

Retrieve CPU usage and information.

Args: interval: Measurement interval in seconds (default: 1.0) per_cpu: Include per-CPU core breakdown (default: false)

ParametersJSON Schema
NameRequiredDescriptionDefault
intervalNo
per_cpuNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/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 burden. It implies a read-only operation via 'Retrieve', but does not disclose potential effects, permissions, or rate limits. Adequate but minimal.

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 concise—one sentence plus a clean Args block. No wasted words; information is front-loaded.

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?

Given the presence of an output schema and the tool's simplicity, the description covers the key aspects. Minor gap: no mention that it is non-destructive, but that's implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by detailing each parameter's meaning, default values, and options (interval in seconds, per_cpu boolean).

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 it retrieves CPU usage and information, using a specific verb and resource. It distinguishes well from sibling tools that cover disk, memory, network, etc.

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 other system info tools. No when-not or context is given.

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

get_disk_info_toolB

Retrieve disk usage information.

Args: path: Specific path to check (default: all mounted disks)

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations exist, so the description carries full burden. It does not disclose whether the operation is read-only, has side effects, requires permissions, or any performance implications. The read-only nature can be inferred from the tool's name and purpose, but explicit disclosure is lacking.

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 one main sentence and an 'Args' block for the parameter. It is front-loaded with the purpose, and the parameter documentation is minimal yet sufficient. No wasted sentences.

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 tool has an output schema, so return values need not be described. However, the description lacks details about potential errors, behavior on invalid paths, or whether it requires elevated privileges. For a simple informational tool, it is functional but leaves some gaps given no annotations.

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?

With schema description coverage at 0%, the description compensates by explaining the 'path' parameter: 'Specific path to check (default: all mounted disks)'. This adds meaning beyond the raw schema, clarifying optionality and default behavior.

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 states 'Retrieve disk usage information', which clearly identifies the resource (disk usage) and action (retrieve). It distinguishes from siblings like get_cpu_info_tool by specifying disk-specific functionality.

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 (e.g., other system info tools). No prerequisites, exclusions, or recommended contexts are provided.

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

get_memory_info_toolA

Retrieve memory usage statistics.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/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 burden. It only states 'retrieve' which implies a read operation, but no details about permissions, side effects, or return format are disclosed. The existence of an output schema may compensate, but without seeing it, the description alone is insufficient.

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 concise sentence with no unnecessary words. For a tool with no parameters, this is appropriately sized, though it could be slightly more informative without losing conciseness.

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 parameters and an existing output schema, the description is minimally adequate. However, it lacks specifics about what the returned statistics include (e.g., total, used, free), which would help the agent understand the output without relying solely on the 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?

There are no parameters, and schema description coverage is 100%, so the description does not need to add parameter info. Baseline is 4.

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 the verb 'Retrieve' and specifies the resource 'memory usage statistics', clearly distinguishing it from sibling tools like get_cpu_info_tool 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 Guidelines3/5

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

No explicit when-to-use or alternatives are given, but the context of sibling tools (e.g., get_cpu_info_tool) implies this tool is for memory statistics. The guidance is implied rather than stated.

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

get_network_info_toolA

Retrieve network interface information and statistics.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

No annotations provided; description carries full burden. It states retrieval without indicating permissions, side effects, or specifics of output. Adequate for a simple read-only tool but could be more 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?

Single sentence of 5 words conveys the purpose without waste. Front-loaded and efficient.

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

Completeness5/5

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

For a simple tool with no parameters and an output schema, the description covers the essential purpose. No missing context given the complexity.

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?

Tool has zero parameters, and schema coverage is 100%. Per guidelines, 0 params yields baseline 4. Description adds no parameter info, which is acceptable.

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 'Retrieve network interface information and statistics', specifying the verb (retrieve) and resource (network interface info/statistics). It distinguishes itself from sibling tools that focus on CPU, disk, memory, etc.

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 guidance on when to use or not use, but usage is implied as a standard info retrieval tool. Sibling tools cover other system resources, so no direct alternative is needed. Lacks exclusions or context.

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

get_process_list_toolA

Retrieve list of running processes.

Args: limit: Maximum number of processes to return (default: 50) sort_by: Sort criteria - cpu, memory, name, pid (default: cpu) filter_name: Filter processes by name pattern

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
sort_byNocpu
filter_nameNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, and the description fails to disclose behavioral traits such as permission requirements, rate limits, or whether the list is a snapshot. It implies a read operation but offers no explicit confirmation.

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 concise, front-loaded with the main purpose, and parameter documentation follows cleanly. Every sentence is necessary and no words are wasted.

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?

While an output schema exists (reducing need for return value descriptions), the description lacks context about the tool's scope (e.g., all processes vs. user-specific) and any limitations, leaving some gaps in completeness.

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?

With 0% schema description coverage, the description effectively adds meaning for all three parameters: limit (max number), sort_by (criteria and defaults), and filter_name (pattern). This compensates for the missing schema descriptions.

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 'Retrieve list of running processes' with a specific verb ('retrieve') and resource ('list of running processes'), distinguishing it from sibling tools like get_cpu_info_tool.

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 (e.g., other info tools), nor any exclusions or prerequisites. It only lists parameters without usage context.

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

get_system_uptime_toolA

Retrieve system uptime and boot information.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention that the tool is read-only, safe to call, or any potential requirements or side effects. The brevity leaves important behavioral context undocumented.

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 with no wasted words. It is concise and front-loaded with the purpose.

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?

Given the tool's simplicity (no params, read-only retrieval) and the presence of an output schema, the description is almost complete. However, it could briefly note the nature of the output (e.g., timestamp or dictionary), but this is not essential.

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 no parameters, so schema coverage is 100% by default. The description adds no parameter information, which is acceptable since none exist. Baseline for zero parameters is 4.

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 'Retrieve' and the resource 'system uptime and boot information', which is specific and distinguishes it from sibling tools like get_cpu_info_tool and get_disk_info_tool.

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. Sibling tools exist for other system information, but the description does not specify when uptime info is needed or exclude other tools.

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

get_temperature_info_toolB

Retrieve system temperature sensors (when available).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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 must fully disclose behavior. It only mentions 'when available,' leaving unclear what happens when sensors are unavailable (e.g., returns null, empty, or error). No details on permissions, rate limits, or other side effects are given, which is a significant gap for a retrieve operation.

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, front-loaded sentence that conveys the essential purpose without unnecessary words. It earns its place by being minimal and clear, though a slightly longer explanation of fallback behavior could be beneficial without harming conciseness.

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 simplicity, no parameters, and presence of an output schema (so return format is defined elsewhere), the description is mostly complete. However, it lacks clarity on what happens when temperature sensors are not available, which is a notable gap for a system info tool.

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 no parameter info, but none is needed since the schema has no properties. The 100% schema description coverage is irrelevant here.

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 'Retrieve system temperature sensors (when available)' uses a specific verb and clearly identifies the resource (system temperature sensors), distinguishing it from sibling tools like get_cpu_info_tool and get_memory_info_tool. The 'when available' qualifier adds useful context, though it doesn't fully elaborate on error handling.

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 retrieving temperature data when sensors are present, but provides no explicit guidance on when to use this tool versus alternatives. Siblings are clearly different info tools, so context is implied, but no exclusions or when-not-to-use scenarios 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.

  1. 7 tool updates
    • First observedget_cpu_info_tool
    • First observedget_disk_info_tool
    • First observedget_memory_info_tool
    • First observedget_network_info_tool
    • First observedget_process_list_tool
    • First observedget_system_uptime_tool
    • First observedget_temperature_info_tool
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct system resource (CPU, disk, memory, network, processes, uptime, temperature) with no overlap, ensuring unambiguous selection.

Naming Consistency5/5

All tool names follow a consistent 'get_<resource>_info_tool' pattern, making naming predictable and easy to navigate.

Tool Count5/5

Seven tools is an appropriate scope for a system information server, covering major metrics without bloat or deficiency.

Completeness5/5

The tool surface covers essential system resources comprehensively, with no obvious missing operations for its stated purpose.

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

  • 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.
    24
    ISC

  • DeviceMCP

    JahidHasanCO
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides cross-platform device information including system specs, battery status, storage, and memory details for Windows, macOS, Linux, and Android through a Model Context Protocol server.
    -

  • System Stats MCP Server

    orkuhh
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides real-time Linux system monitoring for CPU load, memory usage, disk space, and process activity. This server enables users to retrieve comprehensive performance metrics and resource utilization data through a standardized interface.
    -

Appeared in Searches

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/dknell/mcp-system-info'

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