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 lightweight, zero-overhead Model Context Protocol server that gives AI agents in Claude Desktop, Cursor, Windsurf, and Antigravity safe, structured access to Linux sysadmin inspection, log tailing, and service health without granting unrestricted root shells or risking interactive terminal freezes.
Giving an AI assistant raw terminal execution often ends in frustration:
Interactive Terminal Freezes: Commands like journalctl, systemctl status, or git log default to interactive pagers (less), leaving the AI agent permanently hung waiting for user input.
Context Window Flooding: Tailing an unconstrained /var/log/nginx/access.log dumps thousands of lines into the LLM prompt, wasting tokens and causing memory errors.
Destructive Shell Commands: Without sandboxing, a hallucinated command can kill critical background daemons or delete workspace assets.
SysFlow exposes safe, bounded, non-blocking tools specifically tailored for autonomous developer agents.
Related MCP server: mcp-linux-tools
ð Resource Healthcheck: Reports CPU core load averages (1m, 5m, 15m), RAM availability (MB and percentage), and disk partition metrics.
ð Safe Log Tailer: Reads the last N lines (bounded and memory-safe) with optional regex filtering; automatically rejects binary files.
âïļ Systemd User Service Inspector: Lists user-level services and timers (systemctl --user), highlighting failed units without requiring sudo.
ðŠķ Zero External Dependencies: Operates strictly on Python standard library and Linux /proc filesystem.
git clone https://github.com/johannschiffer/sysflow-mcp.git
cd sysflow-mcp
pip install .claude_desktop_config.json)On Linux: ~/.config/Claude/claude_desktop_config.json
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"sysflow": {
"command": "python",
"args": ["-m", "sysflow.server"],
"cwd": "/path/to/sysflow-mcp"
}
}
}python -m sysflow.cli resourcesTool | Parameters | Description |
| (none) | Returns CPU load, memory usage, and partition disk metrics |
|
| Safely tails recent log lines with optional regex filter |
|
| Lists user-level services, states, and detects failed daemons |
| (none) | Lists scheduled systemd user timers |
Looking to automate shell task execution, manage Docker containers, or generate verified systemd units?
Feature | Lite (Open Source) | Pro ($14.99 USD) |
CPU, RAM & Disk Monitoring | â | â |
Safe Bounded Log Tailer | â | â |
Systemd User Service Auditing | â | â |
Sandboxed Task Runner with Timeouts (Anti-freeze) | â | â |
Docker Container Health & Log Inspector | â | â |
Verified Systemd Unit File Generator | â | â |
Listening Socket & Port Conflict Auditor | â | â |
Production Docker Container | â | â |
Full Pytest Suite & Sysadmin Automation Guide | â | â |
ð Get SysFlow Pro on Gumroad ($14.99)
MIT License. See LICENSE for details.
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.
Local checks for sudo, systemd, sshd, ufw, and secret leaks before an agent applies them.
