NikolaNddTesla/ssh-mcp-server

Server Quality Checklist

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

Latest release: v2.2.3
Disambiguation5/5
Each tool targets a distinct operation: file transfer, server configuration, proxy management, connection handling, or command execution. Even similar tools like connect and quick_connect have clear differences (persistent vs temporary). No two tools appear to do the same thing.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern (upload_directory, add_server, list_proxies), but a few single-word verbs like connect, disconnect, and execute break the pattern slightly. The inconsistency is minor and does not cause confusion.
Tool Count3/5
With 21 tools, the server spans multiple sub-domains (file transfer, server CRUD, proxy management, connection lifecycle), making the count feel heavy but not excessive. It is on the borderline for a typical MCP server scope.
Completeness4/5
The tool surface covers server CRUD, proxy management, file transfer (upload/download, file/directory), file read/write, and command execution. Notable gaps include remote file deletion and remote directory listing, which agents might need but can work around.
Average 3.5/5 across 21 of 21 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the operation is destructive, whether the old ID becomes invalid immediately, or how it affects existing connections or resources. This leaves the agent without essential side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise but under-specified. It is not overlong, but it omits important usage and behavioral details, making it minimally informative for a tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema and no annotations, the description is incomplete. It fails to explain consequences, prerequisites, or how this operation differs from related server management tools, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for both parameters ('New server ID' and 'Current server ID') with 100% coverage. The description adds no additional semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Rename server ID (alias)', which clearly identifies the action (rename) and the resource (server ID). It does not explicitly distinguish from the sibling tool update_server, which could also modify server attributes, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_server or add_server. It only states the operation without mentioning when it is appropriate or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It fails to disclose key behaviors: whether it overwrites existing proxies, how the add/update decision is made, auth requirements, or return values. The text is essentially a restatement of the tool name without any side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words or redundant information. It is maximally concise and front-loaded, conveying the essential action and resource without any wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the return value, error conditions, idempotency, or any operational context needed for safe invocation. The tool's complexity demands far more than a one-sentence summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 7 parameters, so the schema already documents parameter meaning. The description adds no extra semantic insight, particularly regarding how proxy_id distinguishes add vs. update, but the schema's coverage warrants a baseline score of 3.
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 'Add or update SOCKS proxy preset' uses a clear verb and resource, explicitly covering both creation and modification. It distinguishes itself from siblings like delete_proxy and list_proxies by naming the specific operation on the proxy resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use add_proxy vs. updating an existing proxy, nor any differentiation from other proxy or server tools. The description doesn't mention prerequisites like having an existing server or proxy ID, or scenarios where this tool is preferred over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Add or update server configuration', implying an upsert behavior, but does not explain permission requirements, how existing configurations are handled, or the nature of write operations. This is minimal and insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it front-loaded and easy to parse. However, it is so brief that it sacrifices important contextual information, so while concise, it is not ideal in structure for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no annotations, no output schema, and the presence of several related sibling tools, the description is inadequate. It does not explain return values, error conditions, or operational context, leaving significant gaps for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline of 3 applies. The description itself adds no parameter-specific meaning beyond the schema, which already documents all parameter purposes. The description's mention of 'server configuration' is generic and does not enhance understanding of individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add or update) and resource (server configuration), making the tool's core function apparent. However, it does not differentiate from the sibling tool 'update_server', which likely handles updates only, so the overlap between add and update is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like 'update_server'. It does not mention prerequisites, context, or specific use cases, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description merely restates the operation without disclosing any behavioral traits. It does not indicate whether deletion is reversible, if it impacts active sessions, or if any confirmation is required. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, using just three words. It avoids verbosity, though it is somewhat fragmentary. For a simple tool, this is appropriately sized but lacks structural completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description carries the full burden of context. It does not explain outcomes, error scenarios, or effects on existing connections, leaving an agent with insufficient information for a mutating/destructive 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?
The schema covers 100% of the single parameter (proxy_id) with a basic description 'Proxy ID'. The tool description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('proxy preset'). It distinguishes from sibling tools like delete_server by specifying the proxy resource, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like add_proxy or list_proxies. There are no exclusions, prerequisites, or contextual hints, leaving the agent without information to decide between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral disclosure beyond the tool name. It does not mention irreversibility, permissions, or consequences of deletion, and with no annotations, the description carries the full burden but fails to provide this critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, very concise and to the point. However, it essentially repeats the tool name and adds minimal information, making it slightly under-specified rather than appropriately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, this description is incomplete. It does not clarify what 'server configuration' entails, whether deletion is permanent, or any side effects, leaving important context missing for such a simple 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 for the single parameter server_id is 100%, described as 'Server ID'. The description adds no information about parameters, but the schema already covers it, 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?
The description 'Delete server configuration' uses a specific verb (delete) and resource (server configuration), clearly distinguishing it from sibling tools like update_server or get_server. It leaves no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to prefer delete_server over update_server or disconnect. Lacks any context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Disconnect from server' without explaining side effects, whether the server is removed (unlikely, as delete_server exists), idempotency, or error behavior. The parameter description mentions the 'disconnect all' behavior, but that is in the schema, not the main description, and no broader transparency is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It clearly states the core action in minimal words, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity of the tool (one optional parameter, no output schema), the description is too sparse. It lacks usage context, safety/behavioral details, and differentiation from related tools. For a tool that can disconnect all servers, such potential impact warrants more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (server_id), which already explains the meaning and the 'leave empty to disconnect all' behavior. The tool description adds no additional parameter context, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disconnect from server' clearly states the action (disconnect) and the resource (server), which distinguishes it from siblings like connect and quick_connect. However, it does not mention the ability to disconnect all servers or a specific server, which is a scope detail only revealed in the parameter description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about the connection lifecycle. It is implied by the name that this is the inverse of connect, but the description itself offers no explicit usage instruction or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It fails to mention potential side effects (e.g., destructive commands), security implications, output format, exit codes, or error handling, making it completely opaque for a potentially dangerous tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is arguably too terse. It earns its place by stating the core purpose, though it omits important operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and risk, the description is incomplete. It lacks output schema, annotations, usage context, and any explanation of return values or side effects, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 3 parameters with descriptions, so the baseline is 3. The description itself adds no parameter-specific meaning beyond what the schema already 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's action ('execute a shell command') and the target resource ('remote server'), distinguishing it from sibling tools that handle file transfers, server management, or connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or preferred scenarios. The user must infer that this is for arbitrary command execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for disclosing behavior. It only states the action ('connect') and a usage hint, but does not mention prerequisites (e.g., authentication), side effects, whether the connection persists, or how errors are surfaced. This is minimal transparency for a connection 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 sentence that conveys the essential action and a critical usage caveat. It is front-loaded and contains zero fluff, making it easy to parse while still being informative enough for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description is minimal but understandable. It communicates the primary use case and even notes that it's rarely needed. However, it lacks behavioral details (e.g., what happens on success/failure, whether connection state is tracked), so it is not fully complete for a robust agent decision-making process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the only parameter `server_id` has a description 'Server ID'. The tool description adds no additional semantic information about the parameter, such as expected format or relationship to server list. Since schema coverage is high, the baseline of 3 is appropriate, but no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Manually connect to server'. It uses a specific verb ('connect') and resource ('server'), and adds the contextual note that it's 'usually not needed' and that tools auto-connect, which distinguishes it as a manual override. However, it doesn't differentiate from the sibling tool 'quick_connect' specifically, so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it ('usually not needed', i.e., as a fallback when auto-connect doesn't apply) but does not explicitly state alternative tools or exclude auto-connect scenarios. No named alternatives like 'quick_connect' are provided, so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds only the async hint and does not disclose behavior such as blocking, file overwrite rules, or error handling. The return value is only implied through the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is front-loaded with the action and includes a meaningful tip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage and no output schema, the description is minimally adequate. It lacks context on expected return values or when to consider alternative tools, but for a simple download operation, the schema fills most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter semantics beyond what the schema already explains—the async hint is already present in the schema's async_transfer 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 and resource: 'Download file from remote server.' This distinguishes it from siblings like upload_file, download_directory, and read_file, even though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'use async mode for large files,' which is a parameter-specific tip rather than guidance on when to choose this tool over alternatives. It does not mention when to use download_file versus download_directory or upload_file, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'View server configuration details' without explicitly stating that the operation is read-only, what response format to expect, or any error/permission conditions. The verb 'view' implies non-mutating behavior, but this is not elaborated beyond the tool's basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence: 'View server configuration details'. It contains no filler, repetition, or unnecessary details, and directly conveys the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), but the description is minimal. It conveys the purpose but does not specify what the returned configuration details include, how to handle missing servers, or any preconditions. Given the lack of annotations and output schema, the description is adequate but leaves gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a 100% description coverage for the single parameter 'server_id' with 'Server ID'. The description adds no additional meaning about the parameter's format, source, or constraints. Since schema coverage is high, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('View') and the resource ('server configuration details'), distinguishing it from sibling tools like list_servers (which lists all servers) and add_server/update_server/delete_server (which modify servers). The required 'server_id' parameter confirms it targets a single server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it is for retrieving details of a specific server, nor does it name alternatives or exclusions. The only hint comes from the parameter name, which is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of disclosing behavior. It only states the purpose and gives a usage hint, but does not disclose what happens if the task is not found, whether the operation is read-only, or what the response contains. This is a significant gap for a status-checking 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 one short sentence that immediately conveys the tool's purpose and usage context. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one optional parameter and no output schema—the description provides the essential purpose and a key usage constraint. However, it does not explain the return value or any error handling, which could be important for an agent to interpret the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'task_id' with 100% coverage, including the example 'tf_1' and the special behavior of leaving it empty. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check background transfer task progress' clearly states the tool's function with a specific verb and resource. It distinguishes itself from sibling transfer tools by focusing on status checking rather than performing transfers.
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 phrase 'use with async_transfer=true' provides clear context for when to use this tool—specifically for asynchronous transfers. It doesn't explicitly exclude synchronous transfers or mention alternative tools, but the context is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the overwrite behavior, which is a critical destructive trait. However, it omits other important behaviors such as whether the file is created if it does not exist, what permissions are required, or what happens on failure. This is partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and directly states the core purpose. Every word earns its place, no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 3 required parameters, all clearly described in the schema. The description covers the essential purpose and the overwrite behavior. Given no output schema, it could mention return values, but for a simple write operation, the current description is mostly complete. The only gap is the lack of clarification on file creation behavior.
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 each parameter has a clear description. The tool description adds no extra semantic detail beyond the schema, but the baseline is 3 when the schema handles the heavy lifting. No compensation needed.
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 'Write content to remote file (overwrite)' clearly identifies the verb (write), resource (remote file), and key behavioral trait (overwrite). It effectively distinguishes from siblings like read_file and upload_file by specifying the action of writing raw content directly to a remote path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to write text content to a remote file, but it does not explicitly contrast with alternatives or state when not to use it. For example, it does not mention that upload_file may be more appropriate for uploading whole files. This is implied usage rather than explicit guidance.
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 present, so the description carries the full burden. It reveals the compress/transfer/extract pipeline and suggests async for large directories, but lacks details on overwrite behavior, error handling, or return values. Some transparency is provided, but important behavioral traits remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action and key behavioral notes. No wasted words; the parenthetical clarifies the process and usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, the description provides the core purpose and an async hint, but does not mention how to monitor async transfers (e.g., using sibling transfer_status) or what the tool returns. It is adequate but leaves gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions (e.g., MD5 dedup for skip_same). The description adds a hint about async for large dirs but does not add meaning beyond the schema, so the 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?
The description clearly states the tool uploads a local directory to a remote server, distinguishing it from sibling tools like upload_file. It also adds specific details (auto compress, transfer, extract) that make the tool's purpose precise.
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 usage context by mentioning 'Use async for large dirs', which guides when to enable a parameter. It does not explicitly name alternative tools, but the resource type (directory vs file) and name make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'zero token cost' and 'path-based', but does not disclose overwrite behavior, permission requirements, return values, or error handling. This is a significant gap for a mutation 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 sentence, front-loaded with the core action and followed by two concise, relevant tips. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema thoroughly documents parameters, but with no output schema or annotations, the description should state what a successful upload returns (e.g., success flag or task ID) and what failure modes exist. The description leaves these unaddressed, making it adequate but not fully 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 the baseline is 3. The description adds practical value by recommending async mode for large files, which is not tautological and helps the agent choose the right parameter setting. Other parameters are already well-documented in 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 uses a specific verb and resource: 'Upload local file to remote server'. It clearly distinguishes from sibling upload_directory by specifying 'file' and adding 'path-based', making the scope 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 gives a clear conditional tip, 'Use async mode for large files', which guides parameter selection. However, it does not explicitly state when to prefer this over alternatives like upload_directory or write_file, though the name implies the distinction.
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 provided, the description carries the burden of disclosure. It reveals the temporary nature, that the connection is not saved, and that it returns a server_id for later use, which is useful. However, it does not detail the connection lifecycle (e.g., when it closes), error behavior, or authentication requirements beyond what the schema already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the core purpose, clearly states the return value, and contains no filler or redundant content. Every token earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description adequately covers the key aspects: what it does, its temporary nature, and the return value. It could be more explicit about connection lifecycle or how server_id is used by other tools, but the current text is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds no additional parameter-level meaning (e.g., clarifying password vs private_key usage), so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Temporary server connection') and resource, with a distinct scope ('not saved') that differentiates it from sibling tools like connect or add_server. It also specifies the output (host:port as server_id), making the tool's 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 implies usage for temporary, non-persistent connections needed for subsequent operations, which provides clear context. However, it does not explicitly name alternatives or state when not to use this tool (e.g., when a saved connection is required), so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'does not affect existing connections' is a valuable behavioral disclosure, especially since no annotations are provided. Yet it omits details on return values, failure modes, or timeout behavior, leaving the description to carry the full transparency burden but only partially fulfilling it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is perfectly front-loaded with the core purpose. Every word earns its place, and it avoids unnecessary detail.
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 one-parameter tool with no output schema, the description adequately covers the tool's purpose and safety profile. It lacks explicit return/error semantics, but the simplicity of the tool makes the description reasonably complete for an agent to invoke it correctly.
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 server_id already described as 'Server ID' in the input schema. The description adds no additional parameter meaning, so it does not go beyond what the schema already 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 'Test server connectivity' with a specific verb+resource structure. The parenthetical 'does not affect existing connections' effectively distinguishes it from sibling tools like connect and disconnect, emphasizing its non-invasive nature.
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 implies this tool is for safe connectivity checks without side effects, which is useful context. However, it doesn't explicitly state when to use it over alternatives like connect or quick_connect, nor does it provide exclusion criteria.
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 provided, the description carries the full burden for disclosing behavior. It does disclose a key behavioral trait: only fields passed are changed, others remain unchanged. However, it does not mention potential side effects, validation, or error cases, leaving some behavioral gaps.
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, efficiently worded sentence that immediately states the purpose and then clarifies the update semantics. Every word contributes value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (13 parameters, no output schema, no annotations), the description covers the essential purpose and partial-update behavior. The schema handles parameter details, so the description is sufficiently complete for the agent to select and invoke the tool correctly, though it could mention the expected response or server existence requirement.
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?
Although the schema covers all 13 parameters with 100% description coverage, the description's "only pass fields to change, rest unchanged" adds important context about how omitted parameters are treated. This goes beyond the schema's optional flags by explicitly stating that omitted fields retain their current values, 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 uses a specific verb ("Update") and resource ("server configuration"), clearly distinguishing it from sibling tools like add_server, delete_server, and rename_server. The additional clause about partial updates further clarifies the specific behavior, 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 implies usage for modifying existing server settings, but it does not explicitly state when to use this tool versus alternatives such as rename_server for name-only changes. It also lacks any exclusion or prerequisite guidance, relying on the agent to infer from sibling names.
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 the transparency burden. It discloses the internal process (compress, download, extract) and advises async for large directories, which goes beyond the schema. It doesn't discuss failure behavior or cleanup, but for a download tool this is reasonable.
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 long, front-loaded with the purpose, and every word adds value. The parenthetical pipeline and async hint are 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 4-parameter tool with a full input schema, the description explains the operation pipeline and provides a performance tip. No output schema exists, but return values are not critical for a download operation. The description is adequately complete for choosing and invoking the 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% with all parameters described. The description adds minimal extra parameter context, only reinforcing the async_transfer hint already present in the schema. Given the full schema coverage, the 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 'Download remote directory' with a specific verb and resource, and the pipeline (remote compress → download → local extract) further clarifies the operation. It is distinct from sibling tools like download_file (file vs directory) and upload_directory (download vs upload).
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 that this tool is for downloading directories and provides an explicit usage hint: 'Use async for large dirs'. It doesn't explicitly name alternatives, but the tool name and description make when-to-use clear enough.
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 the full burden of behavioral disclosure. It explicitly mentions 'supports line range', which is a meaningful behavioral trait beyond the tool's name. The term 'read' inherently implies non-destructive behavior, and the suitability note suggests a focus on text files. It does not cover error handling or binary files, but the core behavior is adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear verb and resource, followed by a parenthetical that adds key capability and use case. It is extremely concise with zero 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?
The tool is simple with four parameters and no output schema. The description conveys the primary return value (file content) and provides usage context. It does not detail edge cases or response format, but given the low complexity and schema completeness, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for all parameters, with clear descriptions for limit, offset, server_id, and remote_path. The description's mention of 'line range' adds little beyond the schema's 'Number of lines to read' and 'Start line'. The baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Read remote file content'. It further distinguishes the tool by noting 'supports line range', which sets it apart from sibling tools like download_file or write_file. The mention of 'suitable for logs and config files' adds context for when this read operation is appropriate.
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 usage context by stating the tool is 'suitable for logs and config files', indicating a text-reading use case. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for an agent to distinguish from download_file or write_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not explicitly mention return format, potential errors, or why this is safe. It adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that says exactly what the tool does with no wasted words. It is appropriately concise for such a simple 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 (zero parameters, no output schema), the description is complete enough. It tells the user exactly what to expect: a listing of all configured SOCKS proxies. No additional context is needed.
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 tool has zero parameters, so the description does not need to explain parameter details. The phrase 'all configured SOCKS proxies' adds scope clarity beyond the empty schema, matching the baseline for parameterless tools.
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 the specific verb 'List' with the resource 'all configured SOCKS proxies', making the tool's purpose unmistakable and distinguishing it from sibling tools like list_servers, add_proxy, and delete_proxy.
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 clearly implies this tool is for viewing configured proxies, which is distinct from adding or deleting proxies. It provides clear context for when to use it, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'List' implies a read-only operation, and the mention of 'active connections' adds behavioral context about the output scope. However, it doesn't explicitly state side-effect freedom or whether it reflects real-time connection state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the operation and target, with no filler 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 tool with zero parameters and no output schema, this description is fully sufficient to understand what the tool does. It covers the core functionality and distinguishes the 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?
The tool has zero parameters and 100% schema coverage (empty schema), so there's nothing for the description to add. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource: 'configured servers and active connections.' This distinguishes it from sibling tools like get_server (single server) and list_proxies (proxies).
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 clearly states what the tool does but doesn't explicitly mention when to choose it over alternatives like get_server or list_proxies. Given the context, it's clear this is for enumerating all servers, so the usage context is implied rather than exclusionary.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NikolaNddTesla/ssh-mcp-server'

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