This MCP server provides Linux host diagnostics through four tools.
Check CPU load averages, RAM utilization, and disk partition space.
Tail log/text files with a required filepath, optional line count (default 50, max 500), and optional regex filtering.
List systemd --user services and active states, optionally only failed units.
List systemd --user scheduled timers and next trigger times.
Provides tools for inspecting local Linux system resources (CPU load, RAM, disk partitions), safely tailing bounded log files with optional regex filtering, and auditing systemd user services and timers.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SysFlow MCP check my CPU, RAM and disk health, then show failed user services"
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.
SysFlow MCP is a zero-dependency Linux administration and diagnostics Model Context Protocol server for Claude Desktop, Cursor, Windsurf, and Antigravity. It exposes host CPU/RAM/disk metrics, path-guarded log tailing, systemd --user service and timer inspection, validated unit generation, TCP port auditing, and timeout-bounded argv command execution.
Run directly via uvx:
uvx sysflow-mcpClaude Desktop / Cursor configuration:
{
"mcpServers": {
"sysflow-mcp": {
"command": "uvx",
"args": ["sysflow-mcp"]
}
}
}Related MCP server: DevOps Dashboard MCP Server
System Resource Telemetry: Reads CPU load averages, /proc/meminfo memory usage, and root partition utilization without requiring root privileges.
Path-Guarded Log Tailer: Reads backward in chunks from /var/log, /tmp, or configured SYSFLOW_LOG_DIRS, filtering regex matches before slicing and rejecting binary files or sensitive dotfiles (.env, .ssh, .git/config).
Systemd User Plane Inspection: Lists systemd --user services, failed units, and scheduled timers.
Validated Systemd Unit Generator: Generates .service and .timer definitions, rejecting control-character injection and distinguishing OnUnitActiveSec intervals (12h, 30min) from OnCalendar expressions (hourly, daily, *-*-* 04:00:00).
Listening TCP Port Auditor: Inspects active TCPv4/TCPv6 listeners via ss with a /proc/net/tcp{,6} hex-decoding fallback.
Timeout-Bounded Task Runner: Executes non-interactive argv commands (shell=False by default, secret environment variables scrubbed) inside a dedicated process group that is cleanly killed if the timeout expires.
Tool | Parameters | Description |
| (none) | Returns CPU load averages, RAM usage, and disk space |
|
| Tails text log files inside allowed directories with optional regex filter |
|
| Lists |
| (none) | Lists active |
|
| Runs an argv command with secret scrubbing and process-group timeout |
|
| Emits validated |
| (none) | Lists listening TCPv4 and TCPv6 ports |
Package | Description | Repository |
genesis-blackbox | Runtime flight recorder and AST blast-radius crash compiler | |
pgsafe-mcp | Read-only PostgreSQL/SQLite query guard and PII masker | |
crawlengine-mcp | HTTP web extraction, clean Markdown conversion, and proxy rotation | |
browserbridge-mcp | Session-pooled HTTP DOM inspection and SHA-256 action trail receipts | |
omnibridge-mcp | Multi-channel notification bus with SQLite retry queue | |
fastmcp-forge | MCP server framework and project scaffolder |
If this project is useful in your workflow, you can support ongoing maintenance on Ko-fi.
MIT License. Copyright (c) 2026 Johann Schiffer.
Inspect CPU load average, RAM utilization, and disk partition space.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'Inspect' strongly implies a non-mutating read and the metric list clarifies what data is surfaced, but there is no explicit statement about safety, permissions, cost/rate limits, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every word (verb plus the three metric categories) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only diagnostic tool this covers what is inspected, but with no output schema it says nothing about the structure or units of the returned metrics (e.g., utilization percentages vs bytes, one partition vs a list), which an agent would need to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the schema to document and the baseline of 4 applies. The description correctly adds no parameter detail because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Inspect') and enumerates the exact resources read: CPU load average, RAM utilization, and disk partition space. This clearly separates it from its siblings (tail_logs, inspect_systemd_services, inspect_systemd_timers), which target logs and services rather than host hardware metrics, though it never names those alternatives directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus the sibling inspection tools, nor any preconditions or exclusions. The diagnostic intent is only implied by the word 'Inspect' and the metric list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List systemd --user services, active states, and detect failed background units.
| Name | Required | Description | Default |
|---|---|---|---|
| failed_only | No | Only return units in failed state (default: false) |
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 usefully discloses the '--user' scope (user session units, not system-wide) and that it surfaces active states plus failures, implying a non-mutating read. It does not state permission requirements, whether it needs a running user systemd instance/dbus, or anything about output shape or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the resource front-loaded and no filler. It slightly overloads three ideas (listing, active states, failure detection) into a single clause, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-required-param read tool with no output schema and no annotations, the description is adequate: it names the resource, the scope, and the key output categories. It leaves open what the return looks like and what environment prerequisites exist, which for an unannotated system-inspection tool is a real but moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single boolean (failed_only) is fully documented in the schema. The description's mention of failed units loosely aligns with it but adds no syntax or default information beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (systemd --user services) plus what it surfaces (active states, failed units). The '--user' scope meaningfully distinguishes it from a system-wide service inspection, though it never explicitly names inspect_systemd_timers as the sibling for timer units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'detect failed background units' hints this is for diagnosing failures, and the failed_only param reinforces that. There is no explicit when-to-use, when-not-to-use, or routing to check_system_resources / inspect_systemd_timers when a different subsystem is the actual target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List systemd --user scheduled timers and their next trigger times.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only listing operation and specifies the returned information (next trigger times), but does not explicitly state the read-only nature, output format, or any permission requirements. It is adequate but has clear gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the action and the key result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool with no output schema, the description is nearly complete: it states what is listed and the key output field. It falls short only in not clarifying its relationship to the sibling inspect_systemd_services.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline score of 4 applies. The description does not need to add parameter meaning beyond the schema, which is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List) and resource (systemd --user scheduled timers) and mentions the key output (next trigger times). It does not explicitly differentiate itself from the sibling inspect_systemd_services, though the timer/service distinction is implied by the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as inspect_systemd_services or check_system_resources. The description simply states what it does, leaving all usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Safely read recent lines from a log or text file with optional regex filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of recent lines to retrieve (default: 50, max: 500) | |
| pattern | No | Optional regex pattern to filter lines | |
| filepath | Yes | Absolute or relative path to log file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Safely read' signals a non-mutating operation, which is useful, but it says nothing about error behavior (missing file, permission denied), how large files are handled, or what the output looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the core action and scope first and the optional capability trailing. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read tool with full schema coverage, the description covers the essentials. However, with no annotations and no output schema, it leaves error handling and result shape unexplained, which is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so defaults, maximums, and per-parameter meaning are already documented. The description only echoes the optional regex filtering, adding no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb ('read') and resource ('recent lines from a log or text file') with the regex filtering capability, so the agent knows exactly what it does. It is clearly distinct from the systemd/resource inspection siblings, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the resource type (log/text files); there is no explicit when-to-use, when-not-to-use, or alternative routing. 'Recent lines' hints at tail-style inspection, but the agent must infer the context itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0check_system_resourcesinspect_systemd_servicesinspect_systemd_timerstail_logsScored across 4 tools
Each tool targets a clearly distinct area: system resources, log tailing, systemd services, and systemd timers. The service and timer tools are related but their descriptions make the boundary explicit.
All tool names follow a consistent snake_case verb_noun pattern: check_system_resources, tail_logs, inspect_systemd_services, inspect_systemd_timers. There are no mixed conventions or vague standalone verbs.
Four tools are focused and each has a clear purpose, but the set is somewhat thin for a general system diagnostics server. Additional common operations could reasonably be expected.
Core diagnostic areas are covered: resources, logs, services, and timers. Minor gaps exist around process listing, network status, or journal-specific queries, but agents can work around them with the provided tools.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Read-only server insight: why a Linux server or K8s cluster is slow, failing or changed.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Context and control for any AI. Agent identity, scoped access, and proof across tools.
