MCP SSH Manager

Server Quality Checklist

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

Latest release: v3.8.0
Disambiguation2/5
Several tools have overlapping purposes: ssh_execute and ssh_session_send both run commands; ssh_db_dump, ssh_backup_create, and ssh_db_import overlap on database backups/restores; ssh_monitor, ssh_health_check, and ssh_alert_setup all inspect CPU/memory/disk. The distinction between ssh_alias and ssh_command_alias is particularly confusing, and the agent may misselect among these without careful reading.
Naming Consistency4/5
All tools share the ssh_ prefix and mostly use a noun_verb (e.g., ssh_session_list, ssh_backup_create) or action_noun (ssh_execute_sudo, ssh_tunnel_create) pattern. Names are readable and consistent in style, though ssh_hooks, ssh_profile, and ssh_alias are less pattern-based than the others, and ssh_alias vs ssh_command_alias is a notable collision.
Tool Count2/5
37 tools is well above the 25-tool threshold for a heavy tool set. While an SSH manager may legitimately cover many subdomains, the set includes redundancies (e.g., db_dump vs backup_create, monitor vs health_check) and could be consolidated to around 25–30 tools without losing functionality. The count feels bloated rather than tightly scoped.
Completeness3/5
The tool surface covers a wide range: sessions, execution, file transfer, deployment, tunnels, backups, databases, monitoring, and local configuration. However, there are notable gaps: no tools to add, update, or remove server definitions (only list_servers), no service start/stop/restart (only status), and no way to start or launch processes (only kill/list). These are common SSH operations and would require workarounds.
Average 4.5/5 across 37 of 37 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 20 of 20 community issues answered or closed in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
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?
Discloses local-only configuration with no remote side effects and mentions restart requirement. Lacks details on return format 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose first, then actions. Informative but slightly wordy; could be more concise.
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?
Without output schema, the description covers purpose, actions, side effects, and restart requirement. Adequate for moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond the schema by describing each action's behavior and specifying that profile is for switch. Schema already covers parameter definitions.
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 manages SSH Manager profiles for project types, with local-only effects. It distinguishes from siblings by emphasizing local configuration but does not explicitly differentiate from other SSH profile-related 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?
Explains actions (list, current, switch) and that switch requires the profile argument. Implies usage but does not provide when-not-to-use or alternatives.
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?
No annotations provided, so description carries full burden. It discloses persistence of add/remove, read-only nature of list, and the requirement for server existence. It does not specify behavior on duplicate alias or error handling, but is sufficient.
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?
Description is concise (5 sentences) and front-loaded with purpose. Every sentence adds value, no redundancy. Efficiently covers actions, parameters, and prerequisites.
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 no output schema and simple CRUD nature, description covers the main usage: actions, required parameters, and prerequisites. It is complete enough for an AI agent to use correctly, though minor details like overwriting existing aliases are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but description adds context: explains the action enum values, and clarifies that alias is for add/remove while server is for add only. This adds meaning beyond the 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 it manages local name aliases for servers, with specific actions (add, remove, list). It distinguishes the tool from general SSH tools but does not explicitly differentiate from sibling 'ssh_command_alias'.
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 explains when to use (to reference a server by a shorter name) and outlines the actions with prerequisites (server must exist for add). It does not provide explicit when-not-to-use, but the context is clear.
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?
With no annotations, the description carries full burden. It declares read-only behavior and explains default directory and filtering, but could mention error conditions.
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 concise and well-organized, front-loading the main purpose and logically adding details.
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 three parameters and no output schema, the description adequately covers inputs, defaults, and return content, though pagination or ordering is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds value by explaining the default for backupDir and the effect of the type filter.
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 lists existing backups with specific return fields. It is distinct from sibling tools like ssh_backup_create and ssh_backup_restore.
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 reading backups but does not explicitly compare to siblings or state when not to use it.
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?
Discloses mutation of remote filesystem and crontab, and the need for root. Mentions retention deletion. However, it does not specify idempotency (e.g., overwriting an existing schedule) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. Every word adds value, with no redundancy.
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?
Covers core mechanism, requirements, types, and retention. Missing details on idempotency and output, but adequate given no output schema and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about the retention default (7 days) and the behavior of the generated script, slightly exceeding the schema.
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 schedules recurring backups by writing a bash script and installing a crontab entry. It distinguishes from sibling tools like ssh_backup_create (one-time) and ssh_backup_list/restore.
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?
No explicit guidance on when to use this tool versus alternatives. It implies usage by describing the function, but does not mention when not to use it or point to siblings for one-time backups.
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 carries full burden. It discloses return format (raw command output as text) and database-specific restrictions, but lacks details on error handling, authentication requirements, or potential timeouts.
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 compact (three sentences) and front-loaded with the core purpose, followed by constraints and specifics. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters (4 required) and no output schema, the description covers the main functionality and constraints adequately. It could be enhanced with more details on error states or output format, but it is sufficient for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the query parameter's behavior (SELECT only for SQL, find for Mongo) and the collection parameter's necessity for MongoDB, going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a read-only query against a remote database, specifying constraints for MySQL/PostgreSQL (SELECT only) and MongoDB (find() with collection). This distinguishes it from sibling tools like ssh_db_dump or ssh_db_import.
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 provides context for when to use (read-only queries) and what limitations apply (rejected keywords, MongoDB collection requirement). However, it does not explicitly state when not to use or list alternative tools among siblings.
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?
No annotations present, so description must stand alone. Explicitly states it is read-only and changes nothing on the remote host. Describes output structure (overall status, CPU, memory, disk, uptime) and parameter effect. Does not disclose authentication or error handling, but sufficient for basic 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 sentences, no wasted words. Front-loaded with purpose and output, then parameter details. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 simple parameters and no output schema or annotations, the description provides a clear picture of what it does and what it returns. Lacks error conditions or SSH failure behavior, but overall sufficiently complete for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning: 'named server' clarifies the server parameter, and 'set detailed to true to additionally include load average and network metrics; it defaults to false' explains the boolean's effect beyond schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs a comprehensive read-only health check on a named server via SSH, returning parsed JSON with specific metrics. Distinguishes from siblings like ssh_execute and ssh_monitor as it is read-only and focused on health 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?
Implies usage for health checks but lacks explicit guidance on when to use versus alternatives like ssh_monitor or ssh_execute. No when-not or exclusion conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: stateful, side-effecting, establishes SSH connection, preserves working directory/environment/history, and consumes a shell until closed. Minor omission of resource limits or error conditions.
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?
Three sentences with no wasted words. Front-loaded with purpose, then key behavioral details, then session lifetime. Every sentence adds value.
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?
The description covers the essential aspects: purpose, statefulness, contrast with sibling, session lifetime. Lacks details about the generated session ID format or concurrency limits, but overall adequate for a session start tool.
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 coverage is 100%, so baseline is 3. The description adds that the optional 'name' is 'only a human label', which provides slight extra meaning beyond the schema description.
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 'opens' and the resource 'persistent interactive shell', and explicitly distinguishes from the sibling 'ssh_execute' by contrasting stateful vs. one-shot behavior.
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 provides clear context for when to use this tool (for stateful shell operations) and contrasts with ssh_execute, but does not explicitly exclude other siblings like file transfer tools.
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?
With no annotations, the description carries full burden. It discloses read-only nature, compression defaults, supported DB types, and that tables parameter is ignored for MongoDB. It could be improved by mentioning SSH authentication requirements or error handling.
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 efficient sentences front-load the core action and read-only guarantee. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description covers key behaviors like DB type specifics and compression. Lacks details on output file format (e.g., .sql) and restoration hints (though pg_restore is mentioned for postgresql).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: explains compress defaults, tables ignored for MongoDB, and specific flags used for each DB type, which goes beyond what the schema provides.
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 dumps a database to a remote file over SSH, emphasizing it is read-only. It specifies supported database types and distinguishes from sibling tools like ssh_db_import or ssh_backup_create.
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 context for when to use (dumping databases) and notes read-only behavior, but does not explicitly mention when not to use or contrast with alternative sibling tools for backup or import.
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?
With no annotations provided, the description fully discloses behavioral traits: toggling persists and affects later operations, no immediate remote action, and the need for hook name for enable/disable. It does not contradict any annotations (none present). Minor gap: does not mention permissions or side effects, but adequate for a simple config 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?
The description is a single, well-structured paragraph that front-loads the purpose, then details each action. No wasted words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (1 required), no output schema, and low complexity, the description fully explains all actions, behavior, and persistence. An agent can correctly select and invoke the tool based on this description alone.
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 coverage is 100% with descriptions for both parameters. The description adds behavioral context for each action (e.g., 'list shows each hook with its enabled state') but does not add new parameter-level details beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'manages' and the resource 'automation hooks that fire around SSH operations'. It distinguishes from siblings by focusing on hook management, which is unique among the listed sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool (for managing hooks) and explains the context of each action (list, enable, disable, status). It explicitly states 'no immediate remote action' to clarify scope. However, it does not explicitly mention when not to use this tool or suggest alternatives.
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, description carries full burden. It declares read-only behavior and resolves common names automatically. However, it does not cover authentication requirements or edge cases like unrecognized services.
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 well-structured sentences: first sentence states purpose and output, second adds read-only nature and parameter details. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description clearly explains return format (JSON per service, counts, health rating). Parameters are fully described, and required parameters are noted. Sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. Description adds value by stating services parameter is required, providing examples (nginx, mysql, docker), and noting automatic resolution of common names to unit names.
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 identifies the action (checks running state), resource (named system services on remote server), and mechanism (over SSH). It distinguishes itself from siblings like ssh_health_check or ssh_process_manager by focusing on system service status.
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 explicitly states it is read-only, guiding when to use it (inspection) vs. management tools. It requires the services array and gives examples, but does not explicitly list alternative tools for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It discloses that the tool mutates remote state, is not idempotent, updates session context with cd/export, uses a bash-style shell, enforces server security policy, and has a default timeout of 30000 ms. This level of detail is exemplary.
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 about 100 words, front-loads the core action, and every sentence adds value. There is no redundancy or fluff.
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 behavior, parameters, and security but lacks information on the return value (command output). Given the absence of an output schema, this omission reduces completeness for an agent expecting to consume results.
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 coverage is 100%, so baseline is 3. The description adds context for 'session' (from ssh_session_start) and 'timeout' (default 30000 ms), but these are minor additions. It does not significantly enhance understanding beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a command in an open session, reusing working directory, environment, and history. It distinguishes itself from sibling tools like ssh_session_start (which begins a session) and ssh_session_list, making the purpose unmistakable.
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 explains that the tool is for executing commands in an existing session and that stateful changes like cd/export affect subsequent calls. It does not explicitly contrast with alternatives like ssh_execute (which runs standalone commands without session state), but the context is reasonably clear.
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?
With no annotations provided, the description carries full burden. It discloses that the tool is read-only, that 'follow' mode streams output to stderr and returns only a session note, and that setting follow=false returns the last N lines. This covers the key behavioral nuance and potential side-effect (output not returned in follow mode). It could mention error handling or server prerequisites, but overall it is transparent.
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 two sentences that efficiently convey purpose, read-only guarantee, and crucial parameter behavior. It is front-loaded with the core action. While it could be more structured (e.g., bullet points for modes), every sentence earns its place and no information is redundant.
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 no output schema, the description explains what the tool returns in each mode (content in follow=false, session note in follow=true). It covers the main parameters and their implications. It does not discuss error handling, authentication, or server configuration, but the context from sibling tools and common usage patterns suggests these are covered elsewhere. The description is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the semantics of 'follow' (streaming vs static), the default value for 'lines' (10), and the effect of 'grep' filtering. This goes beyond the schema's property descriptions, which only note defaults. The description also clarifies the response behavior dependent on 'follow'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Reads the tail of a remote log file'. It clearly identifies the resource (log file on a named server) and the operation (tail with optional grep filter). This distinguishes it from sibling tools like ssh_execute which could run arbitrary commands, making its purpose unambiguous.
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 explains that the tool is read-only and does not modify remote state, guiding when to use it. It provides critical context on the 'follow' parameter behavior, recommending setting follow=false to capture output directly. However, it does not explicitly name alternative tools for similar tasks, such as consulting logs via ssh_execute or other means.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: set is mutating, may need write access to /etc, is blocked on readonly servers; get and check are read-only; check errors if no config. This level of detail is comprehensive and leaves no ambiguity about side effects or prerequisites.
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 five sentences, each providing essential information without redundancy. It front-loads the main purpose and efficiently covers actions, side effects, and constraints. Every sentence earns its place, and there is no unnecessary verbosity.
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 complexity (6 parameters, 3 actions, no output schema), the description covers the key aspects: action behavior, file path, permissions, and error condition. However, it does not describe the return format for get or check actions, which could be useful for an AI agent. Still, it is largely complete and sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes all parameters. The description adds only minor context (e.g., 'enabled defaults to true') that is not already in the schema. Baseline 3 is appropriate since the schema handles parameter semantics well and the description offers minimal additional 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 uses specific verb ('configures and evaluates') and resource ('CPU, memory, and disk usage alert thresholds for a remote server'). It clearly distinguishes three actions (set, get, check) and is readily differentiated from sibling tools that focus on SSH management tasks like backups, commands, and sessions.
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 explains when to use each action: set writes configuration, get reads config, check compares metrics. It notes that set is mutating and may require write access, while get and check are read-only. It also warns that check errors if no config exists. This provides clear context but does not explicitly exclude situations or compare with other tools, keeping it slightly from a perfect score.
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?
No annotations are provided, so the description carries full responsibility. It explicitly discloses local-only persistence, no remote side effects, and that list is read-only with derived groups not editable here. This adds important behavioral context beyond a simple 'manages groups' statement, though it stops short of describing return values or error handling.
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 three sentences, densely packed with essential information: core purpose, operation list, parameter requirements, read-only caveats, and optional behavior. It is front-loaded and every sentence adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (six actions, seven parameters, no output schema), the description covers the critical aspects: what each action does, per-action parameter requirements, local vs remote effects, and the derived-group nuance for list. It doesn't detail return values, but for a configuration management tool the description is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful conditional semantics: 'Every action except list requires name; add-servers and remove-servers also require a non-empty servers array' and explains that optional parameters set default execution behavior. This goes beyond the schema by linking parameters to specific actions.
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 identifies the tool as managing named server groups for ssh_execute_group, listing the specific actions (create, update, delete, add-servers, remove-servers, list) and scope (local configuration only). This distinguishes it from sibling tools like ssh_execute_group or ssh_list_servers.
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 notes that groups are 'used by ssh_execute_group', providing context for when to use this tool. It also explains the special read-only behavior of list for derived groups and clarifies that derived groups change via SSH configuration editing. While it doesn't explicitly state exclusions like 'use ssh_execute_group for execution', the related sibling is named and the role is clear.
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?
With no annotations, the description carries the burden. It discloses mutation (accept, remove), readonly server blocking, and caution for autoAccept. It could add more detail on idempotency or error behavior, but it is sufficient.
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 three sentences, front-loaded with purpose, and covers all key details without unnecessary words. Every sentence adds value.
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 three parameters and no output schema, the description covers purpose, actions, server requirement, readonly limitation, and autoAccept. It does not describe output format for list/check/verify, but it is reasonably complete for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning: explains each action's effect, server requirement, and autoAccept caution. This goes beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages SSH host key fingerprints in the known_hosts file, with specific actions. It is distinct from sibling tools which cover different SSH operations like execution, connection status, etc.
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 explains when actions like accept/remove are read-only vs mutating, notes that they are blocked on readonly servers, and cautions about autoAccept. It also specifies that server is required except for list. This provides clear usage context, though it does not explicitly compare to other tools.
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?
With no annotations, the description fully explains behavioral traits: read-only vs mutation, readable servers blocking kill, defaults for signal/sortBy/limit, and pid dependency. Missing error handling or side effects, but adequate.
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?
Three succinct sentences. First introduces overall purpose, second delineates actions with safety hints, third summarizes defaults and constraints. No waste, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 7 parameters with their dependencies and defaults, explains action-specific requirements, and notes server-level constraints. No output schema, but the description is self-sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds significant value: explains pid relevance per action, defaults for signal, sortBy, limit, and filter usage. This exceeds the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's three actions (list, info, kill) on remote processes, using specific verbs and resource. It distinguishes read-only vs mutation operations, making the purpose unambiguous.
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 per-action guidance (e.g., pid required for kill/info, kill blocked on readonly servers) but does not compare this tool with sibling SSH tools or indicate when to prefer it over alternatives.
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?
With no annotations, the description discloses key behaviors: backup types, conditional parameter requirements, pruning by retention, default compress=true, and pre/post hooks. It does not mention potential side effects like overwrite behavior or failure modes, but coverage is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph without fluff. It is front-loaded with the main action and efficiently covers all key points: what it does, types, constraints, defaults, and additional behaviors (hooks, pruning).
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 complexity (13 params, 4 types, conditional requirements, defaults, pruning, hooks), the description is mostly complete. It mentions output (compressed archive + JSON metadata) but does not describe the return value or success/failure indicators. However, for a creation tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: clarifies defaults (backupDir, retention, compress), conditional requirements (database for db types, paths for files), and explicitly warns that 'full' errors. This is highly informative.
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 'Creates a database or file backup' with specific resources (remote server, compressed archive, metadata file). It distinguishes from sibling tools like ssh_backup_list, ssh_backup_restore, and ssh_backup_schedule.
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 provides clear context on when to use the tool (creating backups) and notes that 'full is not yet implemented and errors'. It does not explicitly state when not to use it or mention alternatives, but sibling names suffice for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses destructiveness, overwrite behavior, specific commands for each database type, and the existence of pre/post-restore hooks. There are no contradictions or missing critical behavioral details.
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 well-structured with multiple sentences that convey essential information without redundancy. It is front-loaded with purpose and then details behavior. Could be slightly more concise, but overall effective.
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 complexity (9 parameters, no output schema), the description covers purpose, behavior, supported engines, hooks, and parameter usage. It does not mention return value or error handling, but for a restore tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 9 parameters. The description adds value by explaining that database restore uses the 'database' parameter and files restore uses 'targetPath' with default '/', plus the 'backupDir' default. This enhances understanding beyond the schema.
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 restores a previously created backup by backupId, reading metadata to determine the engine. It specifies supported types (mysql, postgresql, mongodb, files) and mentions hooks, distinguishing it from sibling tools like ssh_backup_create and ssh_backup_list.
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 explicitly states the tool is destructive and overwrites the target, with specific behaviors per engine (e.g., pg_restore --clean --if-exists). It does not explicitly say when not to use it versus alternatives like ssh_db_import, but the context of backup restore is clear.
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?
No annotations are provided, so the description carries the full burden. It states the tool affects only local in-memory connections, never remote state, and describes the effects of each action. This is transparent but could mention potential side effects like connection disruption or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and well-structured: purpose first, then action details. No redundant 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 no output schema, the description mentions that 'status' returns active connections with age and keepalive, but does not specify the output format. It also does not cover error scenarios. For a tool with two parameters and clear actions, it is mostly complete but could be slightly more detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value by explaining the action parameter's enum values in context and specifying when the server parameter is required vs ignored. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects and manages pooled SSH connections, distinguishing it from other SSH tools. It specifies the action parameter and the effects of each action, making the purpose unambiguous.
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 explains when to use each action (status is read-only, reconnect/disconnect modify connections) and notes that server is required for reconnect/disconnect. However, it does not explicitly compare with sibling tools like ssh_session_list, though the context of siblings is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: it explains the destructive actions per database type (PostgreSQL uses pg_restore --clean, MongoDB uses mongorestore --drop, MySQL pipes), and mentions automatic decompression of .gz inputs. No contradictions.
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 concise and front-loaded with the primary purpose and destructive nature. It then efficiently covers per-database behavior, supported types, and compression handling in just a few sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and no output schema, the description provides sufficient context about the tool's impact, expected behavior for each database type, and input file handling. It is complete enough for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining the semantic differences of the 'drop' parameter (MongoDB only, default true) and the type-specific behavior for each database system. This goes beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a dump file into a target database on a remote server, explicitly noting it is destructive. It distinguishes itself from siblings like ssh_db_dump and ssh_db_query by focusing on importing and restoring data.
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?
While the description explains the destructive nature and per-database behavior, it does not provide explicit guidance on when to use this tool versus alternatives like ssh_db_query or ssh_backup_restore. Usage context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses it's read-only, local, does not persist, does not expose command output, only commands and outcomes. Excellent 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 sentences, front-loaded with the core purpose. Every sentence adds value without redundancy. Concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains what is returned (timestamps, server, duration, success status) and covers all input parameters. It is complete for a read-only history tool.
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 coverage is 100%, so baseline 3. The description repeats the filter options and mentions default limit, but the schema already provides property descriptions. No additional semantics beyond schema.
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 it returns the in-memory log of SSH commands, specifies the resource (log), verb (returns), and adds details like timestamps, server, duration, success status. It distinguishes from siblings by emphasizing it's local and read-only, unlike execution or session tools.
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 explicitly says 'purely local and read-only: it opens no SSH connection' which implies when to use (view history) and when not (for remote execution). It provides context but does not explicitly list alternatives or exclusions.
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?
Explicitly states read-only nature and that it inspects in-memory state with no side effects. Describes filter behavior and exclusion of closed sessions. Could mention data freshness or error conditions, but sufficient for a list 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?
Three efficient sentences: purpose and attributes, read-only nature, parameter behavior and exclusion rule. No wasted words; critical information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional param and no output schema, the description covers all essential aspects: what is listed, how it behaves, and parameter specifics. Lists return fields explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description is present ('Filter by server name'), and the description adds 'case-insensitive substring filter on server name' and optional omission, enhancing clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists active SSH sessions with specific attributes (ID, server, state, etc.). Distinguishes itself from sibling tools like ssh_session_close or ssh_session_start by focusing on listing.
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?
Provides clear context: lists active sessions, optional case-insensitive server filter, omits closed sessions. Lacks explicit comparison to alternatives, but usage is well implied.
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?
With no annotations, the description carries full burden. It discloses that the operation only affects local tunnel state, is irreversible, and that the server option reports how many tunnels were closed. This is adequate behavioral 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 two sentences with no wasted words. It front-loads the main action and efficiently explains parameter usage and side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers behavior, parameter selection, side effects, and error condition (neither supplied). It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds extra value by explaining the behavioral difference between tunnelId and server (single close vs. batch close with count). This goes beyond the schema's concise descriptors.
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's purpose with a specific verb ('Tears down') and resource ('active SSH tunnels'). It distinguishes from sibling tools like ssh_tunnel_create and ssh_tunnel_list by specifying it is for closing tunnels.
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 provides explicit guidance on parameter usage: exactly one of tunnelId or server must be supplied, and explains the behavior of each. While it doesn't directly contrast with alternatives like ssh_session_close, the context of sibling tools makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explicitly states 'no remote execution or side effects', 'stored in local config', and 'Adding an existing alias overwrites it', disclosing key behavioral traits concisely.
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 four sentences long, front-loaded with the core purpose, and each sentence adds value. No redundant or extraneous 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 no annotations and no output schema, the description adequately covers the tool's behavior for its simplicity. It could mention return format or error handling, but the core functionality and constraints are clearly communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are minimal ('Action to perform', etc.), but the tool description adds significant context: it clarifies the relationship between action and required parameters, and specifies that for suggest, the command field serves as a search term. This enhances understanding beyond the schema.
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 it manages local shorthand aliases mapping short names to full command strings, stored locally with no remote execution. It distinguishes from siblings by specifying 'no remote execution or side effects' and 'local config', differentiating from other SSH tools that involve remote actions.
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 explains each action's behavior and parameter requirements: add needs both alias and command, remove needs alias, list shows all, suggest returns matches. It doesn't explicitly state when not to use this tool or provide alternatives, but the guidance is clear enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description thoroughly discloses behavioral traits: it is read-only, does not modify anything, it filters out common system databases, and it is safe to call repeatedly. It also clarifies return content (items and count). This fully compensates for the absence of annotations.
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 concise, consisting of three short sentences that front-load the core purpose. Every sentence adds essential information: purpose, conditional behavior, supported engines, return format, and safety note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately covers what it returns (items and count), the conditions affecting output, and its safe nature. It could mention potential errors or connection details, but the provided context is sufficient for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining the conditional behavior of the 'database' parameter (listing tables/collections vs databases) and noting that system databases are filtered. This goes beyond the schema's descriptions, which already cover the basic meaning.
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 lists database objects (databases or tables/collections) on a remote server without modification. It specifies conditional behavior based on the database parameter and explicitly names supported engines (mysql, postgresql, mongodb), distinguishing it from sibling tools like ssh_db_query or ssh_db_dump.
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 explains when to list databases vs tables/collections and emphasizes it is read-only and safe to repeat. However, it does not explicitly mention when not to use it or suggest alternative tools for other tasks, though the context provided implies its appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Comprehensively discloses mutation, destructiveness, password handling (piping to sudo -S, masking), timeout default (30000 ms), OS adaptation, and mode restrictions. No annotations exist, so description fully carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, no unnecessary words. Could be more structured (e.g., bullet points) but remains efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations, yet description is thorough: covers input, behavior, side effects, restrictions. Complete for a utility tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters with descriptions. Description adds value by clarifying cwd defaults, timeout default, and password masking behavior, going beyond schema.
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 runs commands with elevated privileges via sudo, returning exit code and output. It distinguishes itself from sibling tools like ssh_execute by specifying sudo usage.
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?
Describes when to use (elevated commands), readonly/restricted mode behavior, but does not explicitly contrast with alternatives like ssh_execute. Provides good context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it discloses mutation of the destination, destructive nature of delete true, dryRun preview, default compression, sshpass requirement, blocking on readonly/restricted servers, and Windows path conversion behavior. This far exceeds minimal disclosure.
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 dense paragraph of about 250 words that front-loads the core purpose and packs each sentence with essential operational details. While not terse, every sentence contributes unique value and no information is redundant. It is appropriately sized for a complex 10-parameter tool, though a bulleted structure could improve scannability.
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?
The description covers the key operational aspects: direction semantics, destructive behavior, dryRun, defaults, Windows support, auth requirement, and server restrictions. The only missing piece is the return/output format, which is not described and there is no output schema. However, for an action tool this is largely adequate, and all important edge cases are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical semantics beyond the schema: the requirement that one side be local and the other remote, the no-prefix default to push, the destructive meaning of delete, and Windows path conversion details for source/destination. This goes well beyond baseline.
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 opens with 'Synchronizes files or directories between local and remote using rsync over SSH on the named server,' which clearly states the action and scope. It distinguishes from sibling tools like ssh_upload/ssh_download by emphasizing bidirectional synchronization with prefix-based direction control. The purpose is unambiguous and specific.
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 explains the prefix rules for source and destination and the default push behavior, giving clear context for operation. However, it does not explicitly contrast with alternatives such as ssh_upload/ssh_download for one-way transfers, nor state when to prefer this tool. Thus, it meets 'clear context, no exclusions' but not explicit alternative guidance.
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?
No annotations provided, so description carries full burden. It discloses tunnel lifecycle (keeps running until closed), return value (tunnel ID), and default behavior (localHost). Could mention authentication or limits, but still informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, no extraneous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers return value, parameter semantics, defaults, and usage for all types. Complete for a tool with 6 parameters and moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond schema: explains type parameter options, which parameters are required for each type, defaults, and that remoteHost/remotePort are ignored for dynamic. Schema coverage is 100% but description enriches understanding.
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 'Opens a new SSH connection... starts a port-forwarding or SOCKS proxy tunnel', using specific verbs and resource. It distinguishes from siblings like ssh_tunnel_close and ssh_tunnel_list by focusing on creation.
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?
Describes parameter roles for each tunnel type (local, remote, dynamic), necessary parameters, and defaults. Lacks explicit when-to-use or when-not-to-use alternatives, but the context is clear for this creation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully carries burden. Discloses overwriting behavior, read-only remote operation, permission requirement, and single-file limitation. No contradictions.
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?
Three sentences with no wasted words: core action first, then critical details (overwrite, security mode, permissions, alternative tool).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, no output schema), description covers all necessary context: overwrite, permissions, security mode, single-file limitation, and sibling recommendation.
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 coverage is 100% with clear descriptions for each property. Description adds no new semantic details beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses strong verb 'Downloads' and clearly identifies the resource as 'one remote file' over SFTP. It distinguishes from sibling ssh_sync by specifying single-file scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (single file download) and when not to use (directories: use ssh_sync). Also notes behavior in readonly/restricted modes and permission requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mutates remote state, alias expansion, OS syntax adaptation, timeout behavior, mode restrictions, and output truncation. No annotations provided, so description fully bears the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds unique information. Front-loaded with core purpose, followed by essential behavioral details. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return values (stdout, stderr, exit code), conditions, and all parameter behaviors. Adequate despite no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters (100% coverage). Description adds value by explaining cwd fallback, timeout default/max, and alias expansion context beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Runs a shell command over SSH on a named configured server and returns stdout, stderr, and exit code.' This is a specific verb+resource. Distinguishes from siblings like ssh_execute_group and ssh_execute_sudo by focusing on basic execution.
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?
Provides context on readonly/restricted modes, timeout limits, and aliases. Does not explicitly name alternatives, but the behavior details help agents decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it mutates remote state, is not idempotent, handles per-server security independently, and explains the effect of stopOnError. It also details strategy behaviors, timeouts, and cwd defaults, providing a thorough safety and runtime profile.
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?
Each sentence conveys essential information without waste. The description flows from core action to membership, behavioral caveats, strategies, and defaults, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers the tool's purpose, behavior under failures, idempotency, execution strategies, and parameter defaults. It is sufficiently complete for an agent to decide when and how to invoke this tool, including handling edge cases like readonly servers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds extra value by explaining the cwd default (default_dir), the delay semantics for rolling strategy, and the fixed 30000 ms timeout (which is not a parameter but a runtime default). This goes beyond the schema.
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's function: running a command on every server in a group and returning a per-server report. It also distinguishes from the sibling ssh_execute by explicitly focusing on group-wide execution and clarifying how groups are formed (ssh_group_manage plus config).
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 clear context on when to use this tool (for group execution) and describes important behaviors like best-effort execution and stopOnError. It doesn't explicitly name alternative tools for single-server execution, but the group-specific language makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: read-only, local, opens no SSH connections, and deliberately omits secrets. This is exemplary transparency for a list 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?
The description is concise and well-structured, front-loading the purpose in the first sentence. Each subsequent sentence adds unique value: return fields, safety, secrets, parameters, and use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description is complete: it lists return fields, describes read-only behavior, clarifies no secrets, states no parameters, and gives a concrete usage scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is empty and the description explicitly states 'Takes no parameters,' leaving no ambiguity. Since there are zero parameters, no further semantics are required, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists all SSH servers defined in the loaded configuration' with specific verb and resource, and enumerates the return fields. It distinguishes itself from sibling tools by being the server list, not sessions or tunnels.
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?
It provides explicit usage context: 'Useful as a first call to discover which server names other tools accept.' It also notes read-only and local behavior, but does not explicitly name alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: terminates the session, writes exit, discards history/context, makes session ID unusable, destructive to session state, not to remote files, 'all' effect, and that the underlying connection is preserved. This is comprehensive.
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 paragraph that front-loads the main action and provides essential details without redundancy. Every sentence adds value, making it concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description completely covers functionality, side effects, special values, and what it does not do. An agent has all necessary information to decide and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'session' has a schema description indicating ID or 'all'. The description adds that the session ID becomes unusable and explains the 'all' behavior, which goes beyond the schema. Since schema coverage is 100%, baseline is 3, and the added context justifies a 4.
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 'Terminates an open SSH session' with the resource being the session ID. It distinguishes from sibling tools like ssh_session_start and ssh_session_list by specifying termination. The special value 'all' is also noted.
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 provides context on when to use: to close a session, with behaviors like writing exit, discarding history, and not deleting files. It notes that 'all' closes all sessions ignoring errors. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it is read-only and does not create, modify, or close anything. It also details what information is shown (tunnel ID, server, type, etc.), ensuring the agent understands the tool's scope.
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 only two sentences, with the first sentence front-loading the purpose and output fields, and the second sentence explaining parameter usage. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is fully complete. It covers what the tool does, what it returns, and how to use the parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the server parameter as 'Filter by server name'. The description adds that omitting the parameter returns all tunnels across all servers, which goes beyond the schema and clarifies the default behavior.
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 lists active SSH tunnels with specific details (ID, server, type, etc.) and explicitly notes it is read-only, distinguishing it from sibling tools like ssh_tunnel_create and ssh_tunnel_close.
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 explains when to use the tool (to list active tunnels) and provides guidance on the optional server parameter, including that omitting it lists all tunnels. It states what the tool does not do (create, modify, close), though it does not explicitly mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses mutation of remote state, backup default, ability to disable backup, setting owner/permissions, sudo password, service restart, and hook execution. The blocking condition on readonly/restricted servers adds transparency.
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?
Single paragraph covers key points efficiently. Could be slightly more structured (e.g., bullet points), but it's concise and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity, no output schema, and full parameter coverage, the description covers nearly all aspects: process, backup, permissions, sudo, restart, hooks, and blocking conditions. It is complete for an agent to decide and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions. The description adds context (e.g., temporary upload, default backup, detection of defaults) beyond schema, enhancing parameter understanding.
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 deploys local files to remote paths using a two-step process (upload to temp then move). This differs from siblings like ssh_upload (simple upload) and ssh_sync (syncing), providing distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: for deploying files with backup, permissions, sudo, hooks, and service restart. Also states it's blocked on readonly/restricted servers, guiding when not to use. No alternative tool named, but the detail implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It comprehensively discloses read-only nature, no sudo requirement, the specific commands run, and the behavior of interval/duration parameters (accepted but only single snapshot). The platform limitation is also noted.
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 three well-structured sentences, front-loaded with the main purpose. Every sentence adds necessary information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters and no output schema, the description adequately covers all relevant behavior: what it does, what commands run, parameter effects, and platform limitation. It is complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds extra value: it explains that 'type' defaults to 'overview', and that 'interval' and 'duration' are for continuous monitoring intent but only a single snapshot is gathered. This clarifies behavior beyond the schema.
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 read-only snapshot of system resources on a named Linux server using specific commands. It distinguishes from siblings by being a monitoring tool, not for command execution or other tasks. The verb 'Collects' and resource 'system resources' are specific, and the scope is well-defined.
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 explains when to use (for read-only monitoring) and notes platform limitation (Linux only). However, it does not explicitly mention when not to use or compare with sibling tools like ssh_execute or ssh_service_status. The guidance is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses behavioral traits: mutation, non-idempotent, no backup, no sudo, blocked in certain modes. This gives the agent a clear understanding of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each adding essential information. Front-loaded with the core action. No redundant phrases.
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?
Covers key aspects: action, mutability, idempotency, preconditions, security mode restrictions, alternative tool. No output schema, but typical for upload tool. Could mention success/failure feedback, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. The description adds value beyond schema by specifying that the remote path must be writable by the configured SSH user (no sudo). This is non-obvious from schema 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?
Description clearly states it uploads a single local file to a remote path via SFTP, overwriting any existing file. It distinguishes itself from the sibling tool ssh_sync for directory trees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (single file upload) and when-not-to (use ssh_sync for directories). Also notes blocking conditions (readonly/restricted mode) and prerequisites (local file must exist, remote path writable).
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:

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

Score Badge

Copy to your README.md:

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

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/bvisible/mcp-ssh-manager'

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