OctSSH

Server Quality Checklist

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

Latest release: v0.1.7
Disambiguation4/5
Most tools are clearly distinct: exec vs exec-async vs sudo variants separate sync/async and privilege. A few pairs could cause confusion, such as list vs info (both fetch host data) and get-result vs grep-result (both inspect async logs), but descriptions clarify their different purposes.
Naming Consistency4/5
Tool names consistently use lowercase hyphenated words (exec-async, upload-async, get-result, write-stdin). However, the placement of 'sudo' varies: sudo-exec puts it first while exec-async-sudo puts it last, which is a minor inconsistency.
Tool Count5/5
15 tools is well-scoped for an SSH server, covering synchronous/async execution, sudo variants, file transfer, session management, and host info. Each tool serves a clear purpose without feeling bloated or sparse.
Completeness4/5
The domain of remote SSH operations is fairly complete: exec, sudo, upload/download (sync and async), session status/log retrieval, and host listing. Minor gaps include no file-browsing or interactive shell, but core workflows are well covered.
Average 3.3/5 across 15 of 15 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
This server has been verified by its author.
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 is the only source of behavioral details. It mentions 'background' and 'passwordless sudo,' but does not disclose how the async execution works, whether a job ID is returned, how results are retrieved, or the purpose of the confirm_code parameter. This leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the core action. However, it is so brief that it omits critical details, making it more under-specified than appropriately concise. It earns its place but does not maximize informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the input requirements, the meaning of confirm_code, or the behavior after execution. The single-sentence description is inadequate for successful tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears full responsibility for explaining parameters. The description does not mention machine, command, or confirm_code, providing no meaning beyond the parameter names themselves. It fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a long-running command in the background with passwordless sudo. It uses a specific verb ('execute') and resource ('command'), and the sudo/background aspect distinguishes it from sibling tools like exec-async (which likely lacks sudo) and sudo-exec (which may be synchronous).
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 is given about when to use this tool versus alternatives such as exec-async or sudo-exec. The description implies use for long-running, sudo-requiring commands, but does not state conditions or exclusions, leaving the agent to infer the selection criteria.
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 burden of behavioral disclosure. It only states a search operation without explaining case sensitivity, regex syntax, session binding, or output format. No additional behavioral traits are disclosed beyond the basic action.
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, grammatically correct sentence, making it concise and front-loaded. However, it lacks any structure or expansion beyond the basic action, so it is not maximally helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter descriptions, this one-line description is severely incomplete. It does not explain how to invoke the tool with session_id, what results look like, or any edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of any parameter. The schema gives names and types only; the description fails to clarify the meaning of session_id, pattern, maxMatches, or contextLines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (search) applied to async stdout/stderr logs, with a pattern parameter. This clearly distinguishes it from siblings like get-result (which retrieves results) and exec-async (which starts processes).
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 such as get-result or cancel. It does not mention any prerequisites, limitations, or 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?
No annotations are provided, so the description must disclose behavioral traits. It does mention the use of passwordless sudo (sudo -n), which is a helpful detail. However, it fails to disclose important traits such as that it runs arbitrary commands with elevated privileges, potential side effects, or the role of the confirm_code parameter. The description is too sparse for a potentially dangerous execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core functionality. It is front-loaded with the action and resource, and there is no redundant or filler content. Every word earns its place.
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 higher complexity (arbitrary command execution with sudo), the description is extremely minimal. It lacks information about return values, execution mode (sync vs async), safety considerations, and the confirm_code parameter. With no output schema and no annotations, the description does not provide enough context for an agent to use the tool correctly and safely.
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 compensate. It does clarify 'command' and 'machine' through the phrase 'Execute a command on a machine', but it completely omits the 'confirm_code' parameter, leaving its purpose unexplained. With three parameters and only partial coverage, the description does not adequately compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a command on a machine using passwordless sudo. The verb 'execute' and resource 'command on a machine using passwordless sudo' are specific, and the mention of sudo -n distinguishes it from the non-sudo exec tool. However, it does not explicitly state whether execution is synchronous or asynchronous, leaving some ambiguity versus exec-async-sudo.
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 this tool is for running commands with sudo privileges, which is the primary use case. However, it provides no explicit guidance on when to use this tool versus alternatives like exec-async-sudo or exec. No exclusions or alternative references are given, so the guidance is purely implied.
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 behavioral burden. It adds two useful behaviors: session creation is conditional on the transfer actually starting, and overwrite confirmation logic matches the upload tool. However, it does not disclose other behaviors like non-blocking semantics, result retrieval, or potential error conditions, leaving 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 two concise sentences with no fluff. The key facts (async, conditional session creation, overwrite confirmation parity) are front-loaded and each sentence adds meaningful information. It is well-structured and easily scannable.
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?
This is an async tool with 4 parameters, no annotations, and no output schema, so the description needs to explain session lifecycle, result handling, and parameter specifics. It only covers conditional session creation and overwrite confirmation, leaving significant gaps about how to use the tool effectively (e.g., meaning of 'session,' how to retrieve results).
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 compensate. It only hints at the confirm_code parameter via 'overwrite confirmation logic' without explaining its format or when it is needed. The required parameters machine, localPath, and remotePath are not described at all, leaving the agent to infer their meaning from names and siblings.
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 identifies this as an async upload operation, distinguishing it from the sibling 'upload' tool. The verb 'upload' plus the 'asynchronous' qualifier conveys the core purpose, and the schema confirms localPath/remotePath/machine semantics. It lacks a bit of explicit scope (e.g., 'file transfer from local to remote'), but the meaning is sufficient.
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 choose async vs. sync upload. The description references the same overwrite confirmation logic as upload and mentions session creation, but does not state 'use this when you want a non-blocking transfer' or 'use upload for synchronous operation.' The necessity of the async variant is only implied by the tool name.
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 must disclose behavioral traits. It only mentions writing data and remote screen, but lacks details on side effects, what happens if the session is not running, default newline behavior, or failure modes. Overly minimal 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 concise and front-loaded, with two short sentences that get to the point. It is efficient, though it sacrifices necessary detail for brevity.
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 three parameters, no annotations, and no output schema, the description is too sparse. It omits parameter explanations, prerequisites, and behavioral details, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameters. It provides no information about session_id, data, or append_newline, leaving their semantics completely unexplained.
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 writes data to a running async session stdin, using a specific verb and resource. It distinguishes itself from exec-async by implying this targets existing sessions, but does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Works for exec-async sessions (remote screen)', indicating when this tool is applicable. It does not explicitly mention when not to use it or name alternatives, but the intended scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two important behavioral traits: sessions are only created if the transfer actually starts, and local files are never overwritten. This is valuable because no annotations are provided. However, it does not explain the async semantics such as return values or how to retrieve results.
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 short sentences, front-loaded with the core purpose. Every word contributes to the behavioral contract. It is appropriately concise without unnecessary filler.
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 three required parameters and no output schema, the description is insufficient for an agent to invoke this tool confidently. It omits parameter semantics, return values, and how to retrieve asynchronous results. The two disclosed behaviors are helpful but leave significant gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the three required parameters (machine, remotePath, localPath). The agent must rely solely on parameter names for meaning. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Async download', which clearly identifies the operation as a download variant. The 'Async' modifier distinguishes it from the sibling 'download' tool. However, it lacks detail about the resource being transferred beyond what the parameter names imply.
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 is given for when to use this tool versus 'download' or other siblings. The statements about session creation and file overwriting are behavioral constraints, not usage directions. No alternatives or prerequisites are mentioned.
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 mentions 'no sudo' and does not explain the confirm_code parameter, whether execution is synchronous, or what response is returned, leaving critical behavior 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 sentence with zero filler content. It is front-loaded with the primary action and includes a key constraint ('no sudo') without unnecessary words.
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 tool with 3 parameters, no annotations, no output schema, and 0% schema description coverage, the description is starkly incomplete. It omits important contextual details like the purpose of confirm_code and whether the tool is synchronous or asynchronous relative to sibling tools.
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 compensate. It implicitly explains 'command' and 'machine' but provides no meaning for 'confirm_code', which remains ambiguous despite its suggestive name.
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 'Execute a command on a machine (no sudo)' clearly identifies the action (execute), the resource (command on a machine), and the scope (no sudo), effectively distinguishing it from sibling tools like sudo-exec and exec-async-sudo.
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 a usage constraint ('no sudo') but does not explicitly state when to use this tool over alternatives such as exec-async or sudo-exec. The exclusion is implicit rather than directly naming fallback tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only mentions 'background' and 'remote screen session.' It omits key behavioral aspects such as how results are retrieved (likely via 'get-result'), the meaning of 'confirm_code', or whether the command is non-blocking and immediately returns a handle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the core purpose. No filler or repetition.
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 moderate complexity (3 parameters, no output schema, no annotations), this description is incomplete. It fails to explain the return behavior, the purpose of `confirm_code`, and the distinction from related tools like `exec-async-sudo`, 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter explanations. The `command`, `machine`, and `confirm_code` parameters are entirely unaddressed, leaving the agent to guess their roles and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: executing a long-running command in the background via a remote screen session. This distinguishes it from siblings like 'exec' (short-running) and 'upload'/'download' (file transfer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for long-running commands that need to run in the background. It does not explicitly mention when not to use it or cite alternatives, but the 'background' qualifier inherently excludes synchronous execution tools like 'exec'.
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 it gets status and tails logs, without mentioning what happens for invalid session IDs, whether it returns immediately or waits, or what the status response contains. It does not disclose any side effects or permission requirements, leaving the agent to infer the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Get async command status') and appends the optional log tailing. Every word is functional, with no redundancy or filler. It is both concise and well-structured.
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 (2 parameters, no output schema, no annotations), the description provides a basic functional overview. However, it lacks critical contextual details such as return value structure, error handling, and required session_id semantics. It is minimally viable but leaves gaps that could confuse an agent deciding if this tool meets its needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It explains that 'lines' is used to tail the last N lines from logs, which adds meaning beyond the schema's integer type. However, it does not explicitly describe the 'session_id' parameter, though 'async command status' implies its role. The description partially compensates for the lack of schema documentation.
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 'Get async command status; optionally tail last N lines from logs' clearly identifies the tool's purpose with a specific verb ('Get') and resource ('async command status' and 'logs'). It distinguishes itself from siblings like grep-result by focusing on status retrieval and log tailing rather than searching.
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 states what the tool does but provides no guidance on when to use it versus alternatives. It does not mention prerequisites, exclusions, or when to prefer another tool such as exec-async or grep-result. Usage context is only implied by the phrase 'async command status'.
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 responsibility for behavioral disclosure. It states the tool terminates a session, which implies a destructive action, but it does not mention whether this is reversible, what side effects might occur, or any permission requirements. The optional signal parameter is mentioned but its effect on behavior is not explained.
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 concise sentence that front-loads the action and resource. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core action for a simple tool, but gaps remain: it does not explain the return value, error conditions, or the meaning of the optional signal parameter. Given the absence of an output schema and annotations, a bit more detail would make it 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 description coverage is 0%, so the description must compensate. It names session_id and signal, but does not explain what signal values are valid, what the default behavior is when signal is omitted, or how session_id is obtained. The description adds minimal meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Terminate' with the resource 'running async session', making the tool's purpose unambiguous. It also clearly distinguishes itself from sibling tools by focusing on the cancellation aspect, especially since there is no other cancel-like sibling.
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 the tool (to cancel a running async session) but does not explicitly mention alternatives or exclusions. It does not reference sibling tools like get-result or write-stdin, leaving the guidance to be inferred from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states 'Never overwrites local files; on conflict, you must choose a new local directory,' which is a meaningful and non-obvious side-effect. It does not cover all aspects, but the key safety trait is 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?
Two concise sentences: the first states the core action, the second provides a critical conflict-handling rule. There is no filler or redundant information.
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 has moderate complexity with 3 required parameters, no annotations, and no output schema. The description covers the essential download behavior and conflict rule, but it omits sync/async distinction, success/error behavior, and prerequisites, making it incomplete.
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 0%, so the description must compensate. It adds some meaning by indicating remotePath can be a file or directory and localPath is a local directory. However, it does not define the machine parameter or provide explicit path format expectations, leaving gaps.
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 downloads a file or directory from a remote machine, which is a specific verb + resource. It does not explicitly differentiate from the download-async sibling, but it communicates the core action and direction well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like download-async or upload. The note about not overwriting local files is a behavioral safety rule, not usage-selection 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?
With no annotations, the description must carry the full burden of behavioral disclosure. It does add value by mentioning 'cached (or refreshed)', indicating a default caching behavior and a refresh option. However, it does not state whether the operation is read-only, what 'extended info' contains, potential side effects of refresh, or error behavior. The description leaves safety and side-effect expectations ambiguous.
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 concise sentence, front-loaded with the primary action ('Get cached (or refreshed) extended info'), and contains no redundant elements. Every word contributes to the meaning, making it appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and only two parameters. The description gives a high-level purpose but fails to specify what 'extended info' includes, what the return format is, or how errors are handled. An agent cannot predict what data it will receive or how to interpret the result, which is a significant gap for a tool with no structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It partially does: 'machine' is implied by 'Machine Info' and 'via SSH', and 'refresh' maps to 'cached (or refreshed)'. However, it does not clarify the format of the machine parameter (hostname, IP, ID) or the exact semantics of refresh (e.g., bypass cache vs. force new SSH connection). The schema provides types, but the description adds only minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Get cached (or refreshed) extended info for a machine via SSH.' It distinguishes this from sibling tools (exec, upload, download, etc.) by focusing on information retrieval rather than command execution or file transfer. The 'cached (or refreshed)' qualifier adds useful nuance beyond a generic 'get info'.
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 you need extended machine info, use this tool rather than running commands via exec-async or other execution tools. However, it does not explicitly state when to use this vs alternatives, nor when to choose cached vs refreshed results. There is no exclusion or alternative naming, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses a key behavioral trait: the tool refuses to overwrite unless a confirm_code is provided after a conflict preview. This adds valuable transparency about the tool's safety mechanism, which is not apparent from the schema alone. It does not mention other behaviors like sync/async nature or return values, but the overwrite protection is a significant 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 concise and well-structured: two sentences, front-loaded with the main purpose, and the second sentence adds a critical safety detail. No redundant phrasing or filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the overwrite refusal behavior, but lacks details about the conflict preview process (e.g., how confirm_code is obtained), whether the operation is synchronous, and expected return values. Given there are no annotations nor output schema, the description carries full burden and is somewhat underspecified for a tool with 4 parameters, though it provides a functional baseline.
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 compensate. It only explains confirm_code indirectly via the overwrite condition, but does not clarify the roles of machine, localPath, or remotePath. The meaning of these parameters is left to inference from their names, and the description does not state the relation between local and remote paths.
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 ('Upload') and resource ('file or directory') and clearly states the destination ('remote machine'). It also distinguishes from sibling tools like 'download' and 'upload-async' by including the overwrite-refusal behavior, which is a unique feature.
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 guidance on when to use this tool versus alternatives such as 'upload-async'. It only states the core action and overwrite behavior, leaving the agent to infer the tool's role. There are no explicit when/when-not conditions or references to sibling tool suitability.
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 fully convey behavior. It states the core action (sleeping for a duration) but does not elaborate on whether it blocks, what it returns, or any cancellation semantics. For such a simple tool, the lack of detail is acceptable but leaves some 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 sentence with no redundant words. Every part of it adds value, and it is front-loaded with the action. It is appropriately sized for the tool's simplicity.
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?
This is a very simple tool with no output schema and one parameter. The description is sufficient for basic usage, though it does not mention whether the call blocks or what it returns. Given the trivial nature of a sleep operation, the description covers the essential context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'time' parameter, so the description's phrase 'duration (ms)' is the only source of semantic meaning. It clarifies that the parameter is a time interval in milliseconds, which is essential for correct usage. The description compensates well for the schema's 0% 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 a specific verb ('Sleep') and resource ('duration (ms)'), and it distinguishes itself from sibling tools like exec or upload, which have entirely different purposes. The unit annotation adds precision, making the intent 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 the tool is for delaying execution, but it does not provide explicit when-to-use guidance or mention any alternatives. No exclusions or comparisons to other tools are given, so the usage context 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.
Behavior3/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 discloses that it reads from local ssh_config and optionally returns cached extended fields, implying a read-only nature. However, it does not explain what 'cached' means, potential staleness, or any side effects. For a simple list operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the primary purpose and add an optional behavior. No wasted words, perfectly sized for the tool's simplicity.
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 0-parameter, no-output-schema, no-annotation tool, the description is mostly complete. It clearly states what it lists and the optional cached fields. The only gap is not explaining what 'cached extended fields' entails, but the core functionality is fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to explain. The baseline of 4 is appropriate; the description adds no parameter info but none is 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 clearly states the tool's function: 'List configured SSH hosts from local ssh_config.' It specifies the verb (List), the resource (SSH hosts), and the source (local ssh_config), distinguishing it from sibling tools like exec, upload, and download. The optional 'cached extended fields' adds specific nuance.
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 when to use this tool: to enumerate SSH hosts from the local ssh_config file. The context is clear enough given the sibling tools are all execution/transfer operations. However, it does not explicitly mention alternatives or exclusions, such as using 'info' for system information, but the purpose is distinct.
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:

[![OctSSH MCP server](https://glama.ai/mcp/servers/AliyahZombie/OctSSH/badges/card.svg)](https://glama.ai/mcp/servers/AliyahZombie/OctSSH)

Score Badge

Copy to your README.md:

[![OctSSH MCP server](https://glama.ai/mcp/servers/AliyahZombie/OctSSH/badges/score.svg)](https://glama.ai/mcp/servers/AliyahZombie/OctSSH)

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/AliyahZombie/OctSSH'

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