Server Quality Checklist

Tool Scores

• kill_sandboxA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description is the only source of behavioral context. It discloses the return value (error message on failure, empty string on success) but does not explicitly warn that killing is irreversible or that it terminates all running processes. The verb 'kill' implies destructive action, but more explicit disclosure would improve 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 extremely concise, with a clear one-sentence purpose followed by structured Args and Returns sections. Every sentence is informative and necessary without redundant 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?

  Given the tool's simplicity (one parameter, small scope), the description covers the core aspects: what it does, how to invoke it, and what to expect in the return. It could improve by adding a note about when to use it (e.g., 'after finishing work in the sandbox'), but it is largely complete for an agent to operate correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero description coverage for the sandbox_id parameter. The description compensates by stating 'sandbox_id: The ID of the sandbox to kill', which clearly explains the parameter's purpose. It does not specify format or source, but the meaning is clear and sufficient for a simple ID.

  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 ('Kill an E2B sandbox') and the targeting method ('by its ID'). This distinguishes it from sibling tools like create_sandbox, run_command, and run_code, which are about creation and execution rather than termination.

  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 use case—terminating a sandbox when it is no longer needed—but does not explicitly state when to use it or provide alternatives/exclusions. It is sufficient for an agent to understand the basic purpose, but lacks explicit guidance on lifecycle or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• run_commandA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description discloses the return format (JSON with stdout, stderr, exit code) and the side effect of creating a new sandbox when none is provided. However, it omits details like execution environment permissions, timeouts, or whether commands are run in a persistent shell.

  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 front-loaded with a one-sentence purpose, followed by a compact Args list and Returns note. No redundant filler; every section serves a 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 two parameters and an output schema. The description covers purpose, parameters, and return format. It doesn't address error conditions or sandbox setup prerequisites, but the self-contained behavior (creating a sandbox if needed) is explained. Overall sufficient for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has no parameter descriptions (0% coverage), but the description's Args section provides clear explanations for both command and sandbox_id, including optionality and behavior. This compensates for the schema's lack of detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Run a shell command in an E2B sandbox' with a specific verb and resource. It distinguishes itself from siblings like run_code by specifying shell commands, and from sandbox management 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 gives context on how to use the sandbox_id parameter ('Optional sandbox ID to connect to an existing sandbox. If not provided, a new sandbox will be created.'), but does not explicitly mention when to prefer this over run_code or other alternatives. Usage is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_sandboxA
  4.3/5.0
  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 the core behavior (creates a sandbox and returns its ID) and optional template/timeout settings. However, it omits any mention of side effects, prerequisites (e.g., authentication), or post-creation state (e.g., that the sandbox persists until killed). This is minimal but 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 brief and well-structured, using a clear Args/Returns format. The main purpose is front-loaded in the first sentence. Every sentence conveys useful information with no fluff or repetition.

  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 (2 optional params, no nested objects), the description is largely complete: it explains params, return format, and the core action. It does not cover edge cases like timeout expiry behavior or sandbox readiness, but that is not essential for a create tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero description coverage, so the description is the sole source of parameter meaning. It fully explains both parameters: timeout (units, default) and template (optional, default behavior). This adds substantial value beyond the schema's raw type/default fields.

  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: 'Create a new E2B sandbox and return its ID.' This clearly distinguishes it from sibling tools like kill_sandbox and run_command. It also states the primary return value, leaving no ambiguity about 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its usage as the initial step in an E2B workflow (creating a sandbox), which is clear from the context of siblings (kill, run). However, it does not explicitly mention when to use it versus alternatives or any 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.

• run_codeA
  4.3/5.0
  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 explains execution in a secure sandbox, the optional connection to an existing sandbox or creation of a new one, and the JSON return containing stdout/stderr. This is substantive, though it doesn't mention potential side effects like sandbox cleanup or persistence.

  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 Args and Returns sections. Every sentence provides necessary information without fluff, and the most important purpose statement is front-loaded.

  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 (2 parameters, no annotations, output schema exists), the description covers purpose, parameters, and return value adequately. It could be more complete by adding details about sandbox lifecycle or execution environment constraints, but it is sufficient for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must fully explain parameters. It does: 'code' is defined as Python code to execute, and 'sandbox_id' is described as optional, with a clear behavioral note that a new sandbox is created if omitted. This adds significant meaning beyond the bare 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 the specific verb and resource: 'Run python code in a secure sandbox by E2B.' It distinguishes itself from sibling tools like run_command by explicitly targeting Python code with Jupyter Notebook syntax, while create_sandbox/kill_sandbox are lifecycle 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 gives useful context for when to use the tool: to run Python code, and explains the optional sandbox_id behavior. However, it does not explicitly mention when not to use it or point to alternatives like run_command for non-Python commands, leaving usage guidance implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.