Click on "Install 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., "@mcp-sysmon What's using the most memory?"
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.
MCP server for system monitoring. Ask Claude about your system — CPU, memory, disk, network, and processes.
Tool | Description |
| CPU, memory, swap, disk, uptime — full snapshot |
| Quick health check — only reports problems |
| Top processes sorted by CPU or memory |
| Disk partitions with I/O stats |
| Network interfaces, IPs, speeds, traffic |
| Listening TCP/UDP ports with owning process |
| Battery level, power source, time remaining |
| Search processes by name |
| Terminate a process by PID (SIGTERM or SIGKILL) |
Related MCP server: technical-notes-mcp
"Why is my laptop slow right now?"
"What's using the most memory?"
"Is anything wrong with my system?"
"What ports are open?"
"How much battery do I have?"
"Find all Chrome processes and kill the biggest one"
pip install mcp-sysmonAdd to your claude_desktop_config.json:
{
"mcpServers": {
"sysmon": {
"command": "mcp-sysmon"
}
}
}claude mcp add sysmon -- mcp-sysmongit clone https://github.com/dragogargo/mcp-sysmon.git
cd mcp-sysmon
uv sync
uv run pytest tests/ -v
uv run mcp-sysmonMIT
Search for running processes by name using case-insensitive partial matching.
Use this to locate specific processes — for example, find_process("chrome") returns all Chrome-related processes. Use get_top_processes instead when you want to see the highest resource consumers regardless of name. After finding a process, you can use its PID with kill_process to terminate it.
This is a read-only operation with no side effects.
Returns a Markdown table with columns: PID, Name, CPU%, Mem%, RSS, User, Status. Returns a plain text message if no processes match. Processes that exit during enumeration or require elevated access are skipped.
Args: name: Process name or substring to search for. Matching is case-insensitive and partial — "fire" matches "firefox", "Firewall", etc.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'This is a read-only operation with no side effects.' It also discloses that processes that exit during enumeration or require elevated access are skipped, and describes the return format (Markdown table or plain text).
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 well-structured: front-loaded with the main purpose, then usage, then return format. Every sentence adds value without redundancy. It is concise yet comprehensive.
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?
Given no output schema, the description explains the return format in detail (Markdown table with columns or plain text for no matches). It mentions edge cases (skipped processes) and provides a complete picture for a search tool with one parameter.
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 0%, so description must explain the parameter. It thoroughly explains the 'name' parameter: 'Process name or substring to search for. Matching is case-insensitive and partial — "fire" matches "firefox", "Firewall", etc.' This adds significant meaning 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?
The description clearly states 'Search for running processes by name using case-insensitive partial matching.' It provides a specific verb (search), resource (running processes), and key characteristics. It also distinguishes itself from sibling tool 'get_top_processes'.
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?
The description explicitly says when to use this tool vs. get_top_processes: 'Use get_top_processes instead when you want to see the highest resource consumers regardless of name.' It also explains the workflow: after finding a process, use its PID with kill_process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve battery charge level, power source, and estimated time remaining.
Use this when the user asks about battery life, charging status, or power source. Only available on laptops and devices with a battery. On desktops or VMs without a battery, returns a message indicating no battery was detected.
This is a read-only operation with no side effects.
Returns a Markdown report with: charge percentage, plugged-in status, estimated time remaining (if on battery), and a low-battery warning when charge drops below 20%.
| 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 full burden. It declares this is a read-only operation with no side effects, describes the platform behavior (laptop vs desktop), and details the return format including what fields are in the Markdown report.
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 concise and well-structured: first sentence defines purpose, second sentence usage guidance, third sentence platform note, fourth sentence read-only guarantee, fifth sentence return format. Every sentence adds value with no redundancy.
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?
Given zero parameters, no output schema, and no annotations, the description is complete. It explains what the tool does, when to use it, platform limitations, and the nature and content of the response.
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 has zero parameters and schema coverage is vacuously 100%. Therefore, baseline score of 3 is appropriate; the description does not need to add parameter semantics.
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 clearly states the tool retrieves battery charge level, power source, and estimated time remaining using specific verbs and resources. It is distinct from sibling tools like find_process or get_disk_usage, which cover other system aspects.
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?
The description provides explicit usage guidance: 'Use this when the user asks about battery life, charging status, or power source.' It also mentions when not to use (desktops/VMs without battery) and the expected fallback behavior, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show detailed disk usage for all mounted partitions with I/O statistics.
Use this for disk space analysis — identifying full partitions, comparing filesystem usage, or checking I/O throughput. For a quick disk summary as part of overall system health, use get_system_overview instead.
This is a read-only operation with no side effects.
Returns a Markdown table with columns: Mount, Device, Total, Used, Free, Usage%, FS type. Also includes cumulative disk I/O since boot (total bytes read/written). Partitions requiring elevated privileges are silently skipped.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is a read-only operation with no side effects and that partitions requiring elevated privileges are silently skipped. Since no annotations are provided, the description fully covers behavioral traits.
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 concise (5 sentences), front-loads the main purpose, and every sentence adds value: purpose, usage, safety, output format, and edge case. No superfluous text.
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?
Given no parameters and no output schema, the description covers the tool completely: what it does, when to use, what it returns (Markdown table columns and I/O stats), and a behavioral note. No gaps.
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 has zero parameters and schema description coverage is 100%. The description need not add parameter information. Baseline 4 is appropriate.
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 'Show detailed disk usage for all mounted partitions with I/O statistics,' which is a specific verb+resource+scope. It also distinguishes itself from the sibling tool get_system_overview by noting it provides 'detailed' info vs a 'quick summary.'
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?
Explicit usage context: 'Use this for disk space analysis... For a quick disk summary... use get_system_overview instead.' This provides clear when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show all network interfaces with IP addresses, link speed, status, and traffic counters.
Use this to check network connectivity, find the machine's IP addresses, or investigate network throughput. Not suitable for packet-level analysis or firewall rule inspection.
This is a read-only operation with no side effects.
Returns a Markdown report grouped by interface. Each interface shows: UP/DOWN status, link speed in Mbps, IPv4/IPv6 addresses, and cumulative bytes sent/received since boot. Loopback and virtual interfaces are included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explicitly states 'This is a read-only operation with no side effects' and mentions that loopback and virtual interfaces are included, giving clear behavioral expectations.
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 concise (about 6 lines), front-loaded with purpose, then usage guidelines, then behavioral transparency, and finally output details. Every sentence adds value with no fluff.
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?
Given no parameters and no output schema, the description fully explains the output format (Markdown report grouped by interface) and the fields shown (status, speed, IPs, traffic counters), making it complete for the tool's simplicity.
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 has zero parameters, so baseline is 4. The description adds context about what the returned Markdown report contains, going beyond the empty 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?
The description starts with a specific verb ('Show') and resource ('all network interfaces'), and clearly lists what information is displayed (IP addresses, link speed, status, traffic counters). It distinguishes itself from siblings like 'get_open_ports' which focuses on ports, not general network interface info.
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?
The description explicitly states when to use the tool ('check network connectivity, find IP addresses, investigate throughput') and when not to use it ('Not suitable for packet-level analysis or firewall rule inspection'), guiding the agent to appropriate alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all listening TCP/UDP ports with the process that owns each one.
Use this to check what services are running and which ports are in use. Helpful for debugging "port already in use" errors or checking if a server is actually listening. For general network interface info, use get_network_info instead.
This is a read-only operation with no side effects.
Returns a Markdown table with columns: Proto, Local Address, Port, PID, Process. Only shows LISTEN (TCP) and bound (UDP) sockets. Connections requiring elevated privileges show "N/A" for PID and process name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is a read-only operation with no side effects, details the return format (Markdown table), and notes edge cases (only LISTEN/bound sockets, privileged connections show N/A).
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 concise with 5 sentences, front-loads the primary purpose, and every sentence serves a distinct purpose without redundancy.
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?
Given no parameters, no output schema, and no annotations, the description fully compensates by explaining the operation, return format, use cases, and limitations.
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?
There are no parameters, so the description cannot add value beyond what the schema provides. A baseline of 4 is appropriate as the description does not need to elaborate further.
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 clearly states the action ('List all listening TCP/UDP ports with the process that owns each one') and distinguishes the tool from the sibling 'get_network_info' by specifying the exact scope.
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?
It explicitly states when to use this tool (check services, debug port conflicts) and when not to (use get_network_info for general interface info), providing clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a quick health check and return warnings for any metrics outside normal ranges.
Use this as a fast diagnostic — it checks CPU, memory, swap, disk, and battery and only reports problems. If everything is healthy, it says so. Use get_system_overview for full metrics regardless of health status.
This is a read-only operation with no side effects. Takes ~0.5 seconds due to CPU sampling.
Returns a Markdown list of warnings (high CPU, low memory, full disk, etc.) or a confirmation that all metrics are within normal ranges. Each warning includes the current value and the threshold that was exceeded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it is read-only with no side effects and takes ~0.5 seconds due to CPU sampling, fully describing behavioral traits beyond the missing annotations.
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?
Concise, front-loaded with a one-sentence summary, then usage guidance and details. Every sentence adds value with no fluff.
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?
Despite no output schema, description explains output format (Markdown warnings or confirmation, including current value and threshold). Also mentions latency. Complete for a simple health check tool.
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?
No parameters exist; baseline is 4 per guidelines. Description adds no param info but is not needed.
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 clearly states it performs a quick health check returning warnings for metrics outside normal ranges, listing CPU, memory, swap, disk, battery. It distinguishes from sibling 'get_system_overview' which returns full metrics regardless of health.
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?
Explicitly says 'Use this as a fast diagnostic' and contrasts with 'Use get_system_overview for full metrics regardless of health status', providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a full system health snapshot: CPU usage, core count, memory, swap, disk usage, and uptime.
Use this as the first tool when diagnosing system performance issues or answering questions like "why is my machine slow?" or "how much disk space is left?". For deeper investigation, follow up with get_top_processes, get_disk_usage, or get_network_info.
This is a read-only operation with no side effects. Takes ~0.5 seconds due to CPU sampling.
Returns a Markdown report with sections: CPU, Memory, Swap, and Disks. Each section shows current usage as absolute values and percentages. Disk partitions that require elevated privileges are silently skipped.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, no side effects, approximate execution time (~0.5s), and limitation that privileged disk partitions are silently skipped. No annotations provided, so description fully covers behavioral traits.
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?
Four sentences, each earning its place: first sentence defines purpose, second gives usage guidance, third adds behavioral context, fourth explains output format. No redundancy.
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?
Despite no output schema, description fully explains return structure and sections. Covers purpose, usage, behavior, performance, and limitations. Complete for a read-only health snapshot tool.
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?
No parameters exist (schema coverage 100%), but description adds value by detailing the return format (Markdown report with sections) and behavior, exceeding the baseline for zero-parameter tools.
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?
Clear verb 'Retrieve' and specific resource 'full system health snapshot' with listed components (CPU, memory, etc.). Distinguishes itself from sibling tools by stating it is the first tool to use.
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?
Explicitly advises using as first tool for system diagnostics and names specific follow-up tools (get_top_processes, etc.) for deeper investigation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the top resource-consuming processes sorted by CPU or memory usage.
Use this to identify which processes are consuming the most resources. Use sort_by="memory" (default) to find memory hogs, or sort_by="cpu" to find CPU-intensive processes. Use get_system_overview first for the big picture, then this tool to drill down into specific processes. To search for a specific process by name, use find_process instead.
This is a read-only operation with no side effects. When sorting by CPU, takes ~0.5 seconds for accurate sampling; memory sorting is instant.
Returns a Markdown table with columns: PID, Name, CPU%, Mem%, RSS, Status. Processes that exit during enumeration or require elevated access are skipped.
Args: sort_by: Sort criterion — "cpu" for CPU usage or "memory" for RAM usage. Default: "memory". Any value other than "cpu" is treated as "memory". limit: Maximum number of processes to return. Range: 1-50. Default: 10. Values outside the range are clamped automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sort_by | No | memory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description fully covers: declares read-only with no side effects, notes timing differences (CPU ~0.5s, memory instant), and mentions skipped processes (exited or elevated access).
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?
Well-structured: purpose first, then usage guidelines, behavioral notes, parameter details. Each sentence adds value, no fluff.
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?
Without output schema, description explains return format (Markdown table with columns). Covers all relevant aspects: purpose, usage context, behavior, parameters, and output.
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 has 0% coverage, but description explains both parameters: sort_by accepts 'cpu' or 'memory' (default behavior), limit 1-50 with clamping. Adds meaning beyond schema defaults.
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?
Clearly states it lists top resource-consuming processes sorted by CPU or memory. Distinguishes from siblings: directs to get_system_overview for big picture and find_process for specific search.
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?
Explicitly says when to use (drill down after overview) and when not (use find_process for specific process). Also explains sort_by options and behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminate a process by its PID. This is a DESTRUCTIVE operation.
Use this only after identifying the target process with find_process or get_top_processes. Always confirm the PID and process name with the user before calling this tool. Killing system processes may cause instability.
Side effects: sends a signal to the target process.
Default (force=False): sends SIGTERM, allowing the process to clean up gracefully.
force=True: sends SIGKILL, immediately terminating the process without cleanup. May require elevated privileges (sudo) for processes owned by other users.
Returns a confirmation message with the process name, or an error message if the process does not exist or access is denied.
Args: pid: The numeric process ID to terminate. Use find_process or get_top_processes to discover valid PIDs. force: If False (default), send SIGTERM for graceful shutdown. If True, send SIGKILL for immediate termination — use only when SIGTERM fails or the process is unresponsive.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | ||
| force | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses destructive nature, signal types (SIGTERM vs SIGKILL), permission requirements, side effects, and return types (confirmation or error). Detailed parameter behavior for force.
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?
Well-structured with clear sections: purpose, usage guidelines, side effects, parameter details. Each sentence is informative without redundancy. Front-loaded with core action.
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?
Coverage for all aspects: input (pid, force), behavior (signal types), prerequisites (identification), warnings, permissions, return values. No output schema, but description includes expected confirmation/error messages.
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 has 0% description coverage; description compensates fully by explaining pid (numeric, use discovery tools) and force (default false sends SIGTERM, true sends SIGKILL, when to use each). Adds guidance not present in 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?
Description clearly states 'Terminate a process by its PID' with a specific verb and resource. Distinguishes from sibling tools like find_process and get_top_processes by indicating the action is termination, not discovery.
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?
Explicitly states when to use (after identification via find_process/get_top_processes) and provides critical safety instructions (confirm with user, danger of killing system processes). Mentions alternatives for identification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of system monitoring with clear descriptions. Tools like get_system_overview and get_system_health are differentiated by full metrics vs. warnings-only, and process tools (find_process, get_top_processes, kill_process) have non-overlapping purposes.
All tools use a consistent verb_noun pattern: get_ for read-only, find_ for search, kill_ for destructive operations. Naming is predictable and clear, e.g., get_disk_usage, get_network_info, kill_process.
With 9 tools covering CPU, memory, disk, network, ports, battery, and processes, the count is well-scoped for a system monitoring server. No redundancy or missing core functionality.
The tool set provides thorough coverage for system diagnostics: process lifecycle (search, top, kill), resource overviews (system overview, health check), and specific subsystems (disk, network, ports, battery). Gaps like hardware sensors are niche and beyond typical scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that automatically collects feedback on your MCP server.
An MCP server giving access to Grafana dashboards, data and more.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dragogargo/mcp-sysmon'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
