Linux MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.6.0
Disambiguation4/5
Each tool targets a distinct resource or action, with clear separation across logs, network, processes, services, files, and hardware. Minor overlap exists between get_hardware_information and get_cpu_information, and between get_journal_logs and get_service_logs, but descriptions mostly disambiguate them.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern, using get_, list_, or read_ appropriately. This makes the tool surface predictable and easy to navigate.
Tool Count4/5
19 tools is slightly above the ideal 3-15 range, but the scope of a Linux system server justifies covering logs, network, processes, services, files, disks, and hardware. The count is manageable and each tool has a clear purpose.
Completeness4/5
The tool set covers most common read-only Linux administration tasks: system info, logs, processes, services, networking, files, and disk usage. It lacks write or lifecycle operations like creating files, managing processes, or restarting services, but the consistent read-only design suggests that is intentional.
Average 3.5/5 across 19 of 19 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 7 of 14 community issues answered or closed in the last 6 months
- 56 commits in the last 12 weeks
- Last stable release on September 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds no additional behavioral context beyond what the annotation and schema already provide—no mention of SSH behavior when host is provided, no note about possible latency, and no details about what 'CPU information' includes. It is not contradictory, but it contributes no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but this is under-specification rather than effective brevity. The one sentence merely restates the tool name/title and does not include any additional context that would help an agent select or invoke the tool. It lacks the precision expected for a useful description.
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?
Although an output schema exists and the parameter schema is complete, the description omits crucial context such as what specific CPU metrics are returned, how the host parameter affects execution, and how this differs from overlapping sibling tools. Given the large set of similarly named information-gathering tools, this description is insufficient for confident tool selection.
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%, with the single host parameter clearly documented as 'Remote host to connect to via SSH'. The description itself adds no parameter-level insight, but the schema fully compensates. The default null behavior is present in the schema, so the agent has enough to understand the parameter's semantics.
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?
States a specific verb and resource: 'Get CPU information.' It clearly identifies the intended action and object, but it does not differentiate from sibling tools like get_hardware_information or get_system_information, which could also return CPU-related data. The lack of scope details (e.g., utilization, architecture, cores) leaves some ambiguity, but the core purpose is unmistakable.
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 the many sibling tools (get_memory_information, get_hardware_information, etc.). There is no mention of prerequisites, scenarios, or exclusions. The agent must infer usage solely from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, but the description itself discloses no additional behavioral context such as default line limits, remote SSH behavior, or potential output volume. It neither contradicts the annotations nor adds meaningful behavioral detail beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is immediately readable and front-loaded. It is not bloated, though it is so minimal that it omits useful context an agent might need for proper routing.
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 rich input schema, output schema, and readOnlyHint annotation cover most of the invocation contract, so the brief description is mostly adequate. However, it lacks sibling differentiation and usage guidance, making the definition incomplete for confident tool selection in a larger toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all seven parameters with descriptions, defaults, examples, and constraints, so the schema carries the full parameter-semantics burden. The description adds no parameter information, but per the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and the resource ('systemd journal logs'), so an agent can understand the basic action and target. However, it does not differentiate this tool from siblings like get_service_logs or read_log_file, which may also return log content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives such as get_service_logs or read_log_file. There is no mention of typical use cases, prerequisites, or exclusions, leaving the agent to infer selection from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the safe read-only nature, so the description does not need to restate that. The description adds some context by naming DMI as a data source, which hints at underlying behavior. It does not mention potential privilege requirements for DMI or how the optional host parameter affects behavior, but annotations lower the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is mostly efficient and front-loads the action and subject. Minor redundancy exists in the phrase 'hardware information such as ... hardware information from DMI', which could be tightened, but overall it is 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?
The tool has only one optional parameter, an output schema, and read-only annotations, so little is missing on those fronts. However, the description does not address the overlapping sibling tools or clarify boundaries (e.g., CPU-specific vs. general hardware inventory), leaving an agent to guess which tool fits a given request. This gap in routing guidance prevents a higher score.
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% — the only parameter, 'host', already has a clear schema description ('Remote host to connect to via SSH'). The tool description adds no parameter-level meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with 'hardware information' as the resource, and lists concrete examples (CPU details, PCI devices, USB devices, DMI). This clearly communicates the tool's scope and differentiates it from file/process/network tools, though it does not explicitly differentiate it from system/cpu/memory sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of overlapping siblings such as get_cpu_information, get_memory_information, or get_system_information. An agent must infer usage context from examples alone; no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true is consistent with the description's 'Read' verb, so there is no contradiction. The description adds little behavioral context beyond the annotation though — it does not mention the remote-host SSH behavior or the allowed-list restriction on log paths, though those details do appear in the schema.
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?
A single front-loaded sentence with zero filler words, stating the core action immediately. It is highly efficient, though its brevity sacrifices the sibling-differentiation and usage context that the description could have transported.
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 schema is rich (100% parameter coverage, examples, mutual-exclusivity constraints), an output schema exists, and annotations cover the read-only safety profile — so the description does not need to explain return values or parameters. The one material gap is the absence of routing guidance among read_log_file, read_file, get_journal_logs, and get_service_logs, which is a real cost for an agent facing this sibling list.
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%, with all four parameters (host, log_path, last_lines, first_lines) having meaningful descriptions including defaults, examples, and mutual exclusivity. Per the high-coverage baseline, the description carries no parameter burden, and it adds none — an appropriate split of responsibilities.
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 a clear verb and resource: 'Read a specific log file.' The word 'specific' signals path-based file access rather than journal or service aggregation. However, it does not explicitly differentiate from near-neighbor siblings like read_file, get_journal_logs, or get_service_logs, leaving some ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains no guidance on when to use this tool versus alternatives. Siblings like get_journal_logs and get_service_logs exist, but no exclusions or selection criteria are mentioned. The agent must infer usage context from the tool name alone, with no support from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals that this is a safe read operation, lowering the burden on the description. The description adds a little context by indicating the returned details cover ports, protocols, and services, but it does not disclose other behavioral traits such as whether only local ports are shown or whether administrative privileges are needed.
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, well-structured sentence with no filler. It front-loads the core action and directly states what kind of information is returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and an output schema, the description is mostly adequate. However, it lacks any comparison to overlapping sibling tools and does not clarify the exact scope of 'listening ports' versus all network connections, leaving a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single host parameter as an optional remote SSH host, so the description does not need to add much. It provides no additional meaning beyond what the schema already includes, which meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details about listening ports, protocols, and services, which is a specific verb and resource. However, it does not explicitly distinguish itself from the closely related sibling get_network_connections, so some ambiguity about scope remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_network_connections or list_services. The optional SSH host parameter implies remote usage, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds path-scoped listing plus sorting behavior as useful context. However, it does not disclose whether the listing is recursive, whether hidden files are included, or that the tool can operate on a remote host via the host parameter.
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 ten-word sentence states the verb, resource, scope, and capability with zero filler. The information is front-loaded and every word 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?
With a 100%-covered schema, an output schema, and a readOnlyHint annotation, the structured data carries much of the burden, so the description need not explain return values or parameter formats. The remaining gaps are the lack of differentiation from list_directories and unspecified listing behavior (recursion, hidden files), which prevent the description from being fully complete for an agent deciding which tool to call.
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 every parameter is already documented in the input schema and the description adds no new parameter semantics. The mention of 'sorting options' merely restates the order_by and sort parameters, keeping this at the baseline of 3.
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 uses a specific verb ('List') with a clear resource ('files under a specified path') and notes sorting options, so an agent immediately understands the core operation. It does not explicitly distinguish itself from the sibling list_directories, leaving some ambiguity about whether directories are also included in results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_directories or read_file. No conditions, exclusions, or prerequisites are stated, so the agent must infer the appropriate context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds mild context by noting that both physical and swap memory are covered, but it discloses no other behavioral details such as what 'detailed' includes, remote host behavior, or potential limitations.
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, focused sentence that front-loads the action and scope with no filler or redundancy. The phrase 'including physical and swap' adds value beyond the title without extra 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?
For a simple read-only tool with one optional parameter, an output schema, and a readOnly annotation, the description is mostly sufficient. It is slightly thin on how it differs from sibling system/hardware information tools and what 'detailed' includes beyond physical and swap, but those gaps are partially mitigated by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter 'host' is fully described in the schema as 'Remote host to connect to via SSH', so schema description coverage is 100%. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'memory information', and adds useful scope by specifying 'including physical and swap.' It does not explicitly distinguish this from sibling tools like get_system_information or get_hardware_information, so it lacks full sibling differentiation.
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?
There is no guidance on when to use this tool versus alternatives such as get_system_information or get_hardware_information, nor any mention of the optional remote host scenario. The only usage signal is the tool name itself, leaving selection logic entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already conveys safety, and the description adds only the 'active' live-snapshot framing. It does not mention that supplying host may trigger an SSH connection to a remote machine, though that behavior is present in the schema. The description contributes minimal behavioral context beyond the annotation.
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, front-loaded sentence that states the action and resource without filler. 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?
For a simple, read-only tool with one optional parameter, an output schema, and a fully documented input schema, the description is nearly sufficient. The only notable gap is the absent usage differentiation from sibling network tools, which is already captured in the usage_guidelines score.
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%: the host parameter already has a clear description ('Remote host to connect to via SSH'). The tool description adds no additional parameter meaning, so the baseline score applies.
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 uses a specific verb and resource: 'Get detailed information about active network connections.' This is clear and distinguishable from siblings like get_network_interfaces or get_listening_ports by targeting active connections rather than interfaces or listening sockets, though it does not explicitly name those boundaries.
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 choose this tool over the many sibling tools. The description implies use when active network connections are wanted, but it never states exclusions or alternatives, leaving the agent to infer selection criteria from the name and title alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation, and the description adds minimal scope detail ('specific systemd service', 'recent'). No contradiction exists, but the description does not disclose additional behavioral nuances such as SSH-based remote execution or line-count limits beyond the schema.
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, compact sentence that states the core purpose immediately. Every word adds value, and there is no redundant or extraneous content.
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 presence of a full input schema, an output schema, and readOnly annotations, the description is largely sufficient for an agent to invoke the tool correctly. It falls slightly short by not clarifying how this tool differs from closely related logging siblings, which is relevant context for correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description does not add extra semantic value beyond what the schema provides, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Get recent logs') and the resource ('specific systemd service'), so an agent can understand what the tool does. However, it does not explicitly distinguish this from sibling tools like get_journal_logs, which may also retrieve logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives such as get_journal_logs or read_log_file. There are no explicit use-case conditions, exclusions, or cross-references to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this is a safe read operation, and the description matches that. The description adds 'running' scope but does not disclose remote-host behavior beyond the parameter schema or any other operational details; no contradiction exists.
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 clear sentence with no filler. Every word contributes to the meaning, and the core action is front-loaded.
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?
For a simple list operation with one optional parameter and an output schema, the description is nearly complete. It could be improved by noting the local default when host is omitted, but the parameter schema already covers that information.
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%: the only parameter, host, has an explicit description ('Remote host to connect to via SSH'). The tool description adds no further parameter meaning, so the baseline 3 applies.
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 'List running processes' — a specific verb and resource that clearly conveys the operation. It does not explicitly differentiate from get_process_info, but the name and sibling context make the distinction reasonably clear.
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 given about when to use this tool instead of siblings like get_process_info or list_services. There is no stated when-not-to-use or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds the scope 'all systemd services' but does not disclose any potential behavior such as large output, required privileges, or effects of the optional host parameter. This is acceptable given the annotation coverage but adds minimal behavioral context beyond it.
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 clear sentence with no wasted words. It is front-loaded with the primary action and object, making it easy for an agent to parse quickly.
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?
For a simple read-only list tool with an output schema and fully documented optional parameter, the description is largely sufficient. It could mention that the host parameter allows remote execution, but that is already in the schema, so nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the host parameter is already fully documented in the schema. The description adds no parameter-specific meaning, which is fine since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all systemd services', making the tool's purpose unambiguous. It is distinct from sibling tools like get_service_status and get_service_logs, though it does not explicitly call out that differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_service_status or get_service_logs. While sibling names imply different purposes, there is no explicit context or exclusion criteria, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the non-mutating nature, and the description aligns with it. The description adds a 'safe size limit' caveat, but it does not explain what happens when that limit is exceeded or how the tool handles non-text or remote files.
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, front-loaded sentence without filler. The verb and resource come first, and the safety qualifier is compact and relevant.
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?
For a low-complexity read tool, the schema, readOnly annotation, and output schema already supply much of the needed context. The main gap is the lack of explicit sibling differentiation and details about the size limit, but these do not prevent correct selection or invocation.
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%: both path and host are already described in the input schema. The tool description adds no parameter-level meaning beyond what the schema provides, so it meets the baseline for high schema coverage.
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 a specific action ('Read the contents') and resource ('a text file') with a useful safety qualifier. It is clear and not a tautology, but it does not explicitly differentiate itself from the sibling tool read_log_file, since log files are also text files.
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 when-to-use or when-not-to-use guidance is provided, and no alternatives such as read_log_file or get_journal_logs are mentioned. The 'text file' wording only implies general use rather than giving an agent selection criteria relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description does not contradict this. It adds no additional behavioral details beyond the parameter mention of SSH, but this is adequate given the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no superfluous content, effectively conveying the tool's core function.
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?
While the output schema is not shown, the description gives hints about the returned data (size, mount points, utilization). It is sufficiently complete for this simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'host' has a description in the schema, and the tool description does not add further meaning. Schema coverage is 100%, so baseline 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 the tool retrieves disk space information including size, mount points, and utilization, which is specific and distinct from sibling tools like get_network_interfaces or get_process_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description only states what it does, not in which scenarios it should be preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds no additional behavioral context beyond that, such as error behavior for invalid PIDs, permission requirements, or remote-host behavior. With annotations present, the lack of extra context is acceptable but not actively informative.
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, direct sentence that conveys the core purpose immediately. There is no wasted wording or redundant repetition of the tool name or title.
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 tool's low complexity, clear read-only annotation, complete parameter schema, and the presence of an output schema, the description is mostly sufficient for correct invocation. It could be improved by mentioning that the tool supports remote hosts via SSH and by explicitly distinguishing it from list_processes, but these are not critical gaps.
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%, fully documenting both 'pid' and 'host' parameters. The description itself adds no parameter-level meaning beyond the schema, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('information about a specific process'), which distinguishes it from sibling tools like list_processes that enumerate processes. It does not explicitly name sibling tools or elaborate on what 'information' is included, but the singular 'specific process' provides enough clarity for basic tool selection.
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 this tool is for retrieving details about one known process, contrasting with list_processes for enumeration. However, it provides no explicit when-to-use or when-not-to-use guidance, and does not mention that it can connect to a remote host via SSH as an alternative use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates the safe read nature. The description adds that the tool returns address and traffic statistics, but it does not disclose additional behavioral traits such as whether the optional ssh host changes data source behavior or any other 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?
The description is a single focused sentence with no filler. Key information is front-loaded and every phrase contributes to understanding the tool's purpose.
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?
For a simple read-only tool with one optional parameter, a readOnlyHint annotation, and an output schema, the description is sufficient. The main gap is that it does not explicitly clarify local versus remote host behavior or recommend when to use sibling network tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage of the single optional host parameter with a clear description. The tool description adds no parameter-level semantics beyond what the schema already supplies, so the baseline score of 3 applies.
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 action 'Get' and the resource 'network interfaces', and adds specific detail about address and traffic statistics. This distinguishes it from sibling tools like get_network_connections or get_listening_ports, which target different network resources.
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 context through the resource name and details, but it does not explicitly state when to use this tool versus alternatives such as get_network_connections or get_listening_ports. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description reinforces that this is a read operation but adds no additional behavioral context such as what 'detailed status' includes or whether a remote host uses SSH. With annotations present, the lack of extra disclosure is acceptable but not exceptional.
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 focused sentence that leads with the action and target. Every word earns its place, with no redundancy or filler.
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?
An output schema exists, so return-value structure is covered. The description plus schema provide enough to call the tool correctly for a single service. It loses one point because it does not explicitly route the agent away from sibling tools like get_service_logs or list_services, but this is a minor gap given the read-only annotation and clear core purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are already well documented: service_name has examples and host is described as a remote SSH target. The description itself adds no parameter-level meaning, so the baseline score of 3 applies.
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 states a specific verb ('Get'), a clear resource ('detailed status of a specific systemd service'), and implies a single-service scope. This distinguishes it from sibling tools like list_services and get_service_logs without needing to inspect schemas.
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 use case is implied: this is the tool for checking the status of one named systemd service. However, it does not explicitly say when to prefer this over alternatives such as get_service_logs or list_services, nor does it mention the optional remote-host behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the operation safe, and the description's 'list' wording is consistent with a read-only behavior. The description adds no additional behavioral context beyond that, such as privilege requirements or output nuances, but neither does it omit anything critical for a simple list operation.
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 one short sentence with no filler or redundancy. It is front-loaded with the action and resource, making it immediately scannable for an agent.
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?
For a simple read-only tool with one optional parameter, an output schema, and a clear description, nothing essential is missing. The only minor gap is that the description doesn't explicitly acknowledge the remote host option, though the schema fully covers it.
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%: the only parameter, 'host', is fully described as an optional remote SSH connection target. The description adds no extra parameter semantics, which is acceptable given the schema already handles it.
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 names a specific verb ('list') and resource ('block devices') with scope ('on the system'), clearly identifying the tool's function. No sibling tool covers block devices, so it is easy to distinguish from alternatives like list_directories or list_services.
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 when to use the tool: whenever block devices on the target system need to be listed. However, it offers no explicit guidance about alternatives, prerequisites, or exclusions, leaving the agent to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description consistently says 'List', which matches that annotation. It adds minor context about sorting options but does not disclose behavior such as remote host handling or output truncation beyond what annotations provide.
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, front-loaded sentence states the core action and resource, then appends the sorting capability. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the readOnlyHint annotation, a fully documented 100% input schema, and an output schema, the description is sufficiently complete for correct invocation. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds no parameter-specific meaning beyond mentioning 'sorting options,' which is already detailed in the sort and order_by parameter descriptions.
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 uses a specific verb ('List') and resource ('directories under a specified path'), clearly distinguishing it from sibling tools like list_files. It also mentions sorting options, which adds functional scope.
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 the tool is for enumerating directories at a given path, but it does not explicitly state when to use this tool versus siblings like list_files or read_file. No exclusionary or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. The description adds useful context by listing the specific categories of system information returned. It is consistent with the annotation and gives the agent a clear picture of the read-only nature of the operation.
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, focused sentence that leads with the action and resource, then provides specific examples of the returned information. Every word earns its place, and there is no redundant repetition of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, read-only tool with one optional parameter, the description, along with the schema and annotations, gives the agent everything needed to invoke it correctly. An output schema is present, so return-value details do not need to be in the description. The only minor gap—explicit usage guidance—is covered by the implied scope of 'basic system information.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the sole host parameter, including its type, default, and purpose ('Remote host to connect to via SSH'). With 100% schema description coverage, the description adds no extra parameter-level meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('basic system information'), and enumerates concrete fields: operating system, distribution, kernel version, uptime, and last boot time. This distinguishes it from sibling tools like get_cpu_information or get_network_interfaces, which cover more specialized areas.
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 phrasing 'basic system information' implies this tool is appropriate when broad OS-level details are needed, but it does not explicitly state when to choose it over siblings or when to avoid it. No alternative tools or exclusionary conditions are mentioned, leaving usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![linux-mcp-server MCP server](https://glama.ai/mcp/servers/rhel-lightspeed/linux-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/rhel-lightspeed/linux-mcp-server)

Score Badge

Copy to your README.md:

[![linux-mcp-server MCP server](https://glama.ai/mcp/servers/rhel-lightspeed/linux-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/rhel-lightspeed/linux-mcp-server)

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/rhel-lightspeed/linux-mcp-server'

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