Skip to main content
Glama
manalejandro

MCP ProcFS Server

by manalejandro
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

MCP ProcFS Server

License: MIT Node.js Version

A powerful Model Context Protocol (MCP) server for reading and modifying Linux /proc filesystem values. Provides both JSON-RPC (stdio) and Server-Sent Events (SSE) interfaces with full Swagger API documentation.

Features

  • 🔍 Comprehensive ProcFS Access: Read and write to /proc filesystem

  • 🎛️ System Monitoring: CPU, memory, load, network, and disk statistics

  • ⚙️ Sysctl Management: Read and modify kernel parameters

  • 🔧 Process Control: Monitor and manage processes (priority, affinity, signals)

  • 📡 Dual Protocols: JSON-RPC over stdio and HTTP with SSE

  • 📚 Full API Documentation: Interactive Swagger UI

  • 🔐 Type-Safe: Written in TypeScript with comprehensive type definitions

  • ✅ Validated: Zod schemas for request/response validation

Related MCP server: mcp-infra

Installation

From npm

npm install -g @mcp/procfs-server

From source

git clone https://github.com/user/mcp-proc.git
cd mcp-proc
npm install
npm run build

Quick Start

JSON-RPC Server (stdio)

# Start the MCP server on stdio
mcp-procfs

# Or with npm
npm start

HTTP Server with SSE

# Start HTTP server on port 3000
npm run start:sse

# Custom port
PORT=8080 npm run start:sse

Then open your browser to:

Usage

As MCP Tool

Configure in your MCP client (e.g., Claude Desktop):

{
  "mcpServers": {
    "procfs": {
      "command": "mcp-procfs"
    }
  }
}

Available Tools

System Information

  • get_cpu_info: Get detailed CPU information

  • get_memory_info: Get memory statistics

  • get_load_average: Get system load average

  • get_network_stats: Get network interface statistics

  • get_disk_stats: Get disk I/O statistics

ProcFS Operations

  • read_procfs: Read any file from /proc

  • write_procfs: Write to writable /proc files

Process Management

  • get_process_info: Get detailed process information

  • list_processes: List all process IDs

  • set_process_priority: Change process nice value

  • set_process_affinity: Set CPU affinity

Sysctl Management

  • read_sysctl: Read kernel parameter

  • write_sysctl: Modify kernel parameter

  • list_sysctl: List all parameters

Example: Using HTTP API

# Get CPU information
curl http://localhost:3000/api/cpu

# Get memory information
curl http://localhost:3000/api/memory

# Read a sysctl parameter
curl http://localhost:3000/api/sysctl/net.ipv4.ip_forward

# Write a sysctl parameter (requires permissions)
curl -X POST http://localhost:3000/api/sysctl \
  -H "Content-Type: application/json" \
  -d '{"key": "net.ipv4.ip_forward", "value": 1}'

# Get process information
curl http://localhost:3000/api/processes/1

# Read custom procfs file
curl "http://localhost:3000/api/procfs?path=sys/kernel/hostname"

Example: Using JSON-RPC

import { MCPProcFSServer } from '@mcp/procfs-server';

const server = new MCPProcFSServer();
await server.run();

Example: Direct Library Usage

import { ProcFSReader, ProcFSWriter } from '@mcp/procfs-server';

const reader = new ProcFSReader();
const writer = new ProcFSWriter();

// Get CPU info
const cpuInfo = await reader.getCPUInfo();
console.log(cpuInfo);

// Get memory info
const memInfo = await reader.getMemInfo();
console.log(memInfo);

// Read sysctl
const param = await writer.readSysctl('net.ipv4.ip_forward');
console.log(param);

// Write sysctl (requires root)
await writer.writeSysctl('net.ipv4.ip_forward', 1);

API Documentation

When running the HTTP server, full interactive API documentation is available at:

http://localhost:3000/api-docs

The documentation includes:

  • All endpoints with request/response schemas

  • Try-it-out functionality

  • Example requests and responses

  • Authentication requirements

API Endpoints

Method

Endpoint

Description

GET

/health

Health check

GET

/api/cpu

CPU information

GET

/api/memory

Memory information

GET

/api/load

Load average

GET

/api/network

Network statistics

GET

/api/disk

Disk statistics

GET

/api/procfs

Read procfs file

POST

/api/procfs

Write procfs file

GET

/api/sysctl

List sysctl parameters

GET

/api/sysctl/:key

Read sysctl parameter

POST

/api/sysctl

Write sysctl parameter

GET

/api/processes

List all processes

GET

/api/processes/:pid

Get process info

POST

/api/processes/:pid/priority

Set process priority

GET

/mcp/sse

SSE endpoint

POST

/mcp/rpc

JSON-RPC endpoint

MCP Resources

The server exposes the following MCP resources:

  • procfs://cpuinfo - CPU information

  • procfs://meminfo - Memory information

  • procfs://loadavg - Load average

  • procfs://net/dev - Network statistics

  • procfs://diskstats - Disk statistics

Permissions

Some operations require elevated permissions:

  • Read-only operations: Most read operations work without special permissions

  • Write operations: Require appropriate permissions (usually root)

  • Process management: Some operations require CAP_SYS_NICE or root

  • Sysctl writes: Usually require root or specific capabilities

Running with elevated permissions

# Run with sudo (not recommended for production)
sudo mcp-procfs

# Better: Use capabilities
sudo setcap cap_sys_nice,cap_sys_admin+ep $(which node)
mcp-procfs

Development

Setup

npm install
npm run build

Development Mode

npm run dev  # Watch mode with hot reload

Testing

npm test              # Run tests
npm run test:watch    # Watch mode
npm run test:coverage # Coverage report

Linting

npm run lint          # Check code
npm run format        # Format code

Architecture

mcp-proc/
├── src/
│   ├── lib/
│   │   ├── procfs-reader.ts    # ProcFS reading logic
│   │   └── procfs-writer.ts    # ProcFS writing logic
│   ├── types/
│   │   ├── procfs.ts           # ProcFS type definitions
│   │   ├── mcp.ts              # MCP protocol types
│   │   └── schemas.ts          # Zod validation schemas
│   ├── server.ts               # MCP JSON-RPC server
│   ├── server-sse.ts           # HTTP/SSE server
│   ├── cli.ts                  # JSON-RPC CLI entry
│   ├── cli-sse.ts              # HTTP/SSE CLI entry
│   └── index.ts                # Main exports
├── scripts/
│   ├── setup.sh                # Setup script
│   ├── build.sh                # Build script
│   └── release.sh              # Release script
└── tests/                      # Test files

Technology Stack

  • Runtime: Node.js 18+

  • Language: TypeScript

  • Validation: Zod

  • Web Framework: Express

  • Documentation: Swagger/OpenAPI

  • MCP SDK: @modelcontextprotocol/sdk

  • Testing: Jest

Security Considerations

⚠️ Important Security Notes:

  1. This server provides direct access to system resources

  2. Write operations can affect system behavior

  3. Always run with minimum required permissions

  4. Consider using read-only mode for untrusted clients

  5. Implement authentication for production deployments

  6. Monitor and log all write operations

Contributing

Contributions are welcome! Please:

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes with tests

  4. Submit a pull request

License

MIT License - see LICENSE file for details

Resources

Support

Changelog

See CHANGELOG.md for version history.

Made with ❤️ for the MCP community

Available Tools

10 tools
get_cpu_infoB

Get detailed CPU information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/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 behavioral traits. It states 'Get detailed CPU information' but offers no details about cost, permissions, or what 'detailed' entails, leaving significant uncertainty.

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 wasted words, achieving clarity without verbosity. Slightly more context about the returned information would improve it.

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 tool with no parameters or output schema, the description adequately communicates the core function. However, it lacks details about the scope and format of the 'detailed CPU information', which if provided would enhance usability.

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?

There are no parameters, and schema description coverage is 100% trivially. The description does not add any parameter-related context, but its brevity is acceptable given the absence of inputs.

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 uses the verb 'Get' and identifies the resource 'CPU information', making the tool's purpose unambiguous and distinguishing it from siblings like get_memory_info or get_disk_stats.

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 provides no explicit guidance on when to use this tool versus alternatives (e.g., read_procfs). Usage context is implied by its name, but explicit when/when-not instructions are absent.

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

get_disk_statsC

Get disk I/O statistics

ParametersJSON Schema
NameRequiredDescriptionDefault
deviceNoSpecific device name (optional)

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, so the description must carry the full burden. The one-line description does not disclose behavioral traits such as whether it reads /proc, requires permissions, or returns aggregated or per-device statistics.

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 short sentence with no wasted words, making it concise and front-loaded.

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?

For a simple tool with one optional parameter, the description is still too brief. It does not hint at the output format or what the statistics represent. Without an output schema, more context is needed.

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%, and the parameter description in the schema already states 'Specific device name (optional)'. The tool description adds no additional meaning, so baseline 3 is appropriate.

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 'Get' and resource 'disk I/O statistics', so the tool's purpose is understandable. However, it does not differentiate from sibling tools like read_procfs or get_cpu_info.

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 usage guidance is provided. There is no indication of when to use this tool versus alternatives, nor any prerequisites or context.

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

get_memory_infoB

Get detailed memory information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries the full burden but only states the purpose. It does not disclose safety (read-only? side effects?), required permissions, or any behavioral traits such as cost or latency.

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, concise sentence that directly states the tool's purpose with no unnecessary words.

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?

The tool has no output schema, so the description should indicate what 'detailed memory information' includes (e.g., total, free, swap). The vague term 'memory information' leaves the agent uncertain about what to expect.

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, so the schema covers all details (100% coverage). The description adds nothing beyond the schema, but the baseline for zero parameters is 4 per guidelines.

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 'get' and resource 'memory information', distinguishing it from sibling tools like get_cpu_info or get_disk_stats. However, the resource could be more specific (e.g., 'memory usage statistics').

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 read_procfs, which might also provide memory information. No context or prerequisites are mentioned.

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

get_network_statsC

Get network interface statistics

ParametersJSON Schema
NameRequiredDescriptionDefault
interfaceNoSpecific interface name (optional)

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, so description carries full burden. It indicates a read operation but does not mention permissions, side effects, rate limits, or the nature of statistics. Minimal behavioral disclosure.

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 with no redundant information. Efficiently conveys the tool's action.

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?

No output schema exists, and description does not explain return values, format, or error scenarios. For a simple tool, more detail on expected output would improve completeness.

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 has 100% coverage with one optional parameter 'interface' described. Description adds no extra meaning beyond schema; baseline 3 is appropriate.

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?

Description states 'Get network interface statistics', which is a clear verb+resource. It distinguishes from siblings like get_cpu_info and get_memory_info by specifying network. However, it lacks detail on what statistics are included.

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 such as read_procfs or other stat tools. No conditions or exclusions provided.

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

get_process_infoC

Get information about a specific process

ParametersJSON Schema
NameRequiredDescriptionDefault
pidYesProcess ID

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description fully bears the burden of disclosing behavior. It only says 'get information' without specifying what information is returned, whether it requires special permissions, or if it has side effects. Critical details are missing.

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 sentence, front-loaded with the key action and object. No unnecessary words. However, the brevity sacrifices useful detail, making it less effective overall.

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 absence of an output schema and the presence of multiple sibling tools, the description is too minimal. The agent lacks information about the return format and cannot distinguish when to use this tool over alternatives.

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 provides 100% coverage for the single parameter (pid) with its description. The tool description adds no extra semantic meaning beyond the schema, so a baseline score of 3 is appropriate.

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 'get information about a specific process,' specifying a verb and resource. While sibling tools like read_procfs could overlap, the description emphasizes 'specific process,' distinguishing from system-wide tools. However, it lacks explicit differentiation from read_procfs.

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 read_procfs or set_process_priority. There are no criteria for context, no exclusions, and no mention of when not to use it.

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

list_sysctlB

List all sysctl parameters

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether root access is required, output format, or that it is a read-only 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 concise sentence, but it could be slightly more informative without losing brevity.

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 no output schema, the description is minimal but sufficient. It might mention that it outputs all kernel parameters, but it's not critically incomplete.

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?

No parameters exist, so the baseline is 4 per guidelines. The description adds no parameter-specific info, but none is needed.

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 lists all sysctl parameters, distinguishing it from write_sysctl (writing) and other get_* tools (specific stats).

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 siblings like read_procfs or write_sysctl. No context on prerequisites or alternatives.

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

read_procfsC

Read a file from the /proc filesystem

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesPath relative to /proc (e.g., "cpuinfo", "meminfo")
formatNoReturn format: raw text or parsed dataparsed

TDQS

C2.8/5.0
Behavior2/5

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

No annotations exist, and the description does not disclose behavioral traits like required permissions, error handling, or side effects. For a read operation, it is safe, but details on reading non-existent files or access restrictions are absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, adequately sized but overly minimal. It is front-loaded with the core purpose but lacks any supplementary details.

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?

No output schema exists, and the description fails to explain return values or structure based on the format parameter. The tool's simplicity is not fully captured; missing details like file encoding or parsing behavior.

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 both parameters. The description adds no new meaning beyond 'Path relative to /proc' which is redundant with the 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 'Read a file from the /proc filesystem' clearly states the verb and resource. However, it does not differentiate this tool from siblings like get_cpu_info or get_memory_info, which are more specific /proc readers.

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. It is implied that read_procfs is for generic /proc files, while siblings cover specific ones, but no explicit when-to-use or when-not-to-use instructions.

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

set_process_affinityC

Set CPU affinity for a process

ParametersJSON Schema
NameRequiredDescriptionDefault
pidYesProcess ID
cpuListYesCPU list (e.g., "0,1" or "0-3")

TDQS

C2.8/5.0
Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits (e.g., required permissions, side effects, error handling).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (5 words) and front-loaded, but it sacrifices necessary detail for brevity.

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?

Despite simple tool and high schema coverage, missing behavioral context (e.g., permissions, return values) makes it incomplete for an AI 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?

Input schema has 100% description coverage for both parameters, so baseline is 3. The description adds 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 action ('Set') and the resource ('CPU affinity for a process'), and it distinguishes from sibling read/information tools like get_cpu_info and write_sysctl.

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 vs alternatives, no prerequisites or exclusions mentioned.

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

set_process_priorityB

Set process priority (nice value)

ParametersJSON Schema
NameRequiredDescriptionDefault
pidYesProcess ID
priorityYesNice value (-20 to 19)

TDQS

B3.1/5.0
Behavior2/5

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

Annotations are absent, so the description carries the full burden. It does not mention side effects (e.g., requires elevated privileges), error conditions, or impact on process scheduling.

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?

Extremely concise single phrase; front-loaded with key action. However, it may be overly terse, lacking context that would improve utility without adding bloat.

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?

For a mutation tool that modifies system state, the description omits crucial context such as permission requirements, expected behavior for invalid priority values, and whether changes are reversible.

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 covers both parameters with descriptions (PID, nice value range). The description adds no extra meaning beyond the term 'nice value', which is already in the parameter description.

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 'Set' and the resource 'process priority (nice value)', and it distinguishes from siblings like set_process_affinity (which sets CPU affinity) and get_process_info (which reads).

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, no prerequisites (e.g., superuser permissions), and no mention of when not to use it.

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

write_sysctlB

Write a sysctl kernel parameter

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYesSysctl key
valueYesValue to set

TDQS

B3/5.0
Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits like persistence (temporary vs permanent change), system impact, or side effects. It only states the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, but it is too brief to be fully informative. Could be expanded with key details while still being concise.

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?

Despite having 2 simple parameters, the description lacks completeness for a mutation tool: no mention of return values, side effects, or how the system responds.

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 basic descriptions ('Sysctl key', 'Value to set'), but the tool description adds 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 'Write a sysctl kernel parameter' clearly specifies the action (write) and resource (sysctl kernel parameter), distinguishing it from reading tools like read_procfs and list_sysctl.

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, when not to, or alternatives. Missing context such as requirements (e.g., permissions) or comparison to sibling tools.

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

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

TDQS

B3.4/5.0
Disambiguation5/5

Each tool targets a distinct subsystem (CPU, memory, network, disk, process, sysctl) with clear, non-overlapping purposes. Even read_procfs is a generic fallback that doesn't conflict with the more specific tools.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (get_cpu_info, get_memory_info, etc.), but there's a mix of 'read' and 'get' (read_procfs vs get_*) which is a minor inconsistency.

Tool Count5/5

10 tools is well within the typical 3-15 range covering the main /proc subsystems without being overwhelming or too sparse.

Completeness4/5

Covers CPU, memory, network, disk, processes, and sysctl comprehensively. Missing features like process signaling are reasonable omissions given the focus on monitoring and configuration.

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

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/manalejandro/mcp-proc'

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