I run shell commands on your private cloud environment (bash, sh, zsh)
Scored across 4 tools
bash, sh, and zsh all run shell commands with identical '(runner operator)' descriptions, so an agent cannot reliably choose between them; for most requests the choice is arbitrary. Only 'converse' has a clearly distinct purpose, leaving three heavily overlapping tools.
Names are all lowercase single tokens, which is readable and stylistically uniform, but there is no verb_noun pattern and 'converse' (a verb) sits alongside shell names (nouns). Conventions are consistent enough to parse but not predictable.
Four tools is a small but reasonable surface for a terminal agent. However, three of them are redundant shell variants, so the effective distinct functionality is closer to two, meaning not every tool earns its place.
Shell execution plus a conversational fallback covers the basic stated purpose, but the surface lacks supporting operations such as working-directory control, timeouts, or output/file handling. It is functional but thin for a terminal command agent.
Terminal command (runner operator): bash
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Specific parameters for this action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. For a shell-execution tool that can run arbitrary commands, it discloses nothing about side effects, permissions, sandboxing, or destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, but it is under-specified rather than concise: the single line is a label plus the tool name, front-loading nothing useful. Brevity here reflects missing content, not efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, a vaguely named parameter, and three competing shell siblings, the description leaves an agent unable to call this tool safely or correctly. Nothing an agent needs is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one optional parameter, so the schema does the documentation work and the baseline is 3. The description adds no meaning beyond the parameter name 'detail' and its generic schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('bash') and adds only the vague label 'Terminal command (runner operator)'. It does not state a specific verb+resource, and it gives no basis for distinguishing bash from its siblings sh, zsh, and converse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, when not to, or how it differs from the near-identical siblings sh and zsh. An agent has no information to choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply conversationally when the request is ambiguous or needs clarification.
| Name | Required | Description | Default |
|---|---|---|---|
| reply_hint | No | Optional hint for the conversational reply. |
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 says nothing about whether this ends the turn, whether it mutates state, whether it should be combined with other tool calls, or what the reply consists of — significant gaps for a tool with zero structured behavioral coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the action and appends the trigger condition; nothing is wasted. It is efficient, though it is efficient at a fairly low level of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity (one optional param, no output schema), so the short description is defensible, but with no annotations and no output schema the description should at least clarify the conversational fallback's role in the turn lifecycle. It stops just short of that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one optional parameter (reply_hint) whose schema description already covers it at 100% coverage, so the baseline of 3 applies. The description adds no syntax, format, or influence guidance beyond what the schema already supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It gives a verb ('reply conversationally') and a trigger condition ('when the request is ambiguous or needs clarification'), which separates it from the calendar siblings by function. However, the 'resource' is nebulous — there is no statement of what the reply acts on or produces, so the agent must infer it is a non-action fallback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names one condition for use: ambiguity or need for clarification. It implies, but never states, that the event-management siblings (add/update/delete/check events) are the alternative when the request is clear, leaving the when-not boundary to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminal command (runner operator): sh
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Specific parameters for this action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: not whether commands execute immediately, whether they are destructive, what permissions or sandboxing apply, or what is returned. For an arbitrary command execution tool this is the most important missing information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is very short, but brevity here reflects under-specification rather than economy. The one clause present adds no information an agent could act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A command-execution tool with no annotations, no output schema, no permission/risk disclosure, and no sibling differentiation is far too thin for an agent to invoke safely or correctly. Everything an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'detail' parameter, so the baseline is 3. The description adds no meaning beyond the schema, but the schema itself is thin ('Specific parameters for this action'), so no credit above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('sh') and adds only the vague qualifier 'Terminal command (runner operator)', which is effectively a tautology. It does not distinguish this tool from siblings bash, zsh, or converse, nor does it say what a terminal command runner actually does (execute shell commands, spawn a shell session, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use sh versus the sibling tools bash or zsh, nor when-not to use it. Given that three near-identical shell tools exist, the absence of any routing guidance is a serious gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminal command (runner operator): zsh
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Specific parameters for this action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no execution environment, no working directory, no side-effect or safety profile, no permission or sandbox constraints for what is effectively arbitrary command execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, but brevity here is under-specification rather than conciseness — the one sentence conveys almost no actionable information about a command-execution tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an arbitrary command runner with no annotations, no output schema, and an opaque single parameter, the description omits everything an agent needs: invocation format, execution context, and expected results. It is completely inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter 'detail' is technically documented in the schema, which sets the baseline at 3. However, the description adds no meaning beyond the schema's generic 'Specific parameters for this action', leaving the expected command syntax unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('zsh') and adds only the generic label 'Terminal command (runner operator)', which does not specify what command is run, how the argument is interpreted, or what distinguishes zsh from a shell invocation. An agent learns nothing beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus the near-identical siblings bash and sh, nor when not to use it (e.g., against converse). The choice among four overlapping terminal/chat tools is left entirely to guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bashconverseshterminal_command__bashterminal_command__converseterminal_command__shterminal_command__zshzshterminal_command__bashterminal_command__converseterminal_command__shterminal_command__zshA private persistent computer: files and a bash shell that survive between runs.
I do everything related to coding and execution tasks
Cloud macOS with Xcode for AI agents: run commands, build, test and ship iOS apps.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Add one secure layer between your agents and this server.
