safe-ssh-mcp

by Areso

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.15
Disambiguation4/5
Most tools target distinct system aspects, but slight overlap exists between get_disk_free/get_disk_usage and get_free_memory/get_memory_pressure. The two file listing tools are differentiated by filter usage, which is clear.
Naming Consistency5/5
All tool names follow a strict 'get_' prefix followed by a descriptive noun phrase (e.g., get_crontab_tasks, get_current_datetime). The pattern is uniform and predictable.
Tool Count4/5
24 tools is on the higher side but reasonable for a comprehensive system diagnostic server. Each tool covers a specific diagnostic need, though a few could be merged (e.g., get_disk_free and get_disk_usage) without loss of clarity.
Completeness3/5
The set covers many essential diagnostics: disk, memory, CPU, processes, systemd, docker, and files. However, it lacks network diagnostics beyond listening sockets, IO stats, and user-related queries, leaving some gaps for a full system assessment.
Average 2.9/5 across 24 of 24 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It fails to disclose that the tool connects via SSH, requires authentication, or what happens when memory pressure is unsupported. No side effects or error behavior described.
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?
Extremely concise but at the expense of necessary detail. Single sentence lacks sufficient information, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of SSH-based tool with 7 parameters and a concept like memory pressure, description is completely inadequate. No output format, error handling, or return value information, despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description does not mention any parameters (host, user, etc.), their purpose, or how they relate to the operation. No compensation for missing schema descriptions.
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?
Description states 'Returns memory pressure if supported', which is vague. It does not specify what memory pressure means or how it differs from sibling tools like get_free_memory or get_ps_aux_top_mem_consumers.
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?
No guidance on when to use this tool vs alternatives. No mention of prerequisites, limitations, or when memory pressure might not be supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'collects via SSH' without mentioning authentication mechanisms, potential side effects (none expected), or error conditions. It is insufficient for safe invocation.
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 a single sentence, which is concise but under-specified for a tool with 7 parameters and no annotations. It does not earn its place by adding value beyond the tool name.
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 the complexity (7 parameters, no annotations, but an output schema exists), the description lacks context on how to use the parameters, what the output contains, or potential failure modes. It is inadequate for autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no parameter details. The agent cannot infer that 'host' is the target host, 'user' the SSH user, or the meaning of 'password', 'key_path', 'timeout', etc. The description fails to compensate for the missing schema descriptions.
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 ('collects'), the resource ('dmesg log'), and the method ('via SSH from a remote Linux host'). It is specific enough to distinguish from siblings like get_service_logs_from_journalctl, though it does not explicitly contrast.
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 usage guidelines are provided. The description does not indicate prerequisites (e.g., SSH access, permissions) or when to prefer this tool over alternatives like get_current_datetime or get_free_memory.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions SSH connectivity but does not disclose potential issues like authentication requirements, key handling, or what happens on connection failure. The behavior is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too brief given the tool's complexity. It front-loads the core action but omits important details, making it minimally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no schema descriptions, no annotations, and an output schema that is not referenced, the description is severely incomplete. It does not explain what the output looks like, error conditions, or prerequisite network access.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 7 parameters are documented in the schema. The description adds no parameter explanations—e.g., what `host`, `user`, or `password` represent. This is a critical gap.
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 collects disk usage via `df -h` from a remote Linux host using SSH. It specifies the verb (collects), resource (disk usage), and method (SSH, remote host), distinguishing it from potentially similar tools like `get_disk_usage` which may be local.
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 on when to use this tool versus alternatives, nor are there any prerequisites or exclusions. The description simply states what it does without contextual usage direction.
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?
With no annotations, the description must disclose behavioral traits. It only lists the output fields but omits that the tool connects via SSH (evident from parameters) or any system commands invoked. It doesn't mention permissions, side effects, or whether it's read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is too brief for the tool's complexity, lacking essential details about usage and parameters.
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 the 7 parameters (2 required) and no schema descriptions, the description is incomplete. It doesn't explain the need for SSH credentials or that it runs remote commands. The output schema exists but doesn't compensate for missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not mention host, user, port, etc., nor their purpose. The description only covers output, leaving parameter usage entirely undocumented for the agent.
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 it returns free memory, swap, page cache, and HugePages. It uses a specific verb and resource, and while it doesn't explicitly distinguish from siblings like 'get_memory_pressure', the resource scope is distinct enough to infer differences.
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 like 'get_memory_pressure'. There are no exclusions or context for appropriate usage, leaving the agent to infer from the name alone.
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?
No annotations exist, so the description must disclose behavioral traits. It only states it gets logs, but fails to mention that the tool connects via SSH (evident from parameters), requires authentication, or is a read-only operation. Security implications, connection behavior, and error scenarios are not described.
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 (7 words) but at the expense of clarity and completeness. It lacks essential context for a tool with 9 parameters, especially regarding remote execution via SSH. Conciseness should not sacrifice informativeness.
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 the tool's complexity (SSH connection, multiple parameters) and no annotations, the description is far from complete. While an output schema exists, the tool's purpose, remote nature, and parameter roles are not sufficiently explained, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for any of the 9 parameters. The description adds no information about parameter meanings or usage, such as the roles of 'host', 'user', 'password', 'lines', etc. This is a critical gap.
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 'Gets' and the resource 'recent journald logs for a specific systemd service'. It distinguishes from sibling tools like get_systemd_status or get_dmesg by specifying logs from journald scoped to a service. However, 'recent' is vague and could be more precise.
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 such as get_systemd_list_all or get_dmesg. There is no mention of prerequisites, when not to use it, or which sibling tools are more appropriate for different scenarios.
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 description only mentions output ordering. It does not disclose that the tool connects via SSH to a remote host, executes a command, or any potential side effects. With no annotations to clarify behavior, this is a significant gap for an agent.
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 very concise (8 words). It gets the main purpose across without excess. While it could benefit from a bit more context, it is not verbose and avoids unnecessary detail.
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 the tool's complexity (7 parameters, SSH connection, top 10 output) and no annotations, the description is inadequate. It lacks mention of connection prerequisites, error handling, and output description. The presence of an output schema slightly reduces the need to explain return values, but the tool's usage context remains underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description adds no parameter explanations. Parameters like host, user, key_path, accept_new_hostkey are left undefined. The agent receives no help in understanding how to fill them, especially complex ones like authentication options.
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 it lists top 10 CPU consumers sorted by CPU descending. It distinguishes from siblings like get_ps_aux_top_mem_consumers (memory) and get_top (general). However, it could be more explicit about the underlying command (ps aux) and the sorting order.
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 on when to use this tool versus alternatives. The sibling set includes many similar tools, but no comparison or selection criteria are provided. The description implies usage for CPU monitoring but lacks context for when to choose this over get_top or others.
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?
No annotations provided. Description only states what it lists, not how it operates (e.g., runs 'ps aux' command), required authentication, or potential side effects. Fails to disclose SSH dependency or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise but omits critical details like parameters and behavior. It is front-loaded with purpose but insufficient for operational use. Concise at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (SSH tool with 7 params, no schema descriptions, no annotations, output schema exists), description is severely incomplete. Does not explain what output contains, command executed, security implications, or error handling. Agent cannot reliably invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 7 parameters with 0% description coverage. Description provides no information about any parameter (e.g., host, user, password, etc.). Agent gets no help understanding required or optional inputs beyond schema structure.
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?
Description uses specific verb 'Lists' and resource 'top 10 mem consumers' with sort direction 'MEM desc'. This clearly distinguishes from sibling 'get_ps_aux_top_cpu_consumers' by focusing on memory consumption.
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 on when to use this tool vs alternatives (e.g., CPU counterpart, or other SSH tools). No mention of prerequisites like SSH credentials, host reachability, or OS requirements. Agent has no context for appropriate invocation.
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?
No annotations exist, so the description carries full burden. It mentions SSH but does not disclose behavioral traits such as authentication methods, error handling, handling of new host keys, timeout behavior, or output format (beyond 'crontab -l output'). This is insufficient for an agent to anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence (16 words). However, it omits critical details, making it under-specified. It is not overly verbose but fails to earn its place by providing sufficient guidance.
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 the tool's complexity (7 parameters, no schema descriptions, no annotations), the description is incomplete. It does not cover authentication, SSH details, output schema interpretation, or error conditions. The presence of an output schema does not compensate for missing usage and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 7 parameters. It does not explain host, user, port, password, key_path, timeout, or accept_new_hostkey. The agent receives no semantic clues about parameter usage beyond the schema types.
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 'collects', the resource 'crontab -l output', and the context 'from a remote Linux host via SSH'. It uniquely identifies what the tool does and distinguishes it from sibling tools which are other system inspection utilities.
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, no prerequisites (e.g., SSH access, user permissions), and no exclusions. An agent would not know if this is the right tool for the task.
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?
With no annotations, the description carries full burden. It mentions 'via SSH' but doesn't disclose that the tool is read-only, what happens on connection failure, authentication methods (password or key), or that it doesn't modify the remote system. The behavior is implied but not explicitly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but incomplete. It front-loads the core action, but missing essential details such as dependencies and behavior. It earns its place but could be more informative without adding excessive length.
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 the complexity of SSH connectivity (7 parameters, authentication, network) and absence of annotations, the description is insufficient. It doesn't cover prerequisites (e.g., SSH access, key management), error scenarios, or expected output, though an output schema exists (not shown here) which may partially mitigate the need to describe return values. Overall, it leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage. The description does not explain any parameter beyond the tool's purpose. It fails to clarify required fields (host, user) or optional fields (port, password, key_path, timeout, accept_new_hostkey), leaving the agent to infer their meaning from names alone.
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 'Collects distr details from os-release from a remote Linux host via SSH', specifying the action (collect), resource (distr details from os-release), and method (via SSH). It differentiates from sibling tools like get_crontab_tasks or get_uptime by focusing on distribution 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 explain prerequisites like SSH credentials being configured or that it should be used to retrieve OS version. The context of siblings implies this is the tool for distribution info, but no explicit 'when to use' or 'when not to use' is given.
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?
No annotations exist, so the description must disclose behavioral traits. It only states the tool checks via SSH but does not explain how it determines installation or if it executes the command, potential side effects, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. It could be longer to add value without being verbose.
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 8 parameters including authentication details and an output schema, the description is too brief. It fails to cover key behavioral aspects like return format, error handling, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 8 parameters, the description adds no meaning beyond the schema. It does not explain parameters like host, user, password, key_path, binary, timeout, or accept_new_hostkey.
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 'Checks' and identifies the resource as 'binary/command installed and callable', clearly distinguishing it from sibling tools that deal with files, disk, or system metrics.
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 alternative methods (e.g., directly running the command) or other sibling tools. The description lacks context for appropriate usage.
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 description does not disclose behavioral traits beyond the basic action. It fails to mention that the tool connects to remote hosts (as indicated by schema parameters like host, user, password), requires authentication, or that it is a read-only operation. Without annotations to supplement, the description carries the full burden and falls short.
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 extremely concise: a single sentence with an emphasis. It avoids unnecessary words. However, the conciseness comes at the cost of completeness; it is efficient but could be considered under-specified for a tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, remote execution implied by schema), the description is severely incomplete. It does not explain that this is a remote SSH-based tool, how to handle authentication, or what the output schema yields. An output schema exists but its content is unknown; the description should provide at least a summary of the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 7 parameters have descriptions. The description adds no information about any parameter, such as the meaning of 'host', 'user', or 'password'. The statement 'Lists all systemd timers' does not clarify the role of parameters. The agent receives no help understanding how to populate the inputs.
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 'Lists all systemd timers' and emphasizes its purpose with 'USE THIS TOOL to check for timers.' It is specific about the resource (systemd timers) and action (lists). However, it does not explicitly differentiate from sibling tools like get_systemd_list_all or get_systemd_list_failed, which could list timers as part of a broader set.
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 provides a usage directive ('USE THIS TOOL to check for timers'), which gives context for when to use it. However, it offers no guidance on when not to use it, no mention of alternatives (e.g., get_systemd_list_all for all units), and lacks prerequisites or contextual hints about remote execution.
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?
Minimal disclosure. No annotations exist, so description should cover SSH authentication, potential timeouts, or that it returns process snapshot text. Only states 'snapshot' without details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 10 words, front-loaded action. Could be more informative without being verbose; borderline under-specified.
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?
With 7 parameters and no schema descriptions, the tool description is insufficient for correct invocation. Lacks security and usage context despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description adds no parameter explanation. Host, user, password, key_path, timeout, accept_new_hostkey are all undocumented.
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 ('collects top's snapshot') and the resource ('remote Linux host via SSH'). It distinguishes from sibling tools like get_disk_free or get_uptime by specifying the top command.
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 on when to use this tool vs alternatives like get_ps_aux_top_cpu_consumers. No mention of prerequisites or context.
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?
No annotations are provided, so the description carries full burden. It states it runs 'df -i' via SSH, but fails to disclose authentication methods, potential for connection failures, timeout behavior, or output format. The behavioral disclosure is minimal.
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 clear sentence with no fluff. It could benefit from additional structure but remains appropriately concise for a simple tool.
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 the complexity of SSH-based tools (authentication, timeout, host key acceptance) and 7 parameters with no schema descriptions, the description lacks crucial details about how to invoke the tool correctly. The existence of an output schema is noted but not leveraged to reduce description burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameters are described in the schema. The description does not explain any of the 7 parameters (host, user, port, password, key_path, timeout, accept_new_hostkey), leaving the agent to infer their meaning from names alone.
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 'collects', resource 'inode usage', and method 'via SSH' with the specific command 'df -i'. It distinguishes from sibling tools focused on disk space by specifically mentioning inodes.
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_disk_free or get_disk_usage. No prerequisites or exclusions are mentioned, which is critical given the 24 sibling tools.
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 description only adds 'via SSH' as a behavioral trait. With no annotations, the description should disclose whether the tool is read-only, requires authentication, has side effects, or may fail under certain conditions. It does not cover these aspects, leaving significant gaps in understanding.
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 front-loaded. It is not wasteful, but could be more informative without increasing length significantly. However, it earns its place by stating the core function.
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?
Despite having an output schema, the tool has 7 parameters and no parameter descriptions. The description does not explain authentication methods, potential failure modes, or why one would use this over sibling tools like get_disk_usage. It is incomplete for a remote command execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no information about parameters. While parameter names are somewhat self-explanatory, the description fails to compensate for the lack of schema descriptions by clarifying optionality, defaults, or relationships among parameters.
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 collects lsblk output via SSH from a remote Linux host. It uses specific verbs and resource names, and clearly distinguishes from sibling tools like get_disk_free or get_disk_usage, which address different aspects of disk information.
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 does not mention prerequisites (e.g., SSH access, necessary permissions) or scenarios where this tool is preferred over other system info tools.
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?
No annotations are provided, so the description bears full responsibility. It only states that the tool lists units and can check statuses, but does not describe any behavioral traits (e.g., authentication requirements, rate limits, or what happens with connection errors). The description is too minimal to inform the agent about side effects or constraints.
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—two short sentences that directly convey the tool's purpose. There is no wasted text, and the key instruction is front-loaded. It earns its space.
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 7 parameters (2 required) with no descriptions, and no output schema description, the tool description fails to provide necessary context for correct invocation. The description does not explain how to use parameters or what the output looks like. The presence of an output schema does not compensate for the lack of parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for any of the 7 parameters. The tool description does not add meaning to any parameter (e.g., host, user, port, password). This leaves the agent with no guidance on how to fill these fields.
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 explicitly states 'Lists all systemd units' and clarifies it can be used to check for running, stopped, or failed services. The purpose is clear and the verb 'lists' specifies the action, though it does not distinguish from sibling tools like get_systemd_list_failed.
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 provides direction on when to use ('to check for running, stopped, or FAILED daemon/service/unit'), but does not mention when not to use it or mention alternative tools, such as get_systemd_list_failed for failed units only.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention that the tool uses SSH (implied by parameters like host, user, password, key_path) or that it may require elevated privileges. The remote execution aspect and potential for large output are not disclosed, which is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too terse given the tool's complexity (8 parameters, remote execution). It front-loads the purpose but sacrifices necessary detail. Every word earns its place, but the description could be expanded to cover key aspects without losing conciseness.
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?
Despite having an output schema, the description does not mention what the tool returns (status, logs, error messages are mentioned but not structured). The 8 SSHs-related parameters are not contextualized—an agent might not realize this tool connects to a remote host. Given the complexity, the description is incomplete and leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 8 parameters (daemon, host, user, port, password, key_path, timeout, accept_new_hostkey). The term 'SPECIFIC' hints at the 'daemon' parameter but provides no semantics for connection details or other parameters. This severely hinders correct invocation.
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 explicitly states 'Gets the detailed status, logs, and error messages for a SPECIFIC systemd daemon/service/unit.' This clearly identifies the tool's purpose: retrieving comprehensive information for a single systemd unit. It distinguishes itself from siblings like get_systemd_list_all and get_service_logs_from_journalctl by focusing on specificity.
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 when a specific systemd unit is known ('SPECIFIC') but does not explicitly state when to use or avoid this tool, nor does it provide guidance on alternatives. No usage context, prerequisites, or exclusions are mentioned, leaving the agent to infer from the sibling names.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions SSH but does not disclose crucial behaviors like authentication methods, host key handling, error scenarios, or the nature of the output (e.g., whether it returns raw command output). The description is too minimal to adequately inform an agent about side effects or requirements beyond the explicit parameters.
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 efficiently communicates the tool's core function. It is front-loaded with the key action. However, it could be restructured to include brief parameter context without becoming verbose. Still, it earns a 4 for being succinct and to the point.
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 the tool's complexity (7 parameters, SSH-based operation, output schema present) and lack of annotations, the description is insufficiently complete. It does not explain prerequisites (SSH access), parameter roles, output format, or error handling. The presence of an output schema partially offsets the need for return value explanations, but other contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for 7 parameters, yet the description does not mention any parameter (host, user, port, password, key_path, timeout, accept_new_hostkey). The description adds no value beyond what the schema already provides, failing to compensate for the lack of parameter descriptions. This is a significant gap.
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 collects 'ss -tulpn output (open ports and sockets)' from a remote Linux host via SSH, matching the tool name 'get_listening_sockets'. The verb 'collects' and specific command and resource make the purpose unambiguous, and the unique function distinguishes it from siblings like disk or process tools.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. However, given the sibling tools are all about different system metrics, the purpose is distinct enough that usage context is implied. A score of 3 reflects no explicit guidance but clear uniqueness from context.
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?
With no annotations, the description must convey behavior fully. It mentions SSH, indicating a remote operation, but fails to disclose whether a new connection is opened, potential side effects (e.g., host key acceptance), error handling, or the fact that it requires network access. This is insufficient for a tool with 7 parameters.
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, front-loaded with the essential information. No unnecessary words or redundancy.
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 the tool has 7 parameters and no schema descriptions, the description is too brief. It does not explain what the output (datetime) looks like despite an output schema existing, nor does it cover parameter details or prerequisites like SSH key setup. The 'via SSH' hint is insufficient for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the schema provides no parameter explanations. The description does not add any parameter semantics, ignoring all 7 parameters (host, user, port, password, key_path, timeout, accept_new_hostkey). This is a critical omission.
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 collects current datetime from a remote Linux host via SSH. The verb 'collects' and resource 'current datetime' are specific, and it distinguishes itself from sibling tools like get_disk_free or get_memory_pressure which focus on other system metrics.
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 datetime over SSH but does not provide explicit guidance on when to use this tool vs alternatives, such as checking if SSH is available or comparing with other remote data tools. No when-not-to-use conditions 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 description discloses that the tool uses SSH and runs 'ls -lah', but with no annotations provided, it fails to mention behavioral traits like authentication methods (password/key), host key verification, or error handling. Some context is given, but it is incomplete for a full transparency score.
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 concise (two sentences) and front-loaded with purpose. However, it could include more detail without excessive length, such as parameter explanations, making it slightly less than perfect in structure.
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 the complexity (8 parameters, no annotations, output schema exists), the description lacks essential context such as authentication mechanisms, host key handling, and the nature of the output (though it hints at '-lah'). It is not complete enough for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain all 8 parameters. However, it only mentions 'abs_path' and implies 'host' via 'remote Linux host', leaving parameters like 'user', 'port', 'password', 'key_path', 'timeout', and 'accept_new_hostkey' unexplained. This is insufficient compensation.
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 collects a list of files from a specific absolute path on a remote Linux host via SSH, and specifies it returns with the '-lah' option. This distinguishes it from the sibling tool 'get_list_of_files_with_filter' which implies filtering capabilities.
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 like 'get_list_of_files_with_filter'. The description only implies usage for basic file listing without exclusions or context about when to choose one over the other.
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?
No annotations are provided, so the description must cover behavioral traits. It does specify it connects via SSH to a Linux host, implying network access and credentials are needed. However, it does not mention authentication handling, potential failures, or the underlying command used (e.g., 'uptime'). This is adequate but incomplete.
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 sentence that immediately conveys the tool's purpose. No filler or redundant information.
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 the tool's complexity (remote SSH with 7 parameters) and lack of annotations, the description is too brief. It omits important context like return value expectations (though output schema exists), authentication methods, or error scenarios. More details are needed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameter roles. It does not. While parameter names like 'host' and 'user' are self-explanatory, others like 'accept_new_hostkey' and 'key_path' are not described, and no hints are provided about their purpose or defaults.
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 ('collects uptime'), resource ('from a remote Linux host'), and method ('via SSH'). This distinguishes it from sibling tools that focus on other system information like disk usage or crontab tasks.
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 fetching system uptime remotely, but provides no explicit guidance on when to prefer this tool over alternatives or exclusion criteria. The context (sibling tools) suggests it's part of a suite, but differentiation is not 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?
With no annotations, the description carries the full burden. It states the tool collects disk usage via SSH and returns top 20 items, implying it is read-only and non-destructive. However, it does not disclose error handling, timeout behavior, or authentication needs beyond what the schema implies.
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 two sentences with no extraneous content. It front-loads the action and output, making it easy to scan.
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 description covers the core function and output format but omits details on connection requirements, authentication methods, and error scenarios. Given the tool's complexity (8 parameters, remote SSH execution), more context is needed for safe and proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only mentions 'abs path' among 8 parameters. It fails to explain other key parameters like host, user, password, key_path, port, timeout, and accept_new_hostkey, which are critical for SSH connections.
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 collects disk usage for a specific path via SSH and returns the top 20 largest items. It distinguishes from siblings like get_disk_free (free space) and get_list_of_files (no size sorting).
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 checking disk usage but does not explicitly compare to alternatives or state when not to use this tool. No guidance on prerequisites such as SSH access or authentication methods.
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?
With no annotations, the description carries full behavioral disclosure. It correctly indicates network connectivity and SSH authentication are required. However, it does not disclose potential failure modes (e.g., host unreachable, Docker not installed) or the output format, leaving gaps in transparency for a command execution tool.
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?
One sentence with no superfluous words; action, resource, and method are front-loaded. Every word is necessary.
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 the presence of an output schema, return value details are likely covered. However, the description lacks mention of prerequisites (Docker, SSH access), error conditions, or authentication methods. For a simple remote command tool, it is functional but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter description coverage is 0%, so the description must compensate. It mentions 'via SSH', hinting at host, user, port, etc., but does not explain meaning or constraints for any parameter (e.g., host format, password vs key authentication). The agent must rely on parameter names, which may be ambiguous (e.g., 'password' without format).
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 collects 'docker ps --all' output from a remote Linux host via SSH. The verb 'collects' and the specific command identify the action, and it distinguishes itself from sibling tools, none of which are Docker-related.
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 Docker container status from a remote host, which is clear from the context. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like Docker being installed on the remote host.
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?
No annotations are provided, so the description must disclose behavioral traits. It indicates a read operation (listing), implies non-destructiveness, but does not mention authentication, rate limits, or behavior when no failed units exist. The transparency is adequate but basic.
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 very short (one sentence plus an explicit usage instruction), front-loading the core purpose. However, it could be more informative, for example by briefly noting that it connects via SSH. It is concise but somewhat under-specified.
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 seven parameters (two required) with no schema descriptions, the description is far from complete. It does not explain how to use parameters or handle authentication. While an output schema exists, the description still leaves significant gaps in understanding tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning no parameter descriptions. The tool description adds no information about parameters (host, user, port, etc.), failing to compensate for the lack of schema documentation. Users must infer usage from parameter names alone.
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 explicitly states that the tool 'Lists failed systemd units' and urges to 'USE THIS TOOL to check for FAILED daemons/services/units.' This clearly distinguishes it from sibling tools like get_systemd_list_all (lists all units) and get_systemd_list_timers (lists timers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear directive on when to use the tool ('to check for FAILED daemons/services/units'), but does not explicitly state when not to use it or mention alternatives, which would improve guidance given the 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?
With no annotations, the description carries full burden. It mentions SSH and -lah, hinting at read-only behavior, but does not explicitly state non-destructive nature, auth needs, or rate limits. Additional context like 'remote Linux host via SSH' provides some 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?
Two concise sentences, front-loaded with the core purpose. No unnecessary words or repetition.
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 an output schema and 9 parameters, the description covers the essential functionality (SSH, filter, abs_path). It could mention more parameters, but is adequate for a straightforward listing tool. Output schema likely explains 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?
Schema description coverage is 0%, so description must compensate. It explains 'abs_path' and 'filter' (grep), but 7 other parameters (host, user, port, password, key_path, timeout, accept_new_hostkey) receive no explanation beyond the implicit 'via SSH' context. Partial compensation.
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?
Description clearly states it collects a list of files from a remote Linux host via SSH with a filter (grep) applied, specifically naming the -lah option. This distinguishes it from the sibling 'get_list_of_files' which presumably does not filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies the tool is for filtered file listing over SSH, which is clear context, but does not explicitly state when to avoid it or suggest alternatives like 'get_list_of_files' for unfiltered results.
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:

[![safe-ssh-mcp MCP server](https://glama.ai/mcp/servers/Areso/safe-ssh-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Areso/safe-ssh-mcp)

Score Badge

Copy to your README.md:

[![safe-ssh-mcp MCP server](https://glama.ai/mcp/servers/Areso/safe-ssh-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Areso/safe-ssh-mcp)

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/Areso/safe-ssh-mcp'

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