Linux MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between get_cpu_information and get_hardware_information (which includes CPU details), and between get_journal_logs, get_service_logs, and read_log_file (all related to logs). The descriptions help differentiate them, but an agent might still be confused about which to use in some cases.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with all tools using snake_case and clear verbs like 'get', 'list', or 'read'. There are no deviations in naming conventions, making the set predictable and easy to parse.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for a Linux system monitoring server, covering a broad range of system diagnostics. It feels comprehensive without being overwhelming, though it could be streamlined by merging some overlapping tools.
Completeness4/5
The toolset provides extensive coverage for system monitoring, including CPU, memory, disk, network, processes, services, and files. Minor gaps exist, such as no tools for modifying system state (e.g., starting/stopping services or writing files), but agents can perform most read-only diagnostic tasks effectively.
Average 3.4/5 across 19 of 19 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 11 community issues answered or closed in the last 6 months
- 46 commits in the last 12 weeks
- Last stable release on July 8, 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

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 doesn't add any behavioral context beyond this—it doesn't mention whether the tool requires SSH access (implied by the host parameter but not stated), what format the CPU information is returned in, or any performance characteristics. However, it doesn't contradict the annotations, so it gets a baseline score for not adding value beyond what structured data provides.
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 extremely concise at just three words, with zero wasted language. It's front-loaded and to the point, though this brevity comes at the cost of being under-specified. Every word earns its place, but the place is too small to be helpful.
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?
Given that this tool has annotations (readOnlyHint) and an output schema (which covers return values), the description doesn't need to explain safety or output format. However, it completely fails to address the tool's purpose relative to siblings or provide any usage context. For a tool with one parameter and clear siblings, this is inadequate—the description should at least hint at what makes it unique.
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 has 100% description coverage, with the host parameter clearly documented as 'Remote host to connect to via SSH.' The description adds no additional meaning about parameters—it doesn't explain when to use the host parameter versus default null, or how it affects the tool's behavior. With high schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get CPU information' is a tautology that merely restates the tool name and title without adding any meaningful specificity. It doesn't distinguish this tool from sibling tools like 'get_hardware_information' or 'get_system_information' that might also provide CPU-related data. The description fails to specify what kind of CPU information is retrieved (e.g., model, cores, usage, temperature) or how it differs from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, nor does it reference sibling tools that might overlap in functionality. This leaves the agent with no information to make an informed choice between this and other system monitoring tools on the server.
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, indicating a safe read operation. The description adds value by specifying the scope of hardware information retrieved (CPU, PCI, USB, DMI), which isn't covered by annotations. However, it doesn't disclose behavioral traits like performance impact, data freshness, or SSH requirements for remote hosts, leaving gaps in context beyond the annotations.
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, efficient sentence that front-loads the core purpose and lists key information types without unnecessary elaboration. It avoids redundancy and waste, though it could be slightly more structured by explicitly separating local vs. remote usage hints.
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 (1 optional parameter), high schema coverage, presence of annotations, and an output schema, the description is reasonably complete. It specifies the information scope, which complements the structured data. However, it lacks guidance on usage context and remote host implications, which could enhance completeness for an agent.
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 'host' parameter fully documented in the schema as a remote host for SSH. The description doesn't add any parameter-specific details beyond what the schema provides, such as SSH configuration or default behavior. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to heavily.
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's purpose with specific verbs ('Get hardware information') and enumerates the types of information retrieved (CPU details, PCI devices, USB devices, DMI). It distinguishes itself from siblings like get_cpu_information by covering broader hardware aspects, though it doesn't explicitly contrast with get_system_information which might overlap.
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 like get_cpu_information or get_system_information. It mentions remote host capability via the schema, but the description itself lacks explicit usage context, prerequisites, or exclusions, leaving the agent to infer based on parameter names 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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about sorting options and path specification, but doesn't disclose behavioral traits like whether it lists only immediate subdirectories or recursively, what happens with invalid paths, or SSH connection behavior for the 'host' parameter. The description doesn't contradict annotations.
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, efficient sentence that front-loads the core purpose. It wastes no words and is appropriately sized for a straightforward listing tool. However, it could be slightly more structured by explicitly mentioning the optional parameters beyond just 'sorting options'.
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 moderate complexity (5 parameters, SSH capability), good annotations (readOnlyHint), and the presence of an output schema, the description is reasonably complete. It covers the core functionality but could better address the SSH 'host' parameter context and depth of listing. The output schema handles return values, so the description doesn't need to explain them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are well-documented in the schema itself. The description mentions 'various sorting options' which aligns with 'order_by' and 'sort' parameters, but adds no additional semantic meaning beyond what the schema provides. With complete schema coverage, the baseline 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 ('List') and resource ('directories under a specified path'), making the purpose unambiguous. It distinguishes from siblings like 'list_files' by specifying directories only, though it doesn't explicitly contrast with them. The description is specific but lacks explicit 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?
The description provides no guidance on when to use this tool versus alternatives like 'list_files' or other sibling tools. It mentions 'various sorting options' but doesn't explain when sorting is useful or when to choose this over simpler directory listing tools. No exclusions or prerequisites are stated.
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 description adds minimal behavioral context beyond what annotations provide. The annotation 'readOnlyHint: true' already indicates this is a safe read operation. The description doesn't disclose any additional behavioral traits like whether this requires elevated permissions, how it handles remote hosts (via SSH), what the output format looks like, or any rate limits. However, it doesn't contradict the annotation either.
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 perfectly concise at just 4 words. It's front-loaded with the essential information (what the tool does) with zero wasted words. Every word earns its place by specifying both the action and the exact type of resource being retrieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool has rich annotations (readOnlyHint), a comprehensive input schema with 100% coverage, and an output schema (though not shown), the description is minimally adequate. However, for a tool with 6 parameters that can query remote systems via SSH, the description could provide more context about typical use cases, limitations, or how it differs from sibling logging tools. The existence of an output schema means the description doesn't need to explain return values.
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?
With 100% schema description coverage, the schema already documents all 6 parameters thoroughly with descriptions, examples, and defaults. The description adds no additional parameter semantics beyond what's in the schema. It doesn't explain relationships between parameters, provide usage examples, or clarify edge cases. The baseline of 3 is appropriate when the schema does all the heavy lifting.
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 'systemd journal logs', making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_service_logs' or 'read_log_file', which also retrieve logs but from different sources. The description is specific about what type of logs it retrieves but doesn't clarify how it differs from similar logging 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 versus alternatives. There's no mention of when to prefer this over 'get_service_logs' (which might retrieve logs for specific services) or 'read_log_file' (which reads arbitrary log files). No context about prerequisites, typical use cases, or limitations is 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 description adds context about what information is included (size, mount points, utilization), which goes beyond the readOnlyHint annotation that only indicates it's a safe read operation. However, it doesn't disclose other behavioral traits like performance implications, rate limits, or error conditions, so it provides some value but not comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get detailed disk space information') and lists specific inclusions without unnecessary words. Every part of the sentence contributes directly to understanding the tool's 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?
Given the tool's low complexity (1 optional parameter), high schema coverage (100%), presence of annotations (readOnlyHint), and an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It specifies what data is returned, though it could benefit from more usage context to fully guide the agent.
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 has 100% description coverage, with the 'host' parameter documented as 'Remote host to connect to via SSH'. The description doesn't add any parameter-specific details beyond this, so it meets the baseline score of 3, as the schema adequately handles the parameter 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?
The description clearly states the tool's purpose with the verb 'Get' and resource 'detailed disk space information', specifying it includes 'size, mount points, and utilization'. However, it doesn't explicitly differentiate from siblings like 'list_block_devices' or 'get_system_information', which might also provide related system data, so it falls short of a perfect score.
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. It doesn't mention context, prerequisites, or exclusions, such as how it differs from 'get_system_information' or 'list_block_devices' in terms of disk-specific data. This leaves the agent with minimal usage direction.
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, which the description aligns with by using 'Get' (implying a read operation). The description adds value by specifying what details are retrieved (ports, protocols, services), but doesn't disclose additional behavioral traits like rate limits, authentication needs for the SSH host parameter, or potential performance impacts. With annotations covering safety, this is adequate but not rich in context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly states what the tool does, making it highly concise and well-structured for quick understanding.
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?
With annotations indicating a read-only operation, an output schema present (so return values are documented elsewhere), and high schema coverage for the single parameter, the description is mostly complete. However, it could improve by clarifying the tool's scope relative to siblings or mentioning default behavior for the host parameter, but overall it's sufficient given the structured data support.
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 has 100% description coverage, with the 'host' parameter documented as 'Remote host to connect to via SSH'. The description doesn't add any extra meaning beyond this, such as default behavior when host is null or examples of valid hosts. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.
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 'details on listening port, protocols, and services', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_network_connections' or 'get_network_interfaces', which might cover related network information, so it doesn't reach the highest score.
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 the sibling tools for network connections or interfaces. It lacks any mention of context, prerequisites, or exclusions, leaving the agent to infer usage based on 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?
Annotations declare readOnlyHint=true, which the description aligns with by using 'Get' (implying read-only). The description adds value by specifying the scope ('detailed memory including physical and swap'), but doesn't disclose behavioral traits like performance impact, data format, or error conditions 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?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('Get detailed memory including physical and swap') directly contributes to understanding the tool's 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?
Given the tool's low complexity (1 optional parameter), high schema coverage, read-only annotation, and presence of an output schema, the description is reasonably complete. It specifies the memory scope, though it could benefit from more context on usage scenarios or output expectations.
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 'host' parameter fully documented in the schema as 'Remote host to connect to via SSH'. The description adds no parameter-specific information beyond implying memory details, so it meets the baseline for high schema coverage without compensating further.
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 ('detailed memory including physical and swap'), making the purpose unambiguous. It distinguishes from siblings like get_cpu_information or get_disk_usage by specifying memory focus, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as when the optional 'host' parameter should be used for remote connections, or how this differs from related tools like get_system_information.
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 the scope 'active network connections', which provides useful context about what data is returned (real-time vs. historical). However, it doesn't disclose other behavioral traits like whether it requires SSH access (implied by the host parameter but not stated), rate limits, or output format details. With annotations covering safety, a 3 is appropriate—some value added but minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It is front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no redundancy or unnecessary elaboration.
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 (one optional parameter), the presence of annotations (readOnlyHint), and an output schema (which handles return values), the description is reasonably complete. It specifies the scope ('active network connections'), which is crucial for usage. However, it lacks guidance on when to use versus siblings, which is a minor gap in this context.
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 has 100% description coverage, with the host parameter documented as 'Remote host to connect to via SSH'. The description adds no additional parameter semantics beyond what's in the schema. Since schema coverage is high (>80%), the baseline score is 3, as the description doesn't need to compensate but also doesn't enhance parameter understanding.
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 'detailed information about active network connections', which is specific and unambiguous. It distinguishes from siblings like 'get_network_interfaces' (which focuses on interface configuration rather than active connections) and 'get_listening_ports' (which focuses on listening services rather than all active connections). However, it doesn't explicitly contrast with these siblings in the description text itself.
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. It doesn't mention when this tool is appropriate (e.g., for real-time connection monitoring vs. historical data) or when to use siblings like 'get_listening_ports' or 'get_network_interfaces'. There are no explicit exclusions or prerequisites stated.
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 agent knows this is a safe read operation. The description adds value by specifying the type of information returned ('address and traffic statistics'), which goes beyond the annotations. However, it doesn't disclose other behavioral traits like performance implications, rate limits, or authentication requirements for the optional 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?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place by specifying what is retrieved and what details are included, with no redundant or vague language.
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 (one optional parameter), high schema coverage, read-only annotation, and presence of an output schema, the description is reasonably complete. It specifies the scope of information returned, which complements the structured data. However, it could better address when to use this tool over siblings for full completeness.
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 host parameter fully documented in the schema as 'Remote host to connect to via SSH'. The description doesn't add any parameter-specific information beyond what's in the schema. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 ('network interfaces') with specific details about what information is retrieved ('detailed information about network interfaces including address and traffic statistics'). It distinguishes from siblings like get_network_connections by focusing on interface properties rather than active connections. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
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 like get_network_connections or get_system_information. It doesn't mention prerequisites (e.g., SSH access for remote hosts) or exclusions. The agent must infer usage from the tool name and description 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 provide readOnlyHint=true, indicating this is a safe read operation. The description adds minimal behavioral context beyond this, stating it 'gets information' without detailing what information is returned, format, or any constraints like permissions or rate limits. It doesn't contradict annotations, but adds little value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy 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?
Given the tool has annotations (readOnlyHint), high schema coverage, and an output schema, the description is reasonably complete for a simple read operation. However, it could better address the tool's role among siblings and provide more behavioral context, though the structured data compensates well.
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 clear descriptions for both parameters (pid and host). The description doesn't add any semantic details beyond what the schema provides, such as explaining the relationship between pid and host or typical use cases. Baseline 3 is appropriate given 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 clearly states the verb 'Get' and resource 'information about a specific process', making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'list_processes' or 'get_system_information', which reduces clarity about when to choose this specific tool.
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. With siblings like 'list_processes' and 'get_system_information', there's no indication of whether this tool is for detailed info on a single process, how it differs from broader system tools, or any prerequisites for usage.
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 declare readOnlyHint=true, indicating a safe read operation, which the description doesn't contradict. The description adds value by specifying 'detailed status' and 'systemd service', providing context beyond annotations. However, it doesn't disclose behavioral traits like potential errors (e.g., if the service doesn't exist), authentication needs for remote hosts, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy 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?
Given the tool's moderate complexity (2 parameters, 1 required), high schema coverage (100%), annotations (readOnlyHint), and the presence of an output schema, the description is reasonably complete. It specifies 'systemd service' and 'detailed status', which adds useful context. However, it could improve by mentioning the tool's scope (e.g., local vs. remote) or output format hints.
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 has 100% description coverage, with clear documentation for both parameters (service_name and host). The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining what 'detailed status' includes or how the host parameter affects behavior. This 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 clearly states the verb ('Get') and resource ('detailed status of a specific systemd service'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'list_services' or 'get_service_logs', which would require mentioning it provides detailed status rather than just listing or retrieving 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'list_services' (for a simple list) or 'get_service_logs' (for log retrieval), nor does it specify prerequisites like needing systemd or appropriate permissions.
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 minimal behavioral context beyond this, stating it lists devices but not detailing output format, SSH behavior for the host parameter, or system-specific considerations. It doesn't contradict annotations, but adds limited value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
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 simplicity (one optional parameter), high schema coverage, read-only annotation, and presence of an output schema, the description is reasonably complete. It states what the tool does, though it could benefit from more context about output or usage compared to siblings.
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 host parameter fully documented in the schema as 'Remote host to connect to via SSH'. The description doesn't add any parameter-specific information beyond what's already in the structured schema, so it meets the baseline for high 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 verb ('List') and resource ('block devices on the system'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_disk_usage' or 'get_hardware_information', which might also provide related information about storage devices.
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. With siblings like 'get_disk_usage' and 'get_hardware_information' that might overlap with block device information, there's no indication of what makes this tool distinct or when it should be preferred.
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' already indicates this is a safe read operation. The description adds minimal behavioral context beyond this, mentioning sorting options but not covering aspects like pagination, error handling, or performance implications. It doesn't contradict annotations, but adds limited value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized and front-loaded with the essential information, 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?
Given the presence of both annotations (readOnlyHint) and an output schema, the description provides adequate context for this read-only listing tool. The description covers the basic purpose and scope, though it could benefit from more guidance on usage relative to sibling 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?
With 100% schema description coverage, the input schema fully documents all 5 parameters. The description mentions 'various sorting options' which aligns with the schema's 'order_by' and 'sort' parameters, but adds no additional semantic meaning beyond what's already in the structured schema.
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 resource ('files'), and specifies the scope ('under a specified path with various sorting options'). However, it doesn't explicitly differentiate from sibling tools like 'list_directories' or 'list_services', which reduces the score from a perfect 5.
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. It doesn't mention when this tool is appropriate compared to siblings like 'list_directories' or 'list_services', nor does it specify any prerequisites or exclusions for usage.
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, indicating this is a safe read operation. The description adds minimal behavioral context beyond this, as 'List running processes' implies it retrieves current process data but doesn't specify format, pagination, or SSH behavior for the host parameter. With annotations covering safety, a baseline 3 is appropriate, though more detail on output or constraints would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'List running processes' is extremely concise and front-loaded, consisting of just three words that directly convey the tool's purpose. There's no wasted language or unnecessary elaboration, making it highly efficient and easy to parse.
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 (one optional parameter), high schema coverage (100%), annotations (readOnlyHint), and the presence of an output schema, the description is reasonably complete. It states the core action but could better address sibling differentiation or output expectations, though the output schema mitigates the need for return value details.
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 host parameter fully documented in the schema as 'Remote host to connect to via SSH'. The description doesn't add any parameter semantics beyond this, such as default behavior when host is null. Since the schema handles the heavy lifting, the baseline score of 3 is correct.
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 'List running processes' clearly states the verb ('List') and resource ('running processes'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_process_info' or 'get_network_connections', which might also involve process-related operations, so it doesn't achieve 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_process_info' (which might retrieve detailed info for a specific process) and 'get_network_connections' (which could involve processes), there's no indication of this tool's specific context or exclusions, leaving usage ambiguous.
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 provide readOnlyHint=true, indicating this is a safe read operation. The description adds minimal behavioral context beyond this, specifying it lists 'all' systemd services, which implies comprehensiveness but doesn't detail output format, pagination, or SSH behavior for the host parameter. It doesn't contradict annotations, but adds limited value 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 a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by directly stating the tool's 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?
Given the tool's low complexity (one optional parameter), high schema coverage (100%), annotations (readOnlyHint), and presence of an output schema, the description is reasonably complete. It specifies the scope ('all systemd services'), which complements the structured data. However, it could benefit from more context about usage relative to siblings.
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 host parameter fully documented in the schema as a remote host for SSH connection. The description adds no additional parameter semantics beyond what the schema provides, such as default behavior when host is null or SSH requirements. Baseline score of 3 is appropriate since the schema handles parameter documentation.
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 resource ('systemd services'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_service_status' or 'get_service_logs', which also deal with services but provide different information. The description is specific about what it lists but lacks sibling distinction.
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. It doesn't mention when this tool is appropriate compared to siblings like 'get_service_status' (which might check a specific service) or 'get_service_logs' (which retrieves logs). There's no context about use cases or exclusions.
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, which the description aligns with by using 'Read'. The description adds minimal behavioral context beyond annotations: it specifies the method ('using cat'), hinting at Unix command-line behavior, but doesn't detail constraints like file size limits, encoding issues, or error handling. No contradiction with annotations 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, efficient sentence with zero waste. It front-loads the core action ('Read the contents of a file') and adds a minor implementation detail ('using cat') that doesn't detract from clarity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (read-only with annotations), 100% schema coverage, and an output schema (implied by context signals), the description is reasonably complete. It covers the basic action and method, though it could better address usage context and behavioral nuances like error cases or remote host implications.
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 clear docs for 'path' and 'host'. The description adds no parameter-specific information beyond what the schema provides (e.g., it doesn't explain how 'host' enables SSH or clarify 'path' beyond 'Absolute'). Baseline 3 is appropriate as 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 ('Read') and resource ('contents of a file'), making the purpose evident. It distinguishes from siblings like 'list_files' or 'read_log_file' by focusing on reading arbitrary file contents rather than listing or reading specific log files. However, it doesn't explicitly differentiate from 'read_log_file' beyond the general vs. specific file type.
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 like 'read_log_file' for logs or 'list_files' for metadata. It lacks context on prerequisites (e.g., file permissions) or exclusions (e.g., binary files). The mention of 'cat' implies Unix-like systems but isn't explicit about when this is appropriate.
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 provide readOnlyHint=true, which the description doesn't contradict. The description adds minimal behavioral context beyond annotations—it specifies 'log file' but doesn't mention constraints like the allowed list mentioned in the schema, rate limits, authentication needs for remote hosts, or what happens with invalid paths. With annotations covering safety, this earns a baseline score.
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 extremely concise—a single sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, remote host capability) and the presence of both annotations (readOnlyHint) and an output schema, the description is reasonably complete. It specifies the resource type (log file) but could better address sibling differentiation and usage context. The output schema means return values don't need explanation.
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 fully documents all three parameters (log_path, lines, host). The description adds no additional parameter semantics beyond what's in the schema, such as explaining the allowed list or SSH requirements. Baseline 3 is appropriate when the schema does all the work.
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 ('Read') and resource ('a specific log file'), making the purpose unambiguous. However, it doesn't differentiate from the sibling tool 'read_file' which appears to be a more general file reading tool, nor does it mention the 'get_journal_logs' or 'get_service_logs' siblings that might handle different types of 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 provides no guidance on when to use this tool versus alternatives like 'read_file', 'get_journal_logs', or 'get_service_logs'. It doesn't mention prerequisites (e.g., file must exist, path must be in allowed list) or exclusions, leaving the agent to infer usage from context 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?
Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds context about what information is retrieved (e.g., OS, kernel, uptime), which is useful beyond annotations. However, it doesn't disclose behavioral traits like whether it requires SSH (implied by the host parameter but not stated), rate limits, or error conditions. No contradiction with annotations 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, efficient sentence that front-loads the purpose with specific examples. Every word earns its place, with no redundant or vague phrasing, making it easy to scan and understand 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?
Given the tool's low complexity (1 optional parameter), rich annotations (readOnlyHint), and presence of an output schema, the description is mostly complete. It clearly states what information is retrieved, though it could benefit from mentioning the SSH capability or usage context. The output schema likely covers return values, reducing the need for description details.
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 host parameter fully documented in the schema as 'Remote host to connect to via SSH.' The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
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 verb 'Get' and specifies the exact resources: 'basic system information such as operating system, distribution, kernel version, uptime, and last boot time.' It distinguishes from siblings like get_cpu_information or get_memory_information by focusing on general system metadata rather than specific hardware or process details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare to siblings like get_hardware_information (which might overlap) or list_services (which is more specific). Usage is implied by the name and purpose but not explicitly stated.
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 declare readOnlyHint=true, which the description doesn't contradict. The description adds context by specifying 'recent logs' (implying recency) and 'systemd service' (scope), which aren't covered by annotations. However, it doesn't mention rate limits, authentication needs for remote hosts, or output format details, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information.
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 moderate complexity (3 parameters, 1 required), 100% schema coverage, annotations for safety, and an output schema (which handles return values), the description is reasonably complete. It covers the core purpose and scope but could improve by adding usage guidelines or more behavioral context to reach a perfect 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%, with each parameter well-documented in the schema. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining 'service_name' examples or 'host' SSH requirements. Baseline score of 3 is appropriate 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.
Purpose5/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 resource ('recent logs for a specific systemd service'), making the purpose immediately apparent. It distinguishes from sibling tools like 'get_journal_logs' (general logs) and 'get_service_status' (status rather than logs), providing specific differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving service logs but doesn't explicitly state when to use this tool versus alternatives like 'get_journal_logs' or 'read_log_file'. No guidance is provided on prerequisites, exclusions, or specific scenarios where this tool is preferred over others.
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