How do I use linux-profiler?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@linux-profiler profile process nginx and generate flame graph" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

linux-profiler

by yuezhongtao

Overview Schema Related Servers Score Discussions

Python

Hybrid

Linux Performance Profiler

A comprehensive Linux system performance profiler with MCP (Model Context Protocol) remote invocation support, featuring advanced process profiling and flame graph generation.

中文文档 | English

License

This project is licensed under the Apache License 2.0.

Related MCP server: Linux MCP Server

Features

CPU Analysis: Usage rate, frequency, load average, per-core status
Memory Analysis: Virtual memory, swap space, cache usage
Disk Analysis: Partition usage, I/O read/write statistics
Network Analysis: Interface traffic, connection status, error statistics
Process Analysis: Top N CPU/memory consumers, process status statistics
🔥 Process Search: 🆕 Search processes by name or command line keywords
🔥 Performance Profiling: 🆕 Profile processes with perf and generate CPU flame graphs
Health Check: Automatic identification of performance issues and alerts

Project Structure

linux-profiler-tool/
├── src/linux_profiler/
│   ├── __init__.py
│   ├── server.py              # MCP server main entry
│   └── collectors/
│       ├── __init__.py
│       ├── base.py            # Collector base class
│       ├── cpu.py             # CPU metrics collector
│       ├── memory.py          # Memory metrics collector
│       ├── disk.py            # Disk I/O collector
│       ├── network.py         # Network metrics collector
│       ├── process.py         # Process metrics & search collector
│       └── perf.py            # 🆕 Perf profiling & flame graph collector
├── examples/
│   └── profile_workflow.py    # 🆕 Interactive profiling demo
├── pyproject.toml
├── mcp_config.json            # MCP configuration example
├── FEATURES.md                # 🆕 Detailed feature documentation
├── CHANGELOG.md               # 🆕 Version changelog
├── LICENSE                    # Apache 2.0 License
└── README.md

Installation

# Clone the project
cd linux-profiler-tool

# Create and activate virtual environment
python3 -m venv .venv
source .venv/bin/activate  # Linux/macOS
# or .venv\Scripts\activate  # Windows

# Install dependencies (development mode)
pip install -e .

# Or use uv (faster)
uv pip install -e .

# Verify installation
linux-profiler --help

Note: If you encounter ModuleNotFoundError, ensure you're in the project directory and have activated the virtual environment. Run pip install -e . to install in development mode.

Usage

1. STDIO Mode (Local Invocation)

# Run directly (default STDIO mode)
python -m linux_profiler.server

# Or use the installed command
linux-profiler

2. HTTP Mode (Remote Invocation)

Two HTTP transport protocols are supported:

Streamable HTTP (Recommended, MCP new standard):

# Start Streamable HTTP service (default)
linux-profiler --http

# Stateless mode
linux-profiler --http --stateless

# Custom port
linux-profiler --http --port 22222

SSE Transport (Legacy mode):

# Use SSE transport
linux-profiler --http --transport sse

Support both transports simultaneously:

# Enable both SSE and Streamable HTTP
linux-profiler --http --transport both

Available endpoints after startup:

Transport Type	Endpoint	Description
Streamable HTTP	`/mcp`	MCP main endpoint (GET/POST/DELETE)
SSE	`/sse`	SSE connection endpoint
SSE	`/sse/messages/`	SSE message endpoint (both mode only)
Common	`/health`	Health check
Common	`/`	Service information

3. Configure MCP Client

STDIO Mode Configuration:

{
  "mcpServers": {
    "linux-profiler": {
      "command": "python",
      "args": ["-m", "linux_profiler.server"],
      "cwd": "/path/to/linux-profiler-tool",
      "env": {
        "PYTHONPATH": "/path/to/linux-profiler-tool/src"
      }
    }
  }
}

Streamable HTTP Mode Configuration (Recommended):

{
  "mcpServers": {
    "linux-profiler": {
      "url": "http://your-server:22222/mcp",
      "transportType": "streamable-http"
    }
  }
}

SSE Mode Configuration (Legacy):

{
  "mcpServers": {
    "linux-profiler": {
      "url": "http://your-server:22222/sse"
    }
  }
}

Available MCP Tools

Core Monitoring Tools

Tool Name	Description
`get_system_info`	Get basic system information (hostname, OS, kernel version, etc.)
`get_cpu_metrics`	Get CPU usage, frequency, and load average
`get_memory_metrics`	Get memory and swap space usage
`get_disk_metrics`	Get disk partition and I/O statistics
`get_network_metrics`	Get network interface traffic and connection status
`get_process_metrics`	Get process statistics and top N resource consumers
`get_all_metrics`	Get comprehensive report of all performance metrics
`get_performance_summary`	Get performance summary and issue alerts

🆕 Advanced Profiling Tools (v1.1.0)

Tool Name	Description	Parameters
`search_processes`	Search processes by keyword (name or command line)	`keyword` (required), `case_sensitive` (optional)
`profile_process`	Profile process using Linux perf, generate flame graph data	`pid` (required), `duration`, `frequency`, `event`

🔥 New Features:
Process Search: Quickly find processes by name or command patterns
CPU Profiling: Deep performance analysis with perf tool integration
Flame Graph Generation: Interactive HTML flame graphs for performance visualization
See FEATURES.md for detailed documentation and examples.

Example Output

get_performance_summary

{
  "status": "warning",
  "timestamp": "2026-01-14T10:30:00",
  "summary": {
    "cpu_percent": 45.2,
    "load_average_1min": 2.5,
    "memory_percent": 72.3,
    "swap_percent": 15.0
  },
  "issues": [],
  "warnings": [
    "Warning: Memory usage is high (72.3%)"
  ]
}

search_processes

{
  "success": true,
  "keyword": "nginx",
  "case_sensitive": false,
  "matched_count": 3,
  "processes": [
    {
      "pid": 1234,
      "name": "nginx",
      "username": "www-data",
      "cmdline": "nginx: master process /usr/sbin/nginx",
      "cpu_percent": 0.5,
      "memory_percent": 0.3,
      "status": "sleeping"
    },
    {
      "pid": 1235,
      "name": "nginx",
      "username": "www-data",
      "cmdline": "nginx: worker process",
      "cpu_percent": 2.1,
      "memory_percent": 0.4,
      "status": "running"
    }
  ],
  "tip": "Use the PID from this list to profile a specific process with profile_process tool"
}

profile_process

{
  "success": true,
  "pid": 1234,
  "duration": 30,
  "frequency": 99,
  "event": "cpu-clock",
  "timestamp": "2026-01-18 07:42:12",
  "statistics": {
    "total_samples": 287,
    "top_functions": [
      {
        "overhead_percent": 15.2,
        "command": "nginx",
        "function": "ngx_http_process_request"
      },
      {
        "overhead_percent": 8.7,
        "command": "nginx",
        "function": "ngx_event_process_posted"
      }
    ]
  },
  "flame_graph_data": [
    "nginx;[libc] __GI___libc_write;ngx_write_channel 12",
    "nginx;ngx_event_process_posted;ngx_http_request_handler 45"
  ],
  "help": "Use flame_graph_data to generate flame graph visualization"
}

get_system_info

{
  "hostname": "web-server-01",
  "system": "Linux",
  "kernel_version": "5.15.0-91-generic",
  "architecture": "x86_64",
  "python_version": "3.10.12",
  "boot_time": "2026-01-10T08:30:00"
}

get_cpu_metrics

{
  "cpu_percent": 35.5,
  "cpu_count": {
    "physical": 8,
    "logical": 16
  },
  "cpu_freq": {
    "current": 2400.0,
    "min": 800.0,
    "max": 3800.0
  },
  "load_average": {
    "1min": 2.15,
    "5min": 1.89,
    "15min": 1.76
  },
  "per_cpu_percent": [25.0, 38.5, 42.1, 30.0, ...],
  "cpu_times_percent": {
    "user": 25.5,
    "system": 8.0,
    "idle": 66.5,
    "iowait": 0.0
  }
}

Command Line Arguments

Argument	Description
`--http`	Enable HTTP mode (default is STDIO mode)
`--port, -p`	HTTP listening port (default: 22222)
`--host, -H`	HTTP listening address (default: 0.0.0.0)
`--transport, -t`	Transport type: `streamable` (default), `sse`, `both`
`--stateless`	Streamable HTTP stateless mode

Environment Variables

Variable	Description	Default
`PROFILER_PORT`	HTTP default port	22222
`PROFILER_HOST`	HTTP default address	0.0.0.0
`PROFILER_TRANSPORT`	Default transport type	streamable

Dependencies

Core Dependencies

Python >= 3.10
mcp >= 1.0.0
psutil >= 5.9.0
starlette >= 0.27.0
uvicorn >= 0.24.0
pydantic >= 2.0.0

Additional Requirements for Profiling (profile_process)

Linux system (perf is Linux-specific)

perf tool installed:

# Ubuntu/Debian
sudo apt-get install linux-tools-generic linux-tools-$(uname -r)

# RHEL/CentOS
sudo yum install perf

# Arch Linux
sudo pacman -S perf

Optional: Enable perf for non-root users

# Temporarily (until reboot)
sudo sysctl -w kernel.perf_event_paranoid=-1

# Permanently
echo "kernel.perf_event_paranoid = -1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Use Cases

1. Local Performance Monitoring

Monitor your local machine's performance metrics in real-time through MCP-compatible AI assistants.

2. Remote Server Monitoring

Deploy the profiler on remote servers and monitor multiple servers centrally through HTTP endpoints.

3. AI-Powered DevOps

Integrate with AI assistants to automate performance analysis, anomaly detection, and troubleshooting recommendations.

4. System Health Checks

Set up automated health checks and receive alerts when system resources exceed thresholds.

5. 🆕 Process Performance Analysis

Search for resource-intensive processes and generate detailed CPU flame graphs to identify bottlenecks.

Example Workflow:

# 1. Search for processes
search_processes --keyword "python"

# 2. Profile the target process
profile_process --pid 12345 --duration 30

# 3. Generate interactive flame graph
# The tool outputs flame_graph_data that can be visualized with:
# - FlameGraph tools (https://github.com/brendangregg/FlameGraph)
# - speedscope (https://www.speedscope.app/)
# - Or the built-in HTML generator

6. 🆕 Performance Bottleneck Identification

Quickly identify CPU-intensive functions and optimize hot code paths using flame graph visualization.

Try the Interactive Demo:

python examples/profile_workflow.py

Development

Running Tests

# Install development dependencies
pip install -e ".[dev]"

# Run tests
pytest

# Run with coverage
pytest --cov=linux_profiler

Code Quality

# Format code
black src/

# Type checking
mypy src/

# Linting
ruff check src/

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request

Troubleshooting

For common issues and solutions, please refer to:

INSTALL.md - Detailed installation guide
FIX_GUIDE.md - Troubleshooting guide

Acknowledgments

Built with MCP (Model Context Protocol)
Performance metrics powered by psutil
HTTP server built with Starlette

License

Copyright 2026 Linux Profiler MCP Contributors

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

See LICENSE for the full license text.

Made with ❤️ for the DevOps and AI community

Available Tools

10 tools

get_all_metricsB

Get a comprehensive performance report including CPU, memory, disk, network, and process metrics.

ParametersJSON Schema

Name	Required	Description	Default
`include_processes`	No	Whether to include process information (default: true)

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 burden of behavioral disclosure. It only describes the contents of the report but does not mention whether the operation is read-only, requires permissions, has rate limits, or any side effects.

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 sentence that efficiently conveys the purpose. However, it could be structured with bullet points or additional detail without being verbose.

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 returns a comprehensive report with no output schema, yet the description provides no information about the report format, return structure, or how to interpret results. Many sibling tools exist, but no guidance on when to use this combined report vs. individual queries.

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% and the description adds no new information about the single parameter 'include_processes' beyond what the schema already provides. Baseline 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 clearly states it returns a comprehensive performance report covering CPU, memory, disk, network, and process metrics. It distinguishes itself from specialized sibling tools like get_cpu_metrics by aggregating multiple metric types.

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 use for an overall performance overview but does not explicitly state when to prefer this tool over individual metric tools or when not to use it. No guidance on prerequisites or context is provided.

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

get_cpu_metricsB

Collects CPU usage, frequency, load average, and time distribution metrics.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full behavioral disclosure burden. It only states 'collects' implying a read operation, but does not mention any side effects, required permissions, performance considerations, or output characteristics.

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

Conciseness5/5

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

The description is a single, efficient sentence that lists the collected metrics without extra words. It is front-loaded and earns its place.

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

Completeness3/5

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

Given no output schema and no annotations, the description is minimally adequate for a simple parameterless tool. However, it does not describe the return format or any caveats, which is a gap for 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?

There are zero parameters, so the input schema provides full coverage. The description adds no parameter-specific information, but with no parameters, the baseline is 4. It could optionally describe default collection behavior but is not necessary.

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 explicitly states the tool collects CPU usage, frequency, load average, and time distribution metrics, clearly identifying the resource. It distinguishes from sibling tools like get_memory_metrics, but lacks specific differentiation or exclusion of alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus other metric tools (e.g., get_all_metrics) or any context about prerequisites or scenarios. The description is purely declarative without actionable usage direction.

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

get_disk_metricsA

Collects disk partition usage and I/O statistics including read/write counts and times.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. States it collects disk usage and I/O stats—non-destructive read operation. Does not disclose side effects, rate limits, or auth needs, but for a simple metrics tool this is adequate.

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, front-loaded verb and resource, no wasted words. Every word earns its place.

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 zero parameters, no output schema, and no annotations, the description sufficiently explains tool purpose with example metrics. Slight gap in not hinting at output format, but overall complete for this complexity level.

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?

Zero parameters; schema coverage is 100%. Description adds value by clarifying what data is collected without needing input, justifying the no-parameter design.

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?

Uses specific verb 'collects' and resource 'disk partition usage and I/O statistics', naming concrete metrics (read/write counts and times). Clearly distinguishes from siblings like get_cpu_metrics or get_memory_metrics.

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 use this tool versus siblings (e.g., get_all_metrics, get_performance_summary). Agent must infer usage from name alone.

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

get_memory_metricsA

Collects virtual memory and swap usage metrics including buffers and cache.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/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 carry the full burden of behavioral disclosure. It states 'collects' but does not confirm non-destructiveness, real-time nature, or system access requirements. For a metrics tool, this is a moderate gap in transparency.

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

Conciseness5/5

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

A single, clear sentence covering the tool's purpose. No wasted words; front-loaded with action and resource.

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 no parameters and no output schema, the description adequately covers the tool's purpose by mentioning the metrics collected (including buffers and cache). However, it could be slightly improved by hinting at the return format or usage context.

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 baseline is 4. The description adds no parameter-specific information, which is acceptable since the schema is empty and 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?

The description clearly states it collects virtual memory and swap usage metrics including buffers and cache. The verb 'collects' combined with specific resource 'virtual memory and swap usage' makes the tool's function unambiguous. It naturally distinguishes from sibling tools focused on CPU, disk, 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 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 this tool versus alternatives like get_all_metrics or get_performance_summary. The usage is implied by the name and description, but without context or exclusions, an agent may not know the best tool for a broader metrics request.

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

get_network_metricsA

Collects network I/O statistics, interface addresses, and connection states.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral traits. It mentions collecting specific data types but does not disclose performance impact, authorization requirements, or whether the tool is destructive. The description is too brief to provide adequate transparency.

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

Conciseness5/5

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

Single sentence with no wasted words. Front-loaded verb 'Collects' immediately conveys action. Highly concise.

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 the tool is simple (no parameters, no output schema), the description lacks any information about return format or potential side effects. For a network metrics gathering tool, more detail on what the output contains could be helpful, especially given sibling tools with more comprehensive descriptions.

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 input schema has zero parameters, so no parameter description is needed. Schema description coverage is 100% (effectively). The description does not need to add parameter semantics, so baseline 4 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?

Description explicitly states the tool collects network I/O statistics, interface addresses, and connection states. It clearly identifies the resource (network metrics) and the action (collects), distinguishing it from sibling tools like get_cpu_metrics or get_memory_metrics.

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 like get_all_metrics or get_performance_summary. The description only states what it does, not the context or conditions for its use.

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

get_performance_summaryB

Get a brief performance summary with key metrics and potential issues.

ParametersJSON Schema

Name	Required	Description	Default
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 must fully disclose behavior. It implies a read operation but lacks details on authentication requirements, rate limits, or what constitutes 'potential issues'. Minimal transparency.

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

Conciseness5/5

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

The description is a single concise sentence that is front-loaded with the action and subject. Zero wasted 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?

Despite low complexity, the description is too vague. It does not specify what key metrics or potential issues are included, leaving the agent uncertain about the output. No output schema compounds this.

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?

Zero parameters exist, so the baseline is 4. The description adds no extra meaning, but it appropriately indicates no inputs are 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 states the verb 'Get' and the resource 'performance summary', clearly indicating the tool's purpose. However, it does not explicitly differentiate from sibling tools like get_all_metrics, which also retrieves metrics.

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 the detailed metric tools (e.g., get_cpu_metrics). The description offers no context for selection.

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

get_process_metricsA

Collects process statistics including top 10 CPU and memory consumers.

ParametersJSON Schema

Name	Required	Description	Default
`top_n`	No	Number of top processes to return (default: 10)

TDQS

A3.7/5.0

Behavior3/5

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

No annotations present, so the description must convey behavioral traits. It states the tool collects top 10 CPU and memory consumers, which implies a read-only sampling. However, it does not mention permissions, potential performance impact, or whether it returns instantaneous or averaged data.

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 of 10 words, front-loading the core action and resource. Every word contributes meaning with no redundancy or filler.

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?

Despite simplicity, the description lacks details about the output format or structure, given there is no output schema. It could mention whether results are sorted, if both CPU and memory are in one list or separate, and typical usage context. The single parameter is well-handled, but the behavioral summary omits important completeness for a tool with only a description.

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?

Schema already documents top_n with meaning (100% coverage). The description adds value by specifying that the statistics are for CPU and memory consumers, narrowing the context from generic process statistics. This clarifies that the tool returns both types, not just one metric.

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

Purpose5/5

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

The description clearly states the tool collects process statistics with a focus on top 10 CPU and memory consumers. The verb 'collects' and resource 'process statistics' are specific, and the tool is well-differentiated from siblings like get_cpu_metrics or get_memory_metrics which likely provide aggregate metrics rather than per-process details.

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 explicit guidance on when to use this tool versus alternatives like profile_process or search_processes. The description only states what it does without indicating prerequisites, exclusions, or context for selection.

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

get_system_infoA

Get basic system information including hostname, OS, kernel version, and architecture.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided. The description describes a read operation ('Get') but does not explicitly state read-only nature, error conditions, or any side effects. It minimally discloses the returned information.

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, comprehensive sentence that immediately conveys the purpose and output. No wasted words.

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 simplicity (no parameters, no nested objects, and no output schema), the description sufficiently covers what the tool returns. It could mention response format, but not critical for this straightforward 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?

There are no parameters (0 params, schema coverage 100%). Baseline is 4. The description adds no parameter info but lists the output, which is acceptable given no parameters exist.

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 'Get basic system information' and lists specific fields (hostname, OS, kernel version, architecture). This distinguishes it from sibling tools which focus on metrics (CPU, 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?

The description implies usage for retrieving system info but does not explicitly state when to use versus alternatives or provide any exclusions. Siblings are metrics tools, so context is clear but no direct guidance.

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

profile_processA

Profile a specific process using perf to collect performance data for flame graph generation. Requires perf tool to be installed on the system.

ParametersJSON Schema

Name	Required	Description	Default
`pid`	Yes	Process ID to profile
`duration`	No	Duration in seconds to collect data (default: 10)
`frequency`	No	Sampling frequency in Hz (default: 99)
`event`	No	Perf event to record (default: cpu-clock). Other options: cycles, instructions, cache-misses	cpu-clock

TDQS

A3.7/5.0

Behavior2/5

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

Without annotations, the description carries full burden for behavioral transparency. It states the tool uses perf to collect performance data, implying it executes system commands. However, it does not disclose potential side effects such as requiring root privileges, impacting process performance, or whether the profiling is safe and non-destructive. This lack of detail leaves the agent uncertain about operational impacts.

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, consisting of two sentences. The first sentence front-loads the core purpose and method, and the second provides an essential prerequisite. Every sentence contributes meaningfully, and there is no wasted text.

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 description covers the main purpose and a key prerequisite but lacks details on output behavior (e.g., where data is stored, how to generate flame graphs) and operational constraints (e.g., permissions, process impact). Given the tool's complexity (4 parameters, active profiling), more context would be beneficial, but the description is minimally adequate.

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 all parameters are already documented with descriptions and defaults. The tool description adds no additional semantic value about the parameters (e.g., pid, duration, frequency, event) beyond what the schema provides. Thus, the description meets baseline but does not enhance parameter understanding.

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

Purpose5/5

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

The description clearly states the tool profiles a specific process using perf to collect performance data for flame graph generation. This is a specific verb+resource combination and stands out from sibling tools that are all 'get_*' metrics tools, which retrieve existing data.

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 mentions the prerequisite that the perf tool must be installed, which is important context. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. The sibling tools are all read-only data retrieval, so the usage context is clear, but the lack of exclusion guidance prevents a 5.

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

search_processesA

Search for processes by keyword (name or command line). Returns matching process IDs and details.

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	Yes	Keyword to search for in process names or command lines
`case_sensitive`	No	Whether to perform case-sensitive search (default: false)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations; description mentions return of IDs and details but does not disclose case sensitivity behavior, pagination, or potential side effects.

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, front-loaded with action, no fluff. Efficient and clear.

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?

Despite no output schema, the description adequately states what is returned. Slightly lacking in details like format or limits, but sufficient for a search 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 coverage is 100%; description restates schema info without adding new semantics. Baseline 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?

Clearly states the tool searches for processes by keyword in name or command line and returns IDs and details. Distinguishes from sibling metric tools.

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?

Provides implied usage (search for processes) but lacks explicit when-to-use vs alternatives, such as profile_process or get_process_metrics.

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

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct aspect of system performance: specific subsystems (CPU, memory, disk, network, processes), a comprehensive overview, a brief summary, system info, process profiling, and process search. There is no overlap that would confuse an agent.

Naming Consistency4/5

The majority of tools follow a consistent 'get_<subsystem>_metrics' pattern. Two tools use 'get_' with different objects (summary, info), and two use different verbs (profile, search). This is mostly consistent with minor deviations.

Tool Count5/5

10 tools is well-suited for a Linux profiler server. Each tool serves a clear purpose without being redundant or excessive, covering the necessary scope for performance monitoring and profiling.

Completeness5/5

The tool set covers all major performance domains (CPU, memory, disk, network, processes) and includes a comprehensive report, a summary, system info, and advanced per-process profiling. This provides a complete surface for typical Linux performance analysis.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Polar Signals
com.polarsignals.api
The Polar Signals MCP server enables AI assistants to connect directly with performance profiling data, allowing users to analyze application performance through natural language queries. Key capabilities include querying CPU performance and memory usage, exploring profiling metadata like profile types and labels, and providing AI-driven code optimization suggestions directly within development environments like Claude Code or Cursor.
Monitoring Developer Tools Observability
2
PGAuditor
com.mcpgatepro
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Databases Monitoring Observability
1
clianythingharness-mcp
com.clauxel.clianythingharness
A paid remote MCP for CLI tool MCP, built to return verdicts, receipts, usage logs, and audit-ready
Command Line Monitoring
21
HumanMirror Oracle A
fr.humanmirror
Structured analysis API and remote MCP tool for text, JSON records and numeric series.
Research & Data Data Platforms
11

Related MCP Servers

mcp-pprof-anaylzer
Developer Tools Code Analysis Monitoring
ZephyrDeng
A
license
Not graded
quality
C
maintenance
This is a Model Context Protocol (MCP) server implemented in Go, providing a tool to analyze Go pprof performance profiles.
Updated 7 months ago (2026-01-30 07:26 UTC)
50
MIT
Linux MCP Server
Shell Access Command Line Monitoring
ahmedadan
A
license
Not graded
quality
B
maintenance
A read-only MCP server for Linux and macOS system administration, diagnostics, and troubleshooting, supporting remote SSH execution and multi-host management.
Updated 2 months ago (2026-06-26 17:46 UTC)
Apache 2.0
py-spy MCP Server
Developer Tools Monitoring
LBurny
A
license
A
quality
A
maintenance
MCP server for profiling Python processes using py-spy, supporting flamegraphs, stack dumps, and performance comparisons.
Updated 2 months ago (2026-07-12 13:52 UTC)
6
1
MIT
MCP ProcFS Server
manalejandro
A
license
B
quality
D
maintenance
A powerful MCP server for reading and modifying Linux /proc filesystem values, providing system monitoring, process management, and sysctl operations via JSON-RPC and SSE.
Updated 10 months ago (2025-10-22 10:09 UTC)
14
MIT

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yuezhongtao/linux-profiler-tool'

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