ssh-chat-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose: connection management, file transfers, command execution (sync, async, sudo), and diagnostics. Even the exec family differentiates immediate vs async and different user contexts without ambiguity.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern (e.g., download_file, exec_status) or single verb (connect, exec). The exec_ family uses a uniform prefix. All names are lowercase with underscores, making them predictable.
Tool Count5/5
With 17 tools, the server is well-scoped for SSH operations. It covers all essential actions without unnecessary duplication or bloat. Each tool earns its place in the set.
Completeness5/5
The tool surface is comprehensive: connection lifecycle, command execution (synchronous, asynchronous, sudo, with status/cancel), file transfer (single, directory, read, write), and diagnostics. Gaps are minimal and easily addressed via exec.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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 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.
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?
With no annotations, the description must fully disclose behavior. It only notes that paths come from arguments and are not hardcoded. Missing critical details: whether existing files are overwritten, what happens on failure, permission handling, or if the tool is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two front-loaded sentences. Every word adds value, but there is room to include more behavioral details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and sibling tools, the description lacks completeness. It does not explain the return value (e.g., success/failure), prerequisites (e.g., need for a connection), or effects like overwriting. The tool is a mutation, yet behavioral context is minimal.
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 high (80%), so baseline is 3. The description adds minimal value beyond the schema, only reinforcing that paths are from arguments. It does not clarify the purpose of 'mode' or 'mkdirParents' beyond the schema, nor does it describe the undocumented 'connectionName' parameter.
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 ('Upload') and resource ('single local file'), specifying the method (SFTP). It implicitly distinguishes from sibling 'upload_directory' by mentioning 'single local file', but does not explicitly contrast with other related tools like 'write_remote_file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an active connection), when not to use it (e.g., for directories), or refer to sibling tools like 'upload_directory' or 'write_remote_file'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions dropping buffered stdout/stderr, which is a behavioral trait, but does not state whether the job record is fully removed, if this is irreversible, or any authorization needs. Major gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with key information. However, it could be more explicit (e.g., 'Remove the job record' instead of 'Forget'). Minimal waste.
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?
The description lacks critical constraints: it does not specify that the job must be in a terminal state (completed/cancelled/failed) and not running. It also does not clarify what happens to the job record in the system. Given no output schema, more context is needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes jobId as a required string with no description (0% coverage). The description adds no further meaning about the parameter beyond the tool's context, so it provides no added value for understanding the parameter.
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 removes or forgets a completed/cancelled/failed job and discards its buffered output. It uses specific verbs and resource, differentiating it from siblings like exec_cancel (which cancels running jobs) and exec_status (which retrieves status).
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 after a job is completed, cancelled, or failed, but does not explicitly say when not to use (e.g., on running jobs) or mention alternative tools. Guidance is adequate but not explicit.
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. It discloses that output is metadata-only and does not include logs, offering some behavioral insight. However, it omits details about permissions, side effects, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, each serving a clear purpose: stating the action and clarifying output. No extraneous information, perfectly front-loaded.
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 single optional parameter and no output schema, the description provides the core function but lacks completeness regarding parameter semantics and use cases. It is minimally adequate but leaves gaps for an agent to make fully informed decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'connectionName' with no description, and the tool description does not explain its purpose or usage. Schema coverage is 0%, and the description fails to compensate, leaving the parameter ambiguous.
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 'List' and the object 'known exec jobs and their statuses'. It also specifies the output nature ('metadata only, without logs'), distinguishing it from sibling tools like exec_status that show a single job status.
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 does not provide any explicit guidance on when to use this tool versus alternatives like exec_status or exec. It neither states prerequisites nor exclusions, leaving the agent to infer usage solely from the tool name and title.
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 provided, so description carries full burden. Mentions UTF-8 text payload but lacks details on overwrite behavior, permission handling, error cases, and mode parameter. Incomplete for a write tool.
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?
Short and front-loaded, but lacks essential information. One sentence plus a hint. Could be more structured by listing key parameters or constraints.
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?
Five parameters, no output schema, no annotations. Description is too brief to guide correct invocation. Missing required parameter details, return value, and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds no meaning to any parameter (mode, remotePath, content, mkdirParents, connectionName). The word 'payload' loosely relates to content but no explicit explanations.
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 action (write), resource (remote file), protocol (SFTP), and provides a specific use case (staging config files). Distinguishes from siblings like read_remote_file and upload_file.
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?
Suggests when to use (staging config files for later movement by exec) and implies an alternative workflow (exec for moving). Does not explicitly state when not to use or compare to upload_file, but provides useful context.
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 provided, so description carries full burden. Discloses that response excludes file content and includes byte count, but does not explain overwrite behavior, permission requirements, or error handling. Adequate but with 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?
Two concise sentences with key information front-loaded. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, many siblings, and no annotations, description lacks parameter guidance, usage context, and comparisons to alternatives. Leaves significant gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and description provides no parameter explanations. Parameter names are self-explanatory (localPath, remotePath, connectionName, mkdirParents), but description adds no value beyond naming. Baseline for low coverage is description must compensate; it does not.
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 the action (download), resource (remote file), method (SFTP), and a key behavioral detail (response contains only byte count, not content). Distinguishes from siblings like read_remote_file.
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 when not to use (when file content is needed) but does not explicitly state when to use vs. alternatives like upload_file or read_remote_file. No guidance on preconditions.
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?
Discloses best-effort cancellation, signal sending, and SSH channel closure. Without annotations, this adds behavioral context, but does not mention potential side effects or failure scenarios.
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 a single sentence, front-loaded with core action, and no unnecessary words. Every part is valuable.
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?
Adequate for a simple cancellation tool, but lacks information about return values or success indicators, especially since no output schema is provided.
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 50% (signal param has description). Tool description adds no parameter info beyond schema, so it meets baseline but does not compensate for the half of parameters without 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 it cancels a long-running command job and explains the mechanism (sends signal to remote process group, closes SSH channel). This distinguishes it from sibling tools like exec_start or exec_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like exec_remove. Usage context is implied but not stated, leaving ambiguity for the AI agent.
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?
Discloses redaction of secrets and byte limit, but lacks details on error handling, permissions, symlink behavior, or encoding fallback. With no annotations, more transparency is 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?
Two sentences, no fluff, directly conveys core functionality and key behavioral note.
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?
No output schema, missing return structure and behavior for binary files or non-UTF-8 encoding. Adequate for simple reads but incomplete for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%; description only reinforces maxBytes. Parameters remotePath and connectionName lack both schema and description elaboration, leaving agents guessing.
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 the tool reads a remote file as UTF-8 text with a byte limit and redaction, distinguishing it from siblings like write_remote_file and download_file.
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 vs alternatives like download_file or exec. The purpose is clear from sibling names, but no when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency. It discloses two key behaviors: excludes are not hardcoded, and symlinks are not followed by default. However, it omits other important behaviors like overwrite policy, error handling, or the need for a prior connection, which leaves 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 extremely concise, consisting of two short sentences. It front-loads the main action and includes critical details without any fluff, making it efficient for an agent to parse.
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 6 parameters and no output schema, the description provides the most essential context (recursive upload, excludes, symlinks) but misses details like the role of connectionName, whether mkdirParents is automatic, and what happens on error. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 17% (only 'exclude' has a description). The description adds semantic value for 'exclude' and 'followSymlinks', but the remaining 4 parameters (localPath, remotePath, connectionName, mkdirParents) receive no additional explanation beyond their names, which is insufficient given the low coverage.
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: recursively upload a local directory tree via SFTP. It specifies the resource (local directory tree) and method (SFTP), distinguishing it from sibling tools like upload_file that handle single files.
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 implicit guidance by noting that excludes are caller-supplied and symlinks are not followed unless requested. However, it does not explicitly state when to use this tool versus alternatives like upload_file, nor does it mention prerequisites such as needing an active connection.
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 full transparency burden. It explicitly warns that 'destructive operations are NOT blocked by this server', clearly disclosing the risk. However, it does not mention return values, error behavior, or success/failure indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that directly state the purpose and a critical warning. No superfluous words, front-loaded with the core action.
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 5 parameters, no output schema, and no annotations, the description should provide more context about what the tool returns, error handling, or when to use specific parameters (e.g., cwd, stdin). The existing warning is important but insufficient for full usability.
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 80%, so most parameters are already explained in the schema. The description adds minimal additional meaning beyond the schema details (e.g., no new context for parameters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a shell command over SSH on the named connection', specifying the action, protocol, and target. It directly matches the tool name 'exec' and its title, and is distinguishable from siblings like 'exec_as' or 'exec_start' which have different scopes.
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 includes a strong warning about destructive operations and the responsibility of the MCP client, but does not provide explicit guidance on when to use this tool versus its siblings (e.g., exec_as for a different user, exec_start for background).
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 full burden. It effectively discloses the incremental reading behavior and that it returns slices of output. It implies a read-only operation (status and output) without side effects, which is sufficient transparency for a non-destructive 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?
Two succinct sentences, front-loading the core purpose. Every word adds value, no repetition or filler. The structure is ideal for quick comprehension.
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 no output schema, the description should at least mention that nextOffset fields are included in the response to enable the incremental pattern. It says 'Return job status plus stdout/stderr slices' but omits the critical nextOffset fields. It is sufficient for basic use but lacks full completeness for a robust polling pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains the role of stdoutOffset and stderrOffset (from previous response's nextOffset fields), but does not explain maxBytes, which has a maximum of 5 MB. jobId is obvious from context, but the lack of explanation for maxBytes leaves ambiguity.
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 returns job status and stdout/stderr slices, distinguishing it from sibling tools like exec_start (starts jobs) and exec_cancel (cancels jobs). The verb 'Return' and the specific resource 'job status plus stdout/stderr slices' make 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 specific guidance on using stdoutOffset and stderrOffset for incremental reading, which is valuable. However, it does not explicitly state when to use this tool versus alternatives like exec (which might wait for completion) or exec_jobs (which lists jobs). It implies usage after starting a job but lacks explicit when-not instructions.
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 responsibility for behavioral disclosure. It explicitly mentions wiping credentials from memory, which is a critical security side effect. However, it does not detail other potential behaviors (e.g., error states for non-existent connections).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It conveys the primary action and an important side effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the main purpose and a key side effect. It could mention error handling (e.g., if connection doesn't exist) but is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds no meaning beyond the parameter name 'connectionName' already in the schema. The description fails to clarify what values are valid or provide context for the parameter.
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: close a named SSH connection and wipe credentials. This distinguishes it from sibling tools like 'connect' (opens a connection) and 'list_connections' (lists connections).
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 after a connection is established but does not explicitly state when to use this tool vs alternatives, nor does it provide contextual guidance such as prerequisites 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It discloses that sudoPassword is piped to stdin and never logged/returned, runAs is strictly validated, and the action is privileged. The exact shell command is shown, providing clear insight into execution behavior. A minor gap is the lack of detail on 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 concise sentences, each serving a clear purpose: stating the action, detailing a key behavioral trait, and issuing a warning. No unnecessary words or redundancy.
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 5 parameters, no output schema, and no annotations, the description covers the essential security and execution details but omits return value format, timeout behavior, error scenarios, and prerequisites. It is adequate but not fully comprehensive.
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 60% (descriptions for runAs, command, sudoPassword). The description repeats the schema notes for runAs and sudoPassword but adds no new information. It does not address connectionName or timeoutMs. The added value is marginal, so baseline 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 'Run a command as another Linux user', specifying a concrete verb and resource. It details the non-interactive nature and the sudo mechanism, which distinguishes it from sibling tools like 'exec' (likely runs as current user) and 'exec_as_start' (probably asynchronous). The warning about privileged actions further clarifies its purpose.
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 use for running commands as a different user with sudo, but does not explicitly guide when to use this tool versus alternatives like 'exec' or 'exec_as_start'. It lacks prerequisites (e.g., sudoers configuration) and does not mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description reveals key behaviors: returns immediately with jobId, runs over SSH, buffer limits. But it omits error handling, connection failure, and resource cleanup details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives usage context and examples. 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?
Given no output schema, description mentions return of jobId and references related tools. It covers main use cases but lacks details on error states and output format.
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 covers 83% of parameters with descriptions; description adds no extra parameter-level meaning beyond what schema provides. Baseline score 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?
Title and description clearly state that exec_start starts a long-running shell command over SSH and returns immediately with a jobId. It distinguishes from sibling tools like exec by emphasizing avoidance of MCP client timeouts.
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 says when to use: for long operations like git clone, pip install, etc. It directs to exec_status and exec_cancel for follow-up. However, it does not explicitly state when not to use or contrast with exec.
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?
Without annotations, the description covers key behaviors: asynchronous execution (returns jobId), sudo -iu invocation, password handling via stdin with no logging. Missing: side effects, error conditions, timeout behavior, or return value format beyond jobId.
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: first states the primary action and key output (jobId), second references sibling tools and highlights password security. No fluff, front-loaded.
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?
No output schema or annotations, so description must carry the full burden. It explains core behavior but omits details like error handling, authentication needs, or exact response structure. Adequate for simple usage but not robust 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?
Schema coverage is 57% (4 of 7 parameters have schema descriptions). The description adds value for sudoPassword (piped stdin, not logged) but doesn't elaborate on other parameters beyond schema. Since schema covers some, description is adequate but not compensating for the 43% uncovered.
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 starts a long-running command as another user via sudo, returns a jobId immediately, and distinguishes itself from siblings like exec_status and exec_cancel. The verb 'Start' and resource 'long-running command' are 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 tells the agent to use exec_status to read output and exec_cancel to stop the command. It explains that the password is never logged, but does not explicitly explain when not to use this tool versus exec_as or exec_start (e.g., synchronous 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?
Without annotations, the description carries the full burden. It explicitly states the tool returns non-sensitive metadata, implying a read-only operation with no side effects. However, it could be more explicit about the read-only nature and any 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 a single sentence that front-loads the action and then provides specific details. Every word adds value; 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?
For a simple list operation with no parameters and no output schema, the description adequately covers what the tool does and what data is returned. It could mention the response format or behavior when no connections exist, but overall it is sufficiently 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?
The tool has no parameters (schema coverage 100%). Per rubric, a 0-parameter tool gets a baseline of 4. The description adds context by listing returned fields, which is helpful even though it is not about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists currently registered SSH connections and specifies the returned non-sensitive metadata fields (connectionName, host, port, username, connectedAt, status). The title also reinforces the purpose. It is distinct from sibling tools like connect, disconnect, and exec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it is implied that listing connections is separate from connecting or executing commands, there is no guidance on prerequisites or when another tool might be preferred.
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 critical behaviors: temporary in-memory connection, credential wiping on disconnect, disabled host-key checking, and a trust warning. This goes well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a warning, front-loaded with the action and key requirements. Every sentence provides essential information 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?
The description covers purpose, credentials, security, and lifecycle (temporary, wiped). It could mention that connect returns a connection handle (implied by connectionName parameter) but overall is complete for a tool with 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 coverage is 100%, so parameters are already documented. The description adds value by clarifying the exclusivity relationship between password and privateKey, and emphasizing credential handling (never logged).
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 opens an SSH connection, specifies required fields (host, username, either password or privateKey), and distinguishes from sibling tools like exec and disconnect by focusing on connection establishment.
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 lists requirements but does not explicitly state when to use this tool versus alternatives (e.g., as a prerequisite for exec calls). It implies usage context but lacks explicit when/when-not 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?
With no annotations, the description carries the full burden. It discloses that it returns local diagnostics and performs a short SSH probe for a named connection. It could be more explicit about being read-only, but it implies no 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?
Two sentences succinctly capture purpose, behavior, and usage context. No unnecessary words or repetition.
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?
Complete for a diagnostic tool with one optional parameter and no output schema. Covers all key aspects: what it returns, when it's useful, and the optional probe behavior.
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% and the description adds meaning by explaining the parameter's effect: a short SSH probe for the named connection, and what happens when omitted (general diagnostics).
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 ('Return explicit local diagnostics') and resource ('MCP/SSH state'), and clearly differentiates from sibling tools like connect, exec, and file operations by specifying the diagnostic scope.
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 diagnostic context ('distinguish server unavailable, SSH unavailable, dead connection, and MCP transport issues') but does not explicitly state when not to use or compare directly to siblings.
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-chat-mcp MCP server](https://glama.ai/mcp/servers/aiplatforms-ru/ssh-chat-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aiplatforms-ru/ssh-chat-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aiplatforms-ru/ssh-chat-mcp'

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