I do everything related to coding and execution tasks
Scored across 8 tools
command__bash, command__sh, and command__zsh are functionally overlapping terminal runners with no guidance on when to choose one over another. Additionally, command__converse and interpreter__converse have identical descriptions, creating duplicate conversational tools.
All names use a consistent namespace__snake_case pattern (e.g., interpreter__generate_and_execute_code), and the double-underscore grouping is predictable. The action portion varies between shell names and verb phrases, which is a minor deviation rather than a chaotic mix.
Eight tools is reasonable for a code interpreter agent and falls within a typical well-scoped range. However, several tools are redundant (three shells, two converse), so not every tool clearly earns its place.
The set covers code generation (generate_code_only), execution (generate_and_execute_code), debugging (debug_update_existing_code), and shell access. A minor gap is the lack of a direct execute-existing-code tool, but shell runners partly compensate.
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?
With no annotations, the description carries the full behavioral burden, yet it discloses nothing about execution environment, permissions, side effects, timeouts, or what output is returned. A shell-execution tool is potentially destructive, so this silence is a significant gap, though the phrase 'terminal command' at least signals that something gets executed.
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 this is under-specification rather than disciplined conciseness — the single fragment carries almost no information and front-loads jargon. A longer description with real content would serve the agent better here.
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 a command-execution tool with no annotations, no output schema, and only a vague parameter description, the definition is completely inadequate. An agent cannot determine safety profile, environment, or return behavior from this text.
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 baseline is 3 even though the description adds nothing about the single 'detail' parameter. The schema's own description ('Specific parameters for this action') is generic, but per the coverage metric the schema is considered to document the parameter.
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 names a resource (terminal command, bash) but supplies no verb describing what happens — it largely restates the tool name. It does hint at sibling differentiation by naming 'bash' versus the sh/zsh siblings, but 'runner operator' is internal jargon that does not clarify the action.
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, no prerequisites, and no guidance for choosing between it and the closely related command__sh or command__zsh siblings. The only implied usage is that it runs bash commands, which the agent could infer from the name alone.
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 implies a non-executing, purely conversational response (useful context against command__bash/sh/zsh), but says nothing about side effects, output shape, or whether any state changes occur.
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 front-loaded sentence with no filler. It is efficient, though it packs two distinct ideas (purpose and trigger condition) that neither one fully develops.
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 a trivial one-optional-param tool with no output schema the bar is low, and the description covers purpose plus trigger. However, it never resolves the overlap with the twin sibling interpreter__converse, leaving an agent unable to pick confidently between them.
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 the single optional reply_hint parameter is already documented in the schema. The description adds no meaning about what the hint influences, so the baseline of 3 applies.
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?
"Reply conversationally" largely restates the name (converse), so the core purpose is only minimally specified. It does convey that the tool produces a chat reply rather than executing something, but it never clarifies how it differs from the near-identical sibling interpreter__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?
It gives an explicit when-to-use condition: "when the request is ambiguous or needs clarification." That is real routing guidance, though it names no alternatives or exclusions, leaving ambiguous overlap with interpreter__converse undirected.
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 burden, yet it discloses nothing about execution behavior: no working-directory context, no persistence between calls, no timeout/rate limits, no safety notes for 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?
The definition is short but under-specified rather than concise; a single tautological fragment leaves the essential information absent. Nothing is front-loaded because nothing substantive is stated.
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 a tool that executes arbitrary shell commands — the highest-risk category — the description omits every behavior an agent needs: execution semantics, output behavior, error handling, and interaction with sibling shells. With no annotations and no output schema, this is completely inadequate.
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 coverage is nominally 100%, but the single parameter's description ("Specific parameters for this action.") is vacuous boilerplate rather than real semantics. The tool description adds nothing about what `detail` should contain, so the nominal coverage does not translate into usable meaning.
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 phrase "Terminal command (runner operator): sh" restates the tool name rather than stating a verb+resource action. It hints that this runs shell commands via the sh interpreter, but gives no explicit verb and no distinction from the bash/zsh siblings.
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 command__bash, command__zsh, or the interpreter__* tools. The agent is left to infer the selection criteria entirely from the name.
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: not that this executes arbitrary shell commands, not sandboxing/permission behavior, not whether execution is destructive or irreversible, and not what the response contains. For an arbitrary command-execution tool this is a critical omission.
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 shortness here reflects under-specification rather than economy. The entire description is a fragment with no front-loaded explanation of what invocation does or returns, so nothing earns its place and nothing useful is conveyed.
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 a command-execution tool with zero annotations, no output schema, and an effectively undocumented parameter, the description is completely inadequate. An agent cannot determine safety, input format, or expected result from what is given.
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 nominally 100%, so the baseline is 3. However, the single 'detail' parameter is described only as "Specific parameters for this action," which is a placeholder that provides no real semantics; the description adds nothing beyond it. A 3 is the rule-mandated baseline despite the weak 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 names a resource (terminal command) and the shell variant (zsh), which does differentiate it from the bash/sh siblings. However, "runner operator" is cryptic jargon and the phrasing largely restates the tool name rather than stating a clear verb+outcome. It is more a label than a purpose statement.
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 zsh versus the sibling command__bash, command__sh, or the interpreter__* code-execution tools. Nothing indicates prerequisites, expected input form, or the conditions that should select this tool over its near-identical siblings.
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 behavioral burden. It does not say whether this tool executes code, returns text only, blocks, or requires any auth/context, and it does not clarify how it differs behaviorally from command__converse.
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 front-loaded sentence with no filler. It is tight, though the brevity is partly because behavioral and param detail are simply absent.
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 a low-complexity conversational tool with no output schema, the sentence covers the essential trigger. It falls short on sibling disambiguation (command__converse, command__bash) and any statement of what the tool actually returns or performs.
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?
With one optional parameter at 100% schema coverage, the schema already fully documents reply_hint. The description adds no format, syntax, or example for the hint, so the baseline 3 applies.
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 states a concrete action (reply conversationally) and the triggering condition (ambiguous or clarification-needed requests). It is clear on its own, but it does not distinguish itself from the near-identical sibling command__converse, which appears to serve the same role.
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?
It gives a usable trigger ('when the request is ambiguous or needs clarification'), which is real when-to-use guidance. However, it names no alternative and gives no when-not guidance, which matters given the overlaps with command__converse and the code-generation siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Code interpreter (runner operator): debug update existing code
| 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 must carry the behavioral burden, but it says nothing about what 'debug update existing code' actually does—whether it executes code, mutates files, persists changes, requires permissions, or has 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the brevity reflects under-specification rather than efficient communication. The single phrase is not front-loaded with actionable detail and contains no useful structure.
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 a code-interpreter tool with no annotations, no output schema, and a near-empty parameter description, this definition is not complete enough for an agent to call it correctly or understand its consequences.
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 reported as 100%, which sets the baseline at 3 per the rubric. However, the sole parameter's schema description ('Specific parameters for this action') is itself vacuous, and the tool description adds no further meaning beyond the schema.
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 almost verbatim ('debug update existing code') and adds only a generic parenthetical ('Code interpreter (runner operator)'). It does not specify the resource or distinguish this tool from siblings like interpreter__generate_and_execute_code or interpreter__generate_code_only.
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 when-to-use guidance is provided, no alternatives are named, and no conditions for selecting this tool over its siblings are given. Sibling tools are listed in context, but the description never references or contrasts them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Code interpreter (runner operator): generate and execute code
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Specific parameters for this action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and largely fails: it does not say whether execution is sandboxed, whether state persists between calls, whether the generated code is returned alongside output, or what permissions are required. 'Execute code' is a high-risk operation and none of its side effects 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with zero filler. It is efficient, but it is terse to the point of under-specification rather than genuinely concise value.
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 code-execution tool with no annotations, no output schema, and one unexplained parameter needs far more context than this. Nothing about sandboxing, persistence, return values, or limits is provided, so an agent cannot safely invoke it.
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?
The single parameter 'detail' is opaque, and the schema text ('Specific parameters for this action') is boilerplate that explains nothing. Despite nominal 100% coverage, the description adds no meaning about what belongs in that field (the code? a prompt? options?), so the agent gets no real guidance.
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?
States a specific verb pair ('generate and execute') on a specific resource (code), and the parenthetical names the operator. It implicitly distinguishes itself from the sibling interpreter__generate_code_only by promising execution, but it never says so explicitly.
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 when-to-use guidance, no exclusions, and no reference to sibling tools such as generate_code_only or command__bash. An agent has to guess whether to route a task here or to the shell siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Code interpreter (runner operator): generate code only
| 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. It implies no execution occurs, but says nothing about what is returned, whether the generated code is displayed, which language/runner is used, or any execution/safety constraints.
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 a single short, front-loaded line with no waste, but the brevity is under-specification rather than genuine conciseness given the sibling ambiguity it needs to resolve.
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 a tool that must be distinguished from generate_and_execute_code, with no output schema and no annotations, the description is far too thin. It leaves the agent unable to confidently decide between the two code-generation siblings.
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 baseline is 3 per calibration, but the single parameter's schema description ("Specific parameters for this action.") is itself generic, and the tool description adds no meaning about what "detail" should contain.
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 states a verb+resource ("generate code") and the parenthetical "(runner operator)" hints at scope, and "only" implies no execution. However it never names the obvious alternative interpreter__generate_and_execute_code, so an agent must infer the distinction from the name alone.
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 explicit when-to-use guidance and no mention of alternatives, despite a sibling (interpreter__generate_and_execute_code) whose behavior overlaps almost entirely. The only signal is the word "only", which is left for the agent to interpret.
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.
code_interpreter__conversecode_interpreter__debug_update_existing_codecode_interpreter__generate_and_execute_codecode_interpreter__generate_code_onlycommand__bashcommand__conversecommand__shcommand__zshinterpreter__converseinterpreter__debug_update_existing_codeinterpreter__generate_and_execute_codeinterpreter__generate_code_onlyterminal_command__bashterminal_command__converseterminal_command__shterminal_command__zshcode_interpreter__conversecode_interpreter__debug_update_existing_codecode_interpreter__generate_and_execute_codecode_interpreter__generate_code_onlyterminal_command__bashterminal_command__converseterminal_command__shterminal_command__zshI do everything related to Browser Automation & Management
I do everything related to Google Sheets
I run shell commands on your private cloud environment (bash, sh, zsh)
I do everything related to research and reports
Add one secure layer between your agents and this server.