remote-shell-mcp

Server Quality Checklist

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

Latest release: v5.0.0
Disambiguation2/5
The `shell` tool is described as the primary tool for remote commands and session control, but it overlaps heavily with `remote_session_start`, `remote_session_end`, `remote_session_signal`, and `remote_session_output`. Several session inspection tools (`remote_session_history`, `remote_session_output`, `remote_session_search`, `remote_session_errors`) also have fuzzy boundaries. An agent would struggle to decide whether to use `shell` or a dedicated `remote_session_*` tool in many situations.
Naming Consistency3/5
Most tools follow a `remote_<resource>_<action>` pattern, but the `shell` tool breaks it by not having a `remote_` prefix. There are also minor inconsistencies in pluralization (e.g., `remote_blocks_list` vs `remote_block_get`, `remote_shares_list` vs `remote_session_*`). Overall the pattern is readable but not fully uniform.
Tool Count2/5
With 56 tools, this server is heavily overweight. While the domain covers many features (sessions, files, ports, blocks, panes, sharing, swarms, streaming), the granularity is excessive. For example, there are 7 separate pane tools and 8 swarm tools, which feels bloated. A more concise set of 15-20 tools would likely cover the same functionality with less confusion.
Completeness5/5
The tool surface is exceptionally complete for a remote shell server. It covers session lifecycle, file transfer, port forwarding, command history, multi-pane management, session sharing, swarm operations, and streaming/error detection. There are no obvious missing operations; it even provides specialized input methods for prompts, passwords, and confirmations.
Average 3.7/5 across 56 of 56 tools scored. Lowest: 2.8/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 status not available
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.
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 carries the full burden of behavioral disclosure. It only states 'Stop sharing a session' without revealing what happens to the session itself, whether the action is reversible, what permissions are required, or what the output/error conditions might be. It adds no context beyond the name.
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 with no fluff, but it is under-specified rather than appropriately concise. It fails to include even a brief note about parameter usage or effects, making it too terse for a mutation tool with two alternative parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two optional parameters, the description is incomplete. It does not explain how the tool behaves when both shareId and sessionId are provided, whether an error occurs if the share does not exist, or what the return value indicates. This leaves the agent uncertain about edge cases and proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both parameters: 'Share ID to remove' and 'Session ID to unshare (alternative to shareId)'. The description itself adds no parameter details, but the schema already documents them adequately, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop sharing a session' clearly identifies the action (stopping) and the resource (a session), which distinguishes it from sibling tools like remote_session_share (which starts sharing) and remote_shares_list (which lists shares). However, it does not explicitly differentiate itself by name in the description, but the verb+resource structure is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remote_share_update or remote_session_share. There is no mention of prerequisites (e.g., that the session must be currently shared), no exclusion criteria, and no indication of when to prefer shareId over sessionId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates the tool mutates collapsed state but doesn't mention side effects, reversibility, or what the response contains. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, zero fluff. It is appropriately sized for the low complexity of the tool and is very easy to parse.
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 is simple, but with no annotations and no output schema, the description alone is too sparse. It doesn't explain what 'block' refers to, how collapse works, or what the result of the operation is. This leaves notable ambiguity for an 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 description coverage is 100%, so the baseline is 3. The description adds no real semantic value beyond the schema's param descriptions; the 'omit to toggle' behavior is already in the schema for the 'collapsed' parameter and is not elaborated on in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Toggle or set' and the resource 'block collapsed state', which conveys the core function. It is distinct from sibling tools like remote_blocks_list or remote_block_get, though it doesn't explicitly explain what a block is.
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, when to toggle vs. set, or any prerequisites or context. The single sentence offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the search covers command history and output, but fails to mention that the search defaults to the active session unless sessionId is provided (as indicated in the schema), nor does it clarify the read-only nature or result format. This leaves significant ambiguity about the tool's scope and 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?
The description is two short, direct sentences with no filler. It front-loads the primary purpose and then clarifies scope, making it efficient and easily skimmable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a well-documented schema, the description omits important context: the default scope is the active session (per sessionId), there is no output schema to clarify return format, and no distinction from similar search tools. For a tool with many siblings, this is 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?
The input schema has 100% coverage with descriptions for all five parameters. The description adds minimal semantic value by mentioning 'command history and output' as the search target, but it does not elaborate on parameter behavior beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'search' and identifies the resource as 'command blocks' with scope 'command history and output'. It distinguishes from sibling tools like remote_blocks_list (list) and remote_session_search (session-specific) through the phrase 'across blocks', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remote_session_search or remote_blocks_list. The description only states what it does, not the appropriate context 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without explaining side effects, prerequisites, or error behavior. It does not mention whether switching focus is non-destructive, what happens to the previous focus, or any required session state.
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, efficient sentence with no redundant words. It is appropriately sized for a simple parameter set, though it could benefit from more context 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?
The tool has no output schema, no annotations, and a sparse description. It does not explain what happens on success or failure, nor does it situate the tool among the many pane-related siblings. The description is bare-bones and leaves significant gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides paneId with the description 'Pane ID to focus', achieving 100% coverage. The tool description adds no further meaning or context for the parameter, so the baseline of 3 applies.
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 'Switch to a specific pane' clearly states the action (switching focus) and the target (a specific pane), using a specific verb and resource. It is distinct from siblings like remote_pane_next or remote_pane_list, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remote_pane_next for sequential navigation or remote_pane_list for viewing panes. The word 'specific' implies using an explicit paneId, but the description does not offer any exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Supports regex' but does not explain how regex is applied, what the result format is, whether pagination is used, or any limitations. It also doesn't clarify whether the search spans all sessions or only a specific one, despite having a sessionId parameter. This is minimal disclosure for a search 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 extremely concise, consisting of two short sentences. It front-loads the core action and avoids unnecessary detail. Every word earns its place, making it highly efficient while still conveying the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 1 required, no output schema, no annotations), the description is incomplete. It provides only a basic function statement and regex support, but lacks usage guidance, behavioral details, and what the returned results look like. This is a significant gap for an agent to invoke it correctly, especially with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter coverage with basic descriptions for each parameter, so the baseline is 3. The description adds a little extra context by mentioning 'command history and output' and 'regex,' which maps to the includeOutput and regex parameters, but it doesn't provide detailed semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search through command history and output.' This is a specific verb+resource combination that identifies what the tool does. However, it does not explicitly differentiate it from sibling tools like remote_session_history or remote_blocks_search, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for use, or contrasts with sibling tools like remote_session_history or remote_blocks_search. The only implied hint is that it searches history and output, but this is not explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Switch to the next pane' without explaining whether it changes focus, wraps around, or handles inactive sessions. No side effects or error conditions are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action without elaborating unnecessarily.
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 simple one-parameter tool, the description is minimally adequate. However, given the extensive set of sibling pane tools, it lacks context on how 'next' relates to pane ordering and how this differs from focus or list operations, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (sessionId) with a note about defaulting to the active session. Since schema coverage is 100%, the description adds no additional meaning, and baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Switch' and names the resource 'next pane in the session', clearly indicating a navigation action. However, it does not explicitly distinguish from sibling tools like remote_pane_focus or remote_pane_list, though the 'next' qualifier implies a sequence.
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?
There is no guidance on when to use this tool versus alternatives such as remote_pane_focus or remote_pane_list. No prerequisites, scenarios, or exclusions 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?
No annotations exist, so the description must convey behavior. It discloses the updatable fields but does not state whether the operation is destructive (e.g., replaces permissions), requires an existing share, or has any side effects. This is a notable omission for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the verb and object. It is appropriately sized and avoids 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 no output schema and no annotations, the description is too thin. It omits critical operational details like whether the share must already exist, how the update interacts with existing settings, and what the return value signifies. An agent would have to make assumptions to use this tool confidently.
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?
Because the input schema already describes all three parameters with 100% coverage, the baseline is 3. The description's mention of 'permissions' and 'expiration' mirrors the schema's descriptions without adding new syntax or semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and resource ('share settings'), with specific mention of permissions and expiration. This distinguishes it from sibling tools like remote_shares_list (listing) and remote_session_share (sharing creation).
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 implies the tool is for modifying an existing share, but it provides no explicit guidance on when to use it versus alternatives such as remote_session_share or remote_shares_list. There are no stated prerequisites or exclusions, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Get command history') but does not disclose behavioral details such as read-only nature, ordering, the meaning of 'working directories', or what happens with omitted sessionId.
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 wasted words, clearly front-loaded with the verb and resource.
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 low complexity (2 optional params, no output schema), the description captures the core purpose but lacks usage guidelines and behavioral context, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with both 'limit' and 'sessionId' described, so the baseline is 3. The description does not add parameter semantics beyond the schema, though it mentions 'working directories' as part of the result.
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 ('Get') and resource ('command history for a session'), and distinguishes itself from sibling tools like remote_session_output or remote_session_search by specifying it includes working directories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remote_session_search or remote_session_output. The description lacks any context about when sessionId is needed or how it relates to other session history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not explain side effects, whether the change is reversible, if it affects other session operations, or what response to expect. This is a gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, so a short description is acceptable. However, as a mutation, it lacks details about reversibility and effects, leaving gaps that should be addressed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'sessionId' with a description ('Session ID (defaults to active session)'). The tool description adds no additional meaning beyond the schema, but since coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disable real-time streaming for a session' uses a specific verb and resource, clearly indicating the action. However, it does not explicitly distinguish from sibling tools like remote_stream_enable or remote_stream_status, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb 'Disable' and resource 'real-time streaming'. No explicit guidance is given on when to use this tool versus alternatives, such as when the user wants to stop streaming but keep the session active, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action but does not disclose any side effects, prerequisites, or failure modes, providing minimal transparency for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose with no wasted words. However, it may be too sparse to be fully useful, but it is well-structured and front-loaded.
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 is highly incomplete for a mutation tool with a nested target object and no output schema. It lacks information about required fields, behavior on success, or side effects, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The tool description does not add any additional parameter semantics beyond the schema, placing it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'add' with resource 'target' and scope 'existing swarm', clearly differentiating it from sibling tools like remote_swarm_create and remote_swarm_remove_target. It precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The phrase 'existing swarm' implies the tool is for adding to an already-created swarm, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains what a block is but does not disclose aspects of the listing operation such as ordering, pagination, default return size beyond the schema, or whether it is read-only. It also does not mention response format or side effects, which is a notable gap given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences. The first sentence front-loads the primary purpose, and the second provides helpful context about blocks. It is appropriately sized with no redundant content, though the second sentence is slightly tangential to the immediate operation.
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 and strong schema coverage, the description is adequate but not fully complete. It explains what a block is but does not specify the return format, pagination, or relationship to sibling tools. Since there is no output schema, a bit more detail on the response would have improved completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters (limit, sessionId, showCollapsed). The description adds no extra parameter details beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List command blocks for a session.' It identifies the resource (command blocks), the operation (list), and the scope (session). It also adds context by explaining what a block is, making the purpose unambiguous and distinguishing it from single-block retrieval or search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying blocks can be searched, tagged, and referenced by ID, but it does not explicitly state when to prefer this tool over alternatives like remote_blocks_search or remote_block_get. There is no direct guidance on when not to use this tool, leaving the agent to infer from the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It mentions the 'cannot close the last pane' restriction, but does not disclose side effects such as destruction of the pane, impact on running processes, irreversibility, or permission requirements. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no wasted words. 'Close a pane' states the action, and the parenthetical adds a critical constraint, both earning their 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?
Without annotations or an output schema, the description should provide more context for this destructive operation. It lacks guidance on how to obtain pane IDs, what happens to running processes after closing, or any prerequisites. The current description is too sparse for safe, informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes paneId as 'Pane ID to close' (100% coverage). The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb and resource: 'Close a pane'. It also adds a useful constraint ('cannot close the last pane') that distinguishes it from other pane-related tools. The operation is unique among siblings like remote_pane_split or remote_pane_focus.
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 action is implied as the way to close a pane, and the 'cannot close the last pane' provides a when-not constraint. However, it does not explicitly mention alternatives, prerequisites (e.g., needing an active session), or how to identify pane IDs (e.g., via remote_pane_list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Rename a pane for easier identification' states the core action but does not mention potential side effects, error conditions, required permissions, or whether the name change is temporary or persistent. For a mutation tool, this is a noticeable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that says exactly what needs to be said. Every word earns its place, with no filler or 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?
Given the low complexity of a rename operation and full schema coverage of both parameters, the description is adequate for understanding what the tool does and how to invoke it. While it lacks broader context such as use cases or pane semantics, this is sufficiently complete for a simple tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (name and paneId) are already fully described in the schema. The description adds no additional parameter-level meaning, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a pane for easier identification' uses a specific verb (rename) and resource (pane), making the purpose unmistakable. Among sibling tools, no other tool uses 'rename', so it clearly distinguishes itself from related pane operations like split, focus, close, and list.
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 or any prerequisites. It merely states the action without explaining context, constraints, or when one might prefer renaming over other pane management operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Read' implies a non-mutating operation and 'recent' clarifies scope, but it does not disclose whether reading consumes the buffer, whether it returns all output or only new output, or any permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no fluff. Every word adds meaning: 'recent', 'raw', 'session buffer'. Highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the core action, but without annotations or an output schema it leaves open questions about return format, buffer consumption, and session selection. Minimum viable for a basic read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'lines' is described but 'sessionId' is not. The description adds minimal parameter meaning, only implying that output is tied to a session buffer and recentness. It does not clarify that sessionId is optional or what it defaults to, leaving a semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('recent raw output from session buffer'), clearly distinguishing it from siblings like remote_session_history, remote_session_errors, and remote_session_status. The scope ('recent', 'raw') adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as remote_session_history or remote_session_errors. It does not state exclusions or mention that sessionId is optional/required, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that tags are added and that tags can be used for filtering, but does not disclose critical traits such as whether tags are appended or replace existing tags, idempotency, permissions, or error behavior. This is insufficient transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short sentences that immediately state the action ('Add tags to a block') and add relevant context (search filtering). No filler or redundant information, and the key verb is 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?
For a low-complexity tool with only 2 parameters and no output schema, the description covers purpose and a use case. However, it omits behavioral details (e.g., additive vs. replace semantics, error handling) and lacks any return-value description. It is minimally viable but not 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 description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema—it explains that tags enable filtering, which gives context to the 'tags' parameter, but does not elaborate on blockId or add format/constraint details.
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 ('Add tags') and resource ('a block'), clearly distinguishing it from sibling tools like remote_block_untag (which removes tags) and remote_blocks_search (which searches/filters). It also states the organizational 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 when to use the tool (to organize blocks for filtering/search), but does not explicitly contrast with alternatives or explain when not to use it. For example, it doesn't mention that remote_block_untag handles removal, so usage guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not disclose side effects (e.g., whether removal is permanent, idempotent, or requires special permissions). This is insufficient for a mutation tool with zero annotation coverage.
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 is front-loaded with the action and resource. Every word contributes to clarity with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully documented parameters, but there is no output schema or annotation to explain return values or edge cases (e.g., missing blockId, already-untagged tags). The description is minimally sufficient for a straightforward removal operation, but lacks any behavioral context beyond the action itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already fully documented. The description adds no additional semantic meaning beyond what the schema provides. Baseline of 3 applies since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove tags from a block' uses a specific verb (remove) with a clear resource (tags from a block). It directly distinguishes itself from the sibling tool remote_block_tag, which likely adds tags, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or when not to use it. It is minimally viable but lacks explicit exclusions or alternative references.
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 burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not explicitly mention side effects, default session selection, or error scenarios. It is minimally transparent for a simple list operation but lacks explicit safety or edge-case context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and target. Every word contributes, with no unnecessary detail.
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 simple 1-optional-param list tool, the description covers the core function but lacks usage context, alternative tool references, and explicit prerequisites (e.g., session must exist). It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents sessionId with a description (100% coverage), including its default behavior. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'all panes for a session,' which is clear and distinct from sibling pane-action tools (e.g., remote_pane_split) and session-status tools. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like remote_pane_focus or remote_session_status. The description states the operation but provides no context, exclusions, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing any side effects, prerequisites, or effects on sessions. For a destructive stop operation, this is minimal and leaves the agent guessing about what happens on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that communicates the core action and target. It is concise without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with good schema coverage, but the description does not explain the optional sessionId parameter's role or when to use this vs. remote_port_stop_all. Given no annotations and no output schema, more context would be helpful, making this minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides clear descriptions for both parameters (forwardId and sessionId) with 100% coverage. The description adds no extra parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (stop) and the resource (a specific port forward by ID). It distinguishes from siblings like remote_port_stop_all and remote_port_list by specifying 'specific' and 'by ID'.
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 that this tool is for stopping a single port forward identified by ID, but it does not explicitly mention alternatives (e.g., remote_port_stop_all) or when not to use this tool. Usage context is inferred from the name and the 'by ID' phrasing.
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 transparency. It only states the action without addressing prerequisites (e.g., an active session waiting for confirmation), side effects, or error behavior, which is a significant gap for a tool that sends input to a remote session.
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 wasted words, front-loading the action and resource. It is appropriately concise for a tool with a simple purpose.
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 is sufficient for a basic understanding but lacks context about when to use it relative to sibling input tools and what happens if no confirmation prompt is pending. The schema covers parameters, but overall guidance is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (confirm, waitTime, sessionId), so the schema coverage is 100%. The description adds no additional parameter context beyond echoing the boolean Y/N mapping.
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 'Send' and identifies the resource as a 'Y/N confirmation response to a session,' clearly distinguishing this from generic input tools like remote_session_input. The scope is well-defined and immediately understandable.
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 confirmation prompts but does not explicitly state when to use this tool versus remote_session_input or remote_session_password. No exclusions or alternative mentions are included, so the agent must infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool searches for specific keywords, but it does not state whether the operation is read-only, what the return format looks like, or how it behaves if sessionId is omitted. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the purpose and includes a useful parenthetical clarification. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity with two optional parameters and no output schema, the description is adequate but incomplete. It does not explain what the tool returns, whether it searches all sessions when sessionId is omitted, or any output structure. More context is needed for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (limit and sessionId), so the baseline is 3. The description adds no extra meaning about the parameters; it only mentions 'session history' which is already implied by the tool 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 clearly states the verb 'Find' and the resource 'error messages in session history', and the parenthetical '(looks for 'error', 'failed', 'denied', etc.)' provides specific detail. This distinguishes it from sibling tools like remote_session_history or remote_session_search by narrowing the scope to error-related content.
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 to find errors in session history. However, it does not explicitly mention when to use this tool over alternatives like remote_session_search or remote_session_history, nor does it provide exclusions or conditions for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only maps SIGINT to Ctrl+C but does not explain the effects of SIGTERM, SIGKILL, or SIGHUP, nor what happens to the session after the signal is sent (e.g., whether it terminates, restarts, or requires reconnection). It also does not mention whether sessionId is required or what the default behavior is when omitted. This is a significant gap for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the core action. Every word earns its place, with no filler or redundant information. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, enum signal, no output schema), but the absence of annotations and the lack of behavioral context (e.g., what happens when sessionId is omitted, or whether signals are sent to the remote shell or a specific process) leaves the description incomplete. The schema covers parameter syntax, but the description does not fully compensate for the missing safety and side-effect profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds marginal value by clarifying SIGINT=Ctrl+C, but leaves the other signal meanings implicit. The sessionId parameter's semantics are not elaborated beyond the schema's 'optional' tag, which is insufficient for an agent to know how to use it correctly.
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 action ('Send a signal') and the target resource ('the session'). It distinguishes itself from sibling tools like remote_session_input (which sends text input) and remote_session_switch by focusing on OS signals. The parenthetical maps SIGINT to Ctrl+C, adding immediate clarity.
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 used when you need to send a termination or hangup signal to a session, but it does not explicitly state when to use it versus alternatives (e.g., remote_session_input for textual input, remote_session_end for graceful shutdown). No exclusions or prerequisites are provided, leaving the exact trigger conditions up to the agent's inference.
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 states the start action and that it usually starts automatically; it does not describe side effects, idempotency, whether it errors if already running, or what the return value looks like. This is a significant gap for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains zero fluff. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter, and the description provides the key context that it usually starts automatically. However, it does not explain what happens on start (e.g., background process, status output) or how to verify success, so it is not fully complete. For a straightforward start command, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for the single 'port' parameter, including its default value. The description does not add any parameter-specific meaning beyond what the schema offers, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Start the share server.' This is a specific verb+resource construction, and the parenthetical note 'usually starts automatically' provides additional context. It is clearly distinct from sibling tools like remote_share_server_stop.
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 phrase 'usually starts automatically' implies the tool is only needed when the server is not already running, but there is no explicit when-to-use guidance, no mention of checking status first, and no alternatives named. Usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It only states the basic function without disclosing whether the operation is read-only, what 'active' means, or what the response format looks like. No side effects or limitations are mentioned.
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 ('List') and the object ('all active swarms'), with zero unnecessary words.
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 zero-parameter list tool, the description is minimally adequate, but it lacks details on the return format (e.g., what 'status' includes) and does not clarify how this differs from sibling tools. Without an output schema, the agent must infer response structure from the vague phrase 'with their status'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics to add, and the description does not attempt to describe any, which is appropriate here.
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 all active swarms and includes their status. It uses a specific verb ('List') and resource ('active swarms'), and the phrase 'all active' distinguishes it from sibling tools like remote_swarm_status that likely focus on a single swarm.
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?
There is no explicit guidance about when to use this tool versus alternatives such as remote_swarm_status or other list tools. The description implies a general listing use case but does not mention exclusions or when another tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Listing' implies a read-only operation, and 'like ls -la' suggests output content, but it does not explicitly state safety, session behavior, or error handling. Some context is added, but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently communicates the tool's purpose and output style without unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (read-only list, 2 parameters, full schema coverage), the description plus schema is mostly sufficient. It lacks explicit session guidance but remains complete for a basic listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so baseline score is 3. The description does not add parameter-specific details beyond the schema, though the 'ls -la' analogy provides some context for what 'details' means.
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 'List files in a remote directory with details (like ls -la)', using a specific verb and resource. The 'like ls -la' analogy clarifies the output format, which distinguishes it from file upload/download tools.
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 session requirements, exclusions, or related tools such as remote_file_upload/download, leaving the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the action but not behavioral traits like side effects on the previously active session, whether the switch is immediate, or what the return value is. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded, no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose. It could elaborate on what switching entails, but for a simple switch operation it is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes sessionId as 'Session ID to switch to' with 100% coverage, so the description adds no additional parameter meaning. Baseline 3 applies due to high schema 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 uses a specific verb ('Switch') and resource ('active session'), with a condition ('when multiple sessions are open'), which clearly distinguishes it from sibling tools like remote_session_start/end/status. It immediately conveys the tool's function.
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 multiple sessions are open, but does not explicitly contrast with alternatives or state when not to use. For example, it doesn't mention that this is for changing the current focus rather than creating or listing sessions.
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 the returned fields ('enabled, error count, pending prompts') and the read-only nature via 'Get', but it does not mention error conditions, the default active session behavior, or any side effects, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with a parenthetical detail, containing no fluff or redundancy. It efficiently communicates the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema; the description lists the return fields, which is helpful. However, it lacks usage context (e.g., how this differs from remote_session_status) and does not define what 'enabled' or 'error count' refer to in the streaming context, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the single parameter, including its optionality and default ('defaults to active session'). The description adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'streaming status for a session', with a parenthetical listing the key components (enabled, error count, pending prompts). This clearly distinguishes it from sibling tools like remote_session_status and remote_stream_enable/disable.
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 remote_session_status or remote_stream_enable/disable. The description implies usage by name and verb, but lacks explicit context or exclusions, so it falls short of the minimum guidance.
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. It only states the action and purpose, but does not disclose behavioral traits such as whether it blocks, returns output, requires an active session, or affects all panes across sessions. This is a significant gap for a mutating broadcast command.
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 action ('Broadcast a command to all panes'), and every word earns its place without filler 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?
The description adequately captures the essential purpose and use case for a simple broadcast tool, but lacks behavioral context such as return behavior and prerequisites. No output schema is present to fill that gap, so it's acceptable but not 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?
The input schema already fully describes both parameters (command and sessionId) with clear descriptions, so the tool description doesn't need to add more. It doesn't add extra meaning beyond the schema, matching the baseline for 100% schema 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 uses a specific verb ('Broadcast') and resource ('all panes in a session'), clearly distinguishing it from sibling tools like remote_pane_exec (targets a single pane) and shell (targets a session). The second sentence reinforces the multi-context use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'running the same command in multiple contexts simultaneously'. This provides clear context, though it does not mention alternatives or when not to use, so it stops short of a 5.
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 disclose behavior. It says 'Returns the complete command and output', indicating a read operation with no side effects, but it does not detail error behavior, formatting options like the raw flag, or any prerequisites. The schema holds the raw flag info, but the description itself lacks deeper transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, clear and efficient. 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 block retrieval tool, the description covers the core purpose and expected output. However, without an output schema or annotations, it could mention error handling or the effect of raw, but given the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so the description adds little beyond what is in the schema. It mentions 'full output' but doesn't clarify how raw affects the response or give block ID format beyond the schema examples. Hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: retrieving a specific block by ID with full output. The verb 'Get' and the resource 'block' uniquely identify it among siblings like remote_blocks_list and remote_blocks_search, which are for listing/searching.
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 by ID, saying 'by ID', which suggests you need to know the block ID. However, it does not explicitly mention alternatives or when not to use this tool, such as using remote_blocks_list for enumerating blocks. Thus only minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the error criteria (non-zero exit or error patterns) and that it returns blocks. Yet it does not describe ordering, pagination, or whether any state changes occur (though 'Find' implies 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?
Two concise sentences, front-loaded with the main action and followed by a brief clarification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple read-only tool: it names the action, resource, and error definition. Missing details like return format and sorting are not critical given the clarity of the schema and the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both 'limit' and 'sessionId' described. The description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Find error blocks in session history.' It specifies the resource (blocks) and the criterion (errors), distinguishing it from siblings like remote_blocks_list and remote_session_errors.
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 context: use when you need blocks that had errors (non-zero exit or error patterns). However, it does not explicitly state when not to use it or mention alternatives like remote_session_errors, so 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The term 'list' implies a read-only operation, and 'active' indicates it shows current forwards, but it does not disclose potential side effects (there are none) or what the return payload contains. It add minimal context beyond the verb, leaving some transparency gaps, though the operation is inherently safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'List all active port forwards.' Every word earns its place, with no redundancy or filler. This is an example of appropriate brevity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema) and the description fully captures its core behavior. However, since there is no output schema, it would be helpful to mention what the returned list contains (e.g., session IDs, port numbers), but this is not critical for a basic list operation. The description is complete enough for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the sessionId parameter fully described in the input schema ('Session ID to filter (optional, shows all if omitted)'). The tool description does not add any additional parameter context beyond the schema, but it doesn't need to since the schema already explains the behavior. Baseline 3 is appropriate given the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('active port forwards'), making the tool's purpose unambiguous. It clearly distinguishes from sibling tools like remote_port_forward_local and remote_port_stop, which perform different actions. The addition of 'all active' provides scope, matching the get_calls standard for a specific verb+resource+scope.
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 want to see active port forwards) but does not explicitly state when to use it versus alternatives like remote_port_stop or remote_port_forward_local. There is no mention of when-not-to-use or references to sibling tools, so it relies on the name and purpose to convey context. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not mention that ending a session is irreversible, what happens to associated processes, or any permission requirements, leaving the agent with only the verb 'End' as a cue.
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 short sentences, front-loaded with the primary verb, and no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with high schema coverage, the description covers the core functionality and the special 'all' case. It doesn't describe return values or side effects, but given the simplicity, it is reasonably complete; however, a safety warning would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the sessionId parameter including 'all' and omit behavior (100% coverage). The description's 'Use sessionId='all'' adds no new information, 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 the verb 'End' and the resource 'remote session(s)', making the tool's function explicit. It also distinguishes from sibling start/status tools by implying termination, and the 'all' variant is highlighted.
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 a specific usage instruction: 'Use sessionId='all' to end all sessions', which tells the agent how to target all sessions vs a specific one. However, it doesn't mention alternatives or when not to use, but given the tool's unique role, this is sufficient clear 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose the key side effect of disconnecting all viewers, which is valuable. However, it omits details about whether the underlying session remains active, whether the shared link is invalidated, and whether the action is reversible or idempotent.
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 with no wasted words. It front-loads the verb 'Stop', immediately names the resource, and includes the key consequence. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter stop operation with no output schema, the description is largely complete: it states the action and the primary side effect. A minor gap is that it does not relate this to the start counterpart or describe the state of the shared session after stopping, but the available context is adequate.
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 no parameters, and the baseline for zero parameters is 4. The description agrees with the schema by implying no configuration is needed, and there are no parameter semantics to explain.
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 'Stop' and names the resource 'share server', while also stating the meaningful consequence of disconnecting all viewers. This clearly distinguishes the tool from sibling tools such as remote_share_server_start and remote_share_update.
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 provided about when to use this tool versus alternatives such as remote_share_server_start or remote_share_update. It does not state prerequisites, such as the share server needing to be running, nor does it warn against use when no viewers are connected.
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 the key behavioral side effect that ending a swarm closes all its sessions, and the 'all' special case. However, it does not mention reversibility, required permissions, or effects on underlying processes, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, and no wasted words. The description is appropriately sized for a simple end operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description adequately covers the main action, side effect, and special value. It lacks details on error handling or return values, but these are less critical for a straightforward terminating operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already explains the 'all' value. The description redundantly repeats 'Use swarmId='all'' without adding extra semantic details beyond what the schema provides, so it adds no significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'End' + resource 'swarm', specifies it closes all its sessions, and includes the special value 'all'. This distinguishes it from sibling tools like remote_session_end (which ends a single session) and remote_swarm_interrupt (which sends an interrupt).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ending a swarm, with the special instruction to use swarmId='all' for ending all swarms. However, it does not explicitly mention when not to use this tool or how it compares to alternatives like remote_session_end for individual sessions.
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 the non-focus-switching behavior, but it does not mention output handling, side effects beyond execution, or any prerequisites like an active session. This is a minimal but not comprehensive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, with no filler or redundant information. 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?
For a two-parameter execution tool, the description is adequate, but it lacks information about return values or how to capture command output, especially since there is no output schema and no annotations. Given the availability of sibling tools like remote_session_output, this is a clear gap.
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?
Both parameters (paneId, command) are fully documented in the schema with clear descriptions, providing 100% coverage. The description adds no additional parameter-level detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Execute a command in a specific pane without switching focus,' identifying the action (execute), target (specific pane), and a distinguishing qualifier (without switching focus). This differentiates it from sibling tools like remote_pane_focus and shell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without switching focus' provides clear context for when to use this tool—when you need to run a command while preserving the current pane focus—but it does not explicitly name alternatives or exclusions, so it falls short of a 5.
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?
Since no annotations are provided, the description carries the burden. It discloses the primary behavioral outcome ('creates a new pane within the session'), which is useful. Yet it does not explain side effects such as whether the source pane remains active or how layout changes, nor does it discuss any prerequisites or reversibility. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action, and includes a helpful usage hint. No wasted words.
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 no output schema, and the description omits what the function returns and does not clarify the meaning of 'horizontal' vs 'vertical' (which can be ambiguous in tmux-style splits). Parameter coverage is perfect, and the usage context is provided, but those missing aspects prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The tool description itself adds no additional parameter details, so the baseline of 3 is appropriate—the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Split'), the resource ('current pane'), and the precise scope ('horizontally or vertically'). It also distinguishes from sibling pane tools by focusing on the split operation, which is unique among the listed sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage context ('Use for running multiple commands in parallel or monitoring'), which helps the agent decide when to invoke it. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full alternatives 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 carries the burden. It explains the core behavior (listens and forwards) and gives an illustrative example, but does not disclose side effects such as port conflict handling, whether the command blocks or returns immediately, or lifecycle management (e.g., need to stop via remote_port_stop).
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: a one-sentence definition followed by the example. Every sentence is purposeful, front-loads the main idea, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (4 params, no output schema, no annotations). The description adequately covers purpose and usage example, but lacks key operational context such as whether an active session is required, background vs. blocking behavior, and how to stop the forward. Given the absence of annotations and output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds a concrete example mapping ports (localPort: 5433, remoteHost: localhost, remotePort: 5432) but does not introduce semantics beyond what the schema already states for each 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?
Description clearly states 'Start a LOCAL port forward (SSH -L style)' with specific verb and resource. It distinguishes from sibling remote_port_forward_remote by explicitly marking 'LOCAL' and contrasting with SSH -L style, making its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context via example ('Access a database running on the remote server') and explains how to connect. However, it does not explicitly mention when not to use it or alternatives like remote_port_forward_remote, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core behavior (listening and forwarding) and the SSH2 session requirement, but does not mention side effects, permissions, or the ongoing nature of the forward beyond the example.
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, using a clear imperative and a helpful example. Every sentence adds value, and the example is particularly instructive without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool description covers the core purpose, the direction of forwarding, a requirement (SSH2 session type), and a practical example. Given the absence of annotations and output schema, it provides sufficient context for an agent to select and use the tool, though it could clarify the optional sessionId interplay.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with clear descriptions for all four parameters. The description adds a concrete example mapping remotePort 8080 to localPort 3000, reinforcing the semantics but not adding new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start a REMOTE port forward (SSH -R style)' and explains the direction: 'Listens on a port on the remote server and forwards connections back to your local machine.' This specific verb+resource description distinguishes it from the sibling remote_port_forward_local.
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 an example ('Expose a local dev server to the remote') and notes the SSH2 session type requirement. It gives clear context for when to use this tool, though it does not explicitly contrast with the local forward tool or mention 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 carries full burden for behavioral disclosure. It only states that the tool starts a remote shell session, but does not mention authentication requirements, session lifecycle, side effects, or what the tool returns. Starting a session is a state-changing operation and the description leaves these aspects 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 two sentences long, front-loaded with the primary purpose, and the second sentence provides valuable alternative guidance. Every word earns its place without 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?
With 16 parameters, no annotations, and no output schema, the description gives clear usage guidance but does not explain session-related outcomes (e.g., whether a session ID is returned), mutual exclusion of parameters by method, or how this fits with session management tools. Some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 16 parameters. The description adds only the generic phrase 'with explicit parameters', which does not meaningfully enhance parameter understanding. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Start' with a clear resource 'remote shell session', and explicitly contrasts with the `shell` tool, distinguishing it from sibling tools. This makes the tool's purpose immediately obvious and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use for fine-grained control' and 'For most cases, prefer the `shell` tool which auto-detects remote commands', providing explicit when-to-use guidance and naming an alternative. This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It clarifies the scope to 'active' shares, but does not explicitly state it is read-only, mention return format, or disclose any side effects. Still, the verb 'list' implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded and 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?
For a simple list tool with no output schema, the description provides the core purpose but lacks details on the return format, data fields, or any edge cases (e.g., pagination, sorting). It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides no additional detail. The description adds meaning by specifying the result set includes all active session shares, which helps the agent understand the tool's behavior absolutely.
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+resource ('List all active session shares') and clearly distinguishes from sibling tools like remote_share_update or remote_share_server_start. The 'active' qualifier adds useful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing current session shares, but does not explicitly state when to use this tool versus alternatives like remote_session_share for creating shares. No exclusions or alternate tool mentions are 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 carries the full burden. It does disclose a key behavior—output only, excluding command and metadata—which is helpful. Yet it does not mention the `stripAnsi` default behavior or any error/edge cases, leaving some behavioral ambiguity.
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, no filler, front-loaded with the core purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with 2 well-documented parameters and no output schema, the description provides sufficient context—it specifies what is returned and the intended use. It lacks mention of error handling or output size limits, but these are not critical for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described (`blockId` and `stripAnsi` with default). The description adds no additional parameter meaning beyond the schema, so the baseline 3 applies. It does not explain parameter interactions or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get block output only (for copying)' and explains it returns 'just the output without the command or metadata.' This specific verb+resource combination distinguishes it from sibling tools like remote_block_get that likely return complete block data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for copying' gives a clear use case, and the note about returning output without metadata implies this is preferred when you need clean, copyable content. However, it does not explicitly name alternatives or state when not to use it, earning a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does explain the underlying transfer mechanisms (SFTP for SSH2, base64 for child process), which is valuable. However, it does not mention side effects like overwriting existing files, permission requirements, or what happens on failure. This leaves some behavioral uncertainty.
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 with a clear main sentence, a bulleted list explaining the two session modes, and a practical example. No unnecessary words or repetition. It earns every sentence's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides solid context: what the tool does, how it works in different session types, and a concrete example. It does not cover error handling or overwrite behavior, but for a file upload tool with this simple interface, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already documents all three parameters (localPath, remotePath, sessionId). The description does not add new meaning to these parameters beyond the schema; it merely implies their use in the example. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Upload' and specifies the resource 'a file from local machine to the remote server', clearly distinguishing it from the sibling `remote_file_download`. The purpose is immediately obvious and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it works with both SSH2 and child process sessions, giving clear context for when it applies. It does not explicitly mention alternatives or exclusions, but the purpose is so specific that the intended usage is clear. The example 'Upload a config file to the server' reinforces the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. The description accurately states the destructive scope ('stop all') and the flexibility of 'session or all sessions', but it does not disclose side effects (e.g., whether existing connections are terminated, if the action is reversible) or any permission requirements.
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?
A single sentence that is front-loaded with the action, succinctly covering the tool's purpose and scope. No filler or 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 tool with one parameter and no output schema, the description provides the essential context: what it does and the two usage modes (specific session or all). It does not explain return values or side effects, but given the low complexity, the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the sessionId parameter already described as 'Session ID, or 'all' to stop all forwards'. The tool description essentially restates this, adding no new semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('Stop'), the resource ('all port forwards'), and the scope ('for a session or all sessions'). This clearly distinguishes it from sibling tools like remote_port_stop, which likely stops a single forward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's scope and the 'all sessions' option, implying when it is appropriate to use. However, it does not explicitly name alternatives like remote_port_stop for single-forward scenarios, so it falls short of full 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.
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 tells the user the tool returns details about detected prompts and how to respond, which is useful. However, it does not disclose whether the check has side effects, whether it consumes the prompt, or what happens when no prompt is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main purpose and followed by return-value information. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter, no output schema, and a clear purpose. The description adequately covers what the tool does and what it returns, though it could briefly mention behavior when no prompt is detected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter (sessionId) with a note about defaulting to the active session. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource combination: 'Check if a session is waiting for user input' and explicitly mentions password, confirmation, etc. This clearly distinguishes it from sibling tools like remote_session_status or remote_session_output by focusing on prompt detection.
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 the tool should be used to detect whether a session requires user interaction before responding. It provides clear context for when to use it, though it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the core behavior: creating a shareable URL and allowing others to view or control the session in real-time. However, it omits security implications (e.g., control permissions allow command execution) and the share's persistence/expiration behavior, which are important for an agent to assess safety before invoking.
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, front-loaded with the action ('Share a terminal session'), and every phrase adds value—no filler, no redundant restating of the tool name. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple purpose and a rich schema (100% coverage), though no output schema. The description implies the return value (a shareable URL) and the use case, but doesn't address edge cases like the session needing to be active or the share's lifetime, leaving a minor gap in an otherwise adequate description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—all four parameters have descriptions, so the description need not explain them. The description aligns with the permissions parameter by mentioning 'view (or control)' but adds no new parameter semantics beyond the schema, warranting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Share') and resource ('terminal session'), and distinguishes it from siblings by describing the outcome: a shareable URL for real-time view/control. This is distinct from unshare, list, and update tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use ('for collaboration') and specifies the mechanism (URL for viewing/controlling). It doesn't explicitly mention exclusions or alternatives, but the context is sufficient to differentiate from share-management siblings like remote_session_unshare and remote_share_update.
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 reveals that the tool executes commands, returns aggregated output, and runs in parallel, but it does not disclose error handling, side effects of command execution, or what 'smart-wait' means. This is adequate but leaves significant behavioral details to the schema and the agent's assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action front-loaded and the use case in the second sentence. No wasted words, and it is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, no output schema, and many sibling tools, the description gives the essential context: broadcast to swarm, parallel execution, aggregated output, and the primary use case. It does not explain return format or error aggregation, but the schema covers parameters, making the overall package reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaningful detail about specific parameters beyond what the schema already provides; it merely reinforces the 'parallel' concept. It fulfills the baseline but does not elevate it.
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 ('Broadcast') and resource ('command to all sessions in a swarm'), and clearly distinguishes the tool's scope ('all sessions', 'across multiple machines') from sibling tools like remote_pane_exec or remote_swarm_input. It also mentions parallel execution and aggregated output, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the intended use case: 'Use for running the same command across multiple machines.' This provides clear context for when to choose this tool, though it does not mention when not to use it or name alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (broadcast input to all sessions) and the interactive-prompt use case, but omits side effects, error handling, and whether the operation is asynchronous. This is minimal yet not misleading.
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 the action front-loaded. Every word contributes value, and there is no redundancy or filler.
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 straightforward broadcast-input tool, the description covers purpose and use case. Without an output schema or annotations, it lacks detail on return values and edge cases, but the core functionality is sufficiently clear for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters adequately described. The description adds no further parameter detail beyond the purpose, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send input text') and the scope ('to all sessions in a swarm'), distinguishing it from single-session input tools like remote_session_input. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'responding to prompts (passwords, confirmations) across all targets.' This gives strong contextual guidance, though it does not explicitly name alternatives or state when not to use the tool.
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 must carry the full burden of behavioral disclosure. It discloses the exact action (send SIGINT) and scope (all sessions in a swarm), which is good. However, it does not mention side effects, such as whether sessions remain active after the interrupt, if the swarm persists, or if there are any prerequisites or destructive implications. This would benefit from additional context but is not misleading.
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, complete sentence. It front-loads the action and includes the signal type and scope with zero superfluous words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. It specifies what, how (Ctrl+C/SIGINT), and to whom (all sessions in a swarm). It could be more complete by addressing what happens to the swarm after the interrupt, but the core behavior is covered, making it adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes one parameter, swarmId, with description 'Swarm ID'. Since schema description coverage is 100%, the description does not need to add parameter details. The tool description adds that the interrupt targets 'all sessions in a swarm', which clarifies the role of swarmId, but this is minimal additional meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send Ctrl+C (SIGINT) to all sessions in a swarm.' It names the specific signal and the resource (swarm sessions), which distinguishes it from sibling tools like remote_session_signal (single session) and remote_swarm_exec (command execution). This is a precise, non-tautological statement of purpose.
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 implicitly communicates when to use the tool: when you want to interrupt all sessions in a swarm. It provides clear context by specifying 'all sessions' and the signal type, but it does not explicitly name alternatives or when-not-to-use. This earns a 4 for clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It does disclose a significant side-effect—closing the target's session—which goes beyond the schema. However, it does not mention reversibility, impact on running processes, or any permissions required, leaving some gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly states the operation and adds a meaningful side-effect in a parenthetical. Every word earns its place; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive operation, the description covers the purpose and a key behavioral consequence. However, it doesn't elaborate on what happens to the session or whether the action is reversible, which might be useful given there is no output schema. Still, it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (swarmId and targetId), so the description adds no extra parameter semantics. With 100% schema coverage, a baseline of 3 is appropriate; the description does not need to compensate.
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 'Remove' and the resource 'a target from a swarm', which is specific and distinguishes it from related sibling tools like remote_swarm_add_target and remote_swarm_end. The parenthetical 'closes its session' adds valuable scoping and clarifies the operation's exact effect.
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 verb and object make the intended use obvious: use when you need to remove a target from a swarm. It doesn't explicitly mention when not to use it or contrast with alternatives, but the context is sufficiently clear given the sibling tool names and the explicit parenthetical.
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 transparency burden. 'Get detailed status' conveys a read-only operation, but it does not explicitly state that it has no side effects, requires an existing swarm, or how it handles invalid swarm IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. Every word contributes to explaining the tool's purpose and scope.
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 one-parameter getter with no output schema, the description is sufficiently complete: it states the action, the target, and that the result includes all targets. It could optionally mention error handling or output fields, but the tool's simplicity does not demand more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single swarmId parameter as 'Swarm ID' with 100% coverage. The description confirms that swarmId refers to a specific swarm but adds no additional constraints, format, or range information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed status of a specific swarm, using a specific verb and resource. It distinguishes itself from sibling tools like remote_swarm_list by focusing on a single swarm and including all targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this should be used when a user needs detailed status for one swarm rather than a list of swarms, but it does not explicitly name alternatives or exclusion criteria. The context makes the intended use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It explains that swarms connect to multiple servers simultaneously and can broadcast commands, which gives some behavioral insight. However, it omits important side effects such as whether connections are established immediately, auto-reconnect behavior, credential requirements, or that creation returns a swarm ID needed for subsequent commands.
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: it leads with the core purpose, follows with a brief use-case statement, and then provides practical examples. No sentences are wasted, and the examples earn their place by showing real target formats.
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 input side well with examples and clear purpose, but it does not mention what the tool returns (no output schema exists) or how to follow up after creation (e.g., using remote_swarm_exec). It also only illustrates SSH and GCloud targets, leaving AWS/Azure/custom methods to the schema alone. This is adequate but leaves meaningful gaps for an agent navigating the tool suite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents all parameters (100% coverage), the description adds valuable example target JSON structures for SSH and GCloud. These examples clarify how to format targets for different methods beyond what the schema alone conveys, though AWS, Azure, and custom examples are not provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Create a swarm of parallel SSH sessions to multiple machines'), clearly identifying what the tool does. It distinguishes itself from sibling tools by emphasizing creation and parallel broadcast capability, while siblings like remote_swarm_exec and remote_swarm_end handle other lifecycle phases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool ('Useful for managing clusters, fleets, or performing parallel operations'). However, it does not explicitly mention when not to use it or point to alternatives (e.g., remote_session_start for single sessions, or remote_swarm_add_target for modifying an existing swarm).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the transfer mechanisms (SFTP for SSH2, base64 for child process), which is valuable context beyond the schema. It does not cover potential side effects like file overwriting, but for a download operation this is acceptable.
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 well-structured and concise, with a clear opening sentence followed by bullet points and a short example. Every sentence earns its place, and it is appropriately front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with no output schema and three well-documented parameters. The description covers both session types, gives an example, and explains the transfer methods, which is sufficient for an agent to understand when and how to invoke it. Minor gaps like error handling are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter-level details beyond the schema, but it reiterates the intended use case with an example. The schema already documents each parameter adequately.
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 'Download' and the resource 'a file from the remote server to local machine', which is specific and unambiguous. It distinguishes itself from siblings like remote_file_upload (opposite direction) and remote_file_list (listing files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining that it works with both SSH2 and child process sessions and gives a concrete example ('Download logs or config files'). It does not explicitly mention when not to use it or compare with alternatives, but the context is sufficient for common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: monitoring for error patterns, interactive prompts, command completion, and the autoInterrupt Ctrl+C behavior. It lacks mention of potential side effects like performance impact, but covers the main operational traits.
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, uses bullet points for clarity, and every sentence contributes to understanding the tool's behavior. No fluff or 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?
Given the tool's simplicity (3 params, no output schema), the description covers the main functionality and behavior. It could mention return values or how to verify enabling, but that is not critical for an action tool. The description is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions, so the description doesn't need to repeat them. It does add context by explaining the autoInterrupt behavior ('it will automatically send Ctrl+C when errors are detected'), which aligns with but does not significantly extend the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enable real-time streaming for a session with error detection', which is a specific verb+resource action. It distinguishes from sibling tools like remote_stream_disable and remote_stream_status by focusing on the enabling action with error monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the context and effects of enabling streaming ('When enabled, the system monitors output in real-time for...'), but does not explicitly mention when not to use it or contrast with specific alternatives. Still, the use case is implicit and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a critical behavioral trait: 'Input is automatically hidden in responses.' This addresses the key security concern for a password-sending tool. It doesn't cover other behaviors like error handling, but the hidden-input trait is the most important.
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 no wasted words. The primary action is front-loaded, and the usage guidance follows immediately. Every part contributes meaning.
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?
Considering the tool's simplicity (3 params, no output schema), the description provides the essential purpose and usage context. Combined with the fully documented schema, it gives an agent everything needed to invoke this tool correctly. The hidden-input behavior is a valuable addition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with clear descriptions for all three parameters (password, waitTime, sessionId). The description adds no additional semantic value beyond what the schema already documents, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a password to a session.' It specifies the resource (session) and the purpose (password), and distinguishes itself from sibling tools like remote_session_input by emphasizing the hidden input aspect for secret data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use when prompted for sudo password, SSH passphrase, or other secret input.' It does not name alternatives or exclusions, but the context is clear and sufficient for an agent to select it for secret input scenarios.
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 burden. 'Get status' implies a read-only operation, but there is no explicit statement about safety or side effects. The description does provide useful behavioral context by listing exactly which status fields are returned, but it lacks clarity on behavior when no sessions exist or any potential rate limits.
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?
A single, focused sentence that opens with the verb 'Get' and quickly enumerates the key included status fields. Every word earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema read operation, the description is complete. It states the scope ('all remote sessions') and the specific information provided (working directory, port forwards, auto-reconnect), giving the agent sufficient context to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage with no properties). The description adds no parameter-specific details, but none are needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as 'all remote sessions', listing specific details (working directory, port forwards, auto-reconnect status). This distinguishes it from sibling tools like remote_session_history or remote_session_output, which focus on different aspects.
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 context for use is clear: checking the overall status of all sessions at a glance. However, it doesn't explicitly mention when not to use it or alternatives (e.g., remote_session_history for detailed logs), though the intent is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that input is sent to a session, that hideInput suppresses logging for sensitive data, and that waitTime/waitForOutput affect behavior. It doesn't mention whether a newline is appended or error handling, but for a focused tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the purpose appears in the first sentence, followed by a tight bullet list of use cases and a specific recommendation. Every sentence earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description covers the key aspects needed for correct use: when to use, what to send, sensitive-data handling, and optional wait behavior. It misses minor details like response format or newline handling, but for a 5-parameter tool with high schema coverage it is notably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description reinforces the hideInput parameter for passwords (also in schema) but adds no additional semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Send input text' and the resource ('a session'), with explicit use cases (respond to prompts, passwords, confirmations). This clearly distinguishes it from sibling tools like remote_session_output (which reads output) and remote_session_signal (which sends signals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use the tool ('Use when a remote command is waiting for user input') and lists concrete scenarios (password prompts, Y/N confirmations, etc.). It also offers a practical tip (set hideInput=true for passwords) that helps the agent apply the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses multiple non-obvious behaviors: automatic detection, smart wait time, working directory tracking, control sequences, auto-reconnect, 1-hour auto-cleanup, and exact terminal output. This goes beyond mere annotations and gives the agent vital operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headers and bullet points, front-loading the primary purpose. Every sentence conveys a distinct, useful fact without redundancy. Given the tool's complexity, the length is justified and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no annotations and no output schema, the description is remarkably complete. It covers command types, session lifecycle, control sequences, wait-time behavior, directory tracking, reconnection, cleanup, and output format. It leaves little ambiguity for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds value by explaining the 'Smart Wait Time' behavior tied to waitTime and the parallel session concept for forceNewSession, plus streaming context. This is meaningful extra semantics beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'PRIMARY TOOL - Intelligent shell command handler for remote sessions,' which clearly states a specific verb and resource. It further differentiates from sibling tools by explaining how it automatically detects remote commands, executes regular commands, and handles session control, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage clearly: it is the primary tool for shell commands, handling remote vs local automatically. However, it does not explicitly name sibling alternatives (e.g., remote_session_start) or state when not to use them, so it lacks explicit exclusions. The behavioral breakdown gives good context for when this tool applies.
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:

[![remote-shell-mcp MCP server](https://glama.ai/mcp/servers/raghavharness/remote-shell-mcp/badges/card.svg)](https://glama.ai/mcp/servers/raghavharness/remote-shell-mcp)

Score Badge

Copy to your README.md:

[![remote-shell-mcp MCP server](https://glama.ai/mcp/servers/raghavharness/remote-shell-mcp/badges/score.svg)](https://glama.ai/mcp/servers/raghavharness/remote-shell-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/raghavharness/remote-shell-mcp'

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