Server Quality Checklist

Tool Scores

• e2b_create_sandboxD
  1.8/5.0
  Behavior1/5

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

  With no annotations and no output schema, the description bears the full burden of explaining the side effects of a resource-creation operation, and it reveals nothing about behavior — no mention that this likely launches a virtual sandbox, incurs cost, requires an environment, or that sandboxes auto-pause/resume (despite autoPause/autoResume params existing). The agent is fully in the dark.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  At six words, it is technically concise, but this crosses the line from conciseness into under-specification. A single simple sentence with no elaboration is not a strength when the semantic load it must carry is this heavy. This is under-specification, not effective brevity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool that provisions infrastructure with 9 configurable params, nested objects, and no annotations or output schema, an 6-word description is severely inadequate. An agent cannot understand the sandbox lifecycle, what envVars are used for, default behaviors, or the calling flow without significant external knowledge. Everything is left to inference.

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

  Parameters1/5

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

  Schema description coverage is only 11%, so the tool description must compensate for 8 underexplained parameters (envVars, autoPause, timeout, autoPauseMemory, allowInternetAccess, etc.). The only parameter the description touches is templateId, and even that is trivial. It provides zero clarity on the configuration contract the agent will need to fill to make a valid call.

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

  Purpose3/5

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

  The description states a clear verb and resource ('Create a sandbox') with a scoping hint ('from a template') that maps to the required templateId parameter. However, it is nearly tautological with the tool name and does little to distinguish the tool within the broader sibling set beyond the obvious 'create' verb. The purpose is understandable but minimally so.

  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 like e2b_connect_sandbox, e2b_pause_sandbox, or e2b_refresh_sandbox. No conditions, prerequisites, or exclusions are given. An agent would have to guess when exactly sandbox creation is appropriate from a 9-parameter config.

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

• e2b_get_templateD
  1.8/5.0
  Behavior2/5

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

  With no annotations present, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description doesn't state what happens when a template doesn't exist, whether any side effects occur, or what fields get returned. The presence of 'limit' and 'nextToken' suggests the operation may return a list of builds, but the description does not explicitly state what the return payload looks like.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The six-word description is brief but not intentionally concise — it's just under-specified, similar to calling a one-sentence paragraph about a feature 'short'. There's no structure or front-loading problem because there's barely any content to structure. Efficient at zero cost.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Completely inadequate for an API call that takes 3 parameters with no output schema and no annotations to lean on. An agent has no way to know what a template ID looks like, whether this is a 'list with pagination' or 'get one' call given limit/nextToken, or what a 'build' object is. The template/build domain model is entirely opaque.

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

  Parameters1/5

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

  Schema description coverage is 0% — all three parameters (limit, nextToken, templateId) are entirely undocumented. The description makes no effort to compensate; it fails to clarify what templateId refers to, where to find it, or how limit and nextToken fit into the 'get template' flow. The interplay between fetching a single template and paginating a collection is not resolved.

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

  Purpose2/5

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

  'Get a template and its builds' names the verb and resource with only slightly more specificity than the function name. The phrase 'and its builds' is the one useful addition, signaling this operation also retrieves related build artifacts. However, it does not distinguish this from the sibling e2b_get_template_by_alias, and lacks context on what a 'template' or 'build' represents.

  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 usage guidance is provided on when to use this tool over alternatives. The sibling tool e2b_get_template_by_alias rightfully raises the question of when to fetch by ID versus alias, yet the description is silent on this distinction.

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

• e2b_list_sandboxes_v2C
  2/5.0
  Behavior1/5

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

  There are no annotations, and the description does not disclose any behavioral aspects such as whether it is read-only, what it returns, or any side effects. It is entirely opaque.

  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 very concise, consisting of a single short sentence. However, it is so minimal that it lacks necessary substance, though it is not verbose or redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of any detail about the return value, the metadata parameter, or any examples, the description is incomplete for an agent to use it effectively. It does not explain what 'sandboxes' means in this context or what output to expect.

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

  Parameters1/5

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

  The input schema has a 'metadata' parameter with no description in the schema, and the tool description also fails to explain its purpose or format. The description adds no meaning to the parameter.

  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 action 'List' and the resource 'sandboxes', which is a specific verb and object. It distinguishes from other tools like create or delete, but provides no additional detail beyond the name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/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 over the many sibling tools. It does not mention any filtering or specific use cases, so an agent would have no idea when to choose this.

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

• e2b_delete_sandboxC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description must disclose side effects. It only says 'permanently,' which indicates non-reversibility, but doesn't mention what happens to running processes, data, or whether any cleanup occurs. It also doesn't mention if it can be called on any sandbox regardless of state.

  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 short sentence, which is concise, but it sacrifices essential detail. It could be expanded to include parameter meaning and usage while staying compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive operation with no annotations and no output schema, the description is severely incomplete. It omits parameter semantics, usage conditions, and behavioral effects, leaving the agent with insufficient information to invoke the tool safely.

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

  Parameters1/5

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

  The schema has zero descriptions, and the description does not explain the sandboxId parameter. The agent is left to infer that the parameter identifies the sandbox, but no format, validation, or guidance is given. This fails to compensate for the 0% schema coverage.

  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 action (kill/delete) and the resource (sandbox), and the word 'permanently' signals it's a destructive operation distinct from pausing or setting timeouts. This distinguishes it from siblings like e2b_pause_sandbox.

  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 on when to use this tool versus alternatives. The 'permanently' wording implies it's for final deletion, but it doesn't state when to prefer this over pausing or setting timeouts, nor any conditions like 'use after the sandbox is idle'.

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

• e2b_get_sandbox_logsC
  2.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It mentions 'structured logs' and 'pagination/filtering', which hints at return format and capabilities, but it does not explain error behavior, authentication requirements, or that this is a read-only operation. The description is too sparse to give the agent a clear picture of side effects or exceptions.

  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, concise sentence with no waste. However, conciseness is achieved at the expense of essential details. It's not bloated, but it is under-specified; the structure is acceptable but would benefit from clarity on pagination mechanics. A neutral 3 reflects this trade-off.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 6 parameters, no output schema, and no annotations, the description is wholly inadequate. It does not explain what 'structured logs' look like, how pagination works (cursor/direction semantics), the meaning of 'level' or 'search', or any constraints. An agent would have to rely entirely on the schema, which is itself incomplete, to call the tool correctly. This is a major gap.

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

  Parameters2/5

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

  Schema description coverage is 50% (level, cursor, search have descriptions; limit, direction, sandboxId do not). The description adds no parameter-level detail beyond the schema—it merely says 'pagination/filtering' without explaining that 'cursor' is a timestamp, how 'direction' interacts with pagination, or what 'limit' defaults to. It fails to compensate for the undocumented parameters, leaving the agent under-informed.

  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 action (Get) and the resource (structured logs for a sandbox), and correctly identifies the v2 endpoint. While it doesn't explicitly distinguish from siblings, it's unique among them—no other tool retrieves logs—making purpose unambiguous. A 4 is warranted because it doesn't name an alternative but the intent is clear.

  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, nor any mention of prerequisites (e.g., must have a sandbox ID). The description only states what it does, not the circumstances under which it should be invoked. With 22 sibling tools, this lack of routing information leaves the agent to infer usage.

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

• e2b_read_fileC
  2.5/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits on its own. It mentions the output encoding (UTF-8 or base64), which is useful, but it does not address potential failure modes (e.g., file not found, permission errors, reading a directory) or any side effects. The description is minimal and leaves many behavioral aspects undocumented.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely brief (one sentence) and front-loaded, but it is under-specified rather than concisely informative. It leaves out critical context about parameters, error handling, and usage scenarios, so the brevity is not paired with information density. Every word earns its place, but the description as a whole is inadequate.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 6 parameters, no output schema, and no annotations, this description is incomplete. It does not explain the role of username or accessToken, does not mention what happens on error, and does not specify whether the path is resolved relative to the sandbox's home directory (though the schema partially covers this). An agent would lack essential information to call the tool correctly in many situations.

  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?

  The description adds no parameter-specific information beyond what is already in the JSON schema. The schema covers 4 of 6 parameters with descriptions (path, port, sandboxId, accessToken), leaving username and encoding without textual explanation in either place. With 67% schema coverage, the description could have filled the gaps but does not, so it provides minimal added value for parameter understanding.

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

  Purpose4/5

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

  The description states a specific verb ('Read') and resource ('a file from a sandbox'), and it mentions the return format (UTF-8 text or base64), which clarifies the tool's core action. It is clearly distinguishable from sibling tools like e2b_list_dir (list directory) or e2b_run_command (execute command), 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?

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or typical scenarios. It simply states the function without any context about file-reading use cases or edge cases where another tool (e.g., e2b_stat) might be preferable.

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

• e2b_list_dirC
  2.9/5.0
  Behavior2/5

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

  There are no annotations, so the description must carry the full behavioral burden. It only says 'list the contents' without disclosing whether it returns just names, full metadata, whether recursion is default, or if any side effects occur (e.g., caching, pagination). For a read-only operation, not much risk exists, but the lack of any behavioral detail leaves the agent guessing about output format and defaults.

  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, non-redundant sentence that front-loads the core action. There's no fluff or repetition. However, it's so terse that it under-specifies rather than being economical; the sentence does earn its place but adds minimal value beyond the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 6 parameters and no output schema or annotations, the description is too thin. It doesn't explain how the depth parameter works, what the default depth is, or what the response structure looks like. An agent needs to infer behavior from the sibling tools and schema, which is not adequate for reliable invocation. The absence of any usage context or return format makes it incomplete.

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

  Parameters3/5

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

  Schema description coverage is high at 83%, with meaningful descriptions for path, depth, port, and sandboxId. The description itself adds no parameter context, but since the schema already documents most parameters, a baseline of 3 is appropriate. The one undocumented parameter, 'username', still lacks clarifying text, but that's a schema gap rather than a description gap.

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

  Purpose4/5

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

  The description states a clear verb and resource: 'List the contents of a directory in a sandbox.' It's direct and unambiguous, but it doesn't differentiate from sibling tools like e2b_stat or e2b_read_file, which could also inspect directory information. The tool's niche is implied but not explicitly contrasted, so it misses the full 'distinguishes from siblings' bar.

  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 on when to use this tool versus alternatives, such as when to prefer e2b_stat or e2b_read_file for inspecting files. There is no mention of the depth parameter for recursive listing or any context about typical sandbox usage. The description relies entirely on the schema for usage hints, leaving the agent to infer the tool's role among 22 siblings.

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

• e2b_make_dirC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided and no schema annotations, the description carries the full behavioral disclosure load, but it fails to explain what happens if the directory already exists, whether it's idempotent, or what happens in error cases. The only behavioral hint—'including parent directories'—hints at recursive creation but stops there.

  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?

  A single, tight sentence with no filler—the parenthetical adds real value. It's minimal and gets straight to the point.

  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?

  It's a simple operation, so the state space is small, but there's no mention of return type, error-handling contract, idempotency, or edge cases (e.g., invalid paths). The API contract is almost entirely missing.

  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?

  The `path` is central but completely undocumented, and `username` and `sandboxId` lack schema documentation; the description adds no additional context to distinguish them. With only 60% schema coverage and no parameter-level descriptions, this is a significant gap.

  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 is concise: it pairs a strong verb ('create') with a clear object ('directory in a sandbox') and includes the useful qualifier 'including parent directories,' which hints at `mkdir -p` semantics. It's clear and specific enough to avoid confusion with siblings like `e2b_list_dir` or `e2b_remove`.

  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 included use case is clear and no guidance about when to prefer it over alternatives is given, nor are edge cases discussed. The mention of parent-directory creation is a behavioral hint, but the description doesn't explicitly guide tool selection beyond the obvious.

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

• e2b_removeC
  2.9/5.0
  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. 'Remove' implies destructive action, but the description doesn't state whether removal is recursive for directories, whether it fails on non-empty directories, whether it's irreversible, or what happens if the path doesn't exist. It also doesn't mention any permission requirements or side effects. For a destructive tool with zero annotation coverage, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with no wasted words. It front-loads the core action. However, it's so brief that it sacrifices useful context, which is a trade-off. Still, for conciseness alone, it earns a 4.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive tool with no annotations, no output schema, and 5 parameters (2 required), the description is incomplete. It doesn't explain return behavior (e.g., success/failure indication), error cases, or whether the operation is recursive. An agent needs more context to call this correctly and safely, especially given the destructive nature.

  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 60%, with sandboxId and accessToken documented in the schema. The description itself adds no parameter-specific meaning beyond the schema. The path parameter is undocumented in both schema and description, and port/username are also undocumented. The description doesn't compensate for the 40% coverage gap, but the schema covers the most critical parameters (sandboxId, accessToken). 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 states a clear verb ('Remove') and resource ('a file or directory in a sandbox'), which is specific enough to distinguish it from siblings like e2b_list_dir, e2b_make_dir, e2b_move, and e2b_read_file. It doesn't explicitly name a sibling it is not, but the purpose is unambiguous.

  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 doesn't mention prerequisites (e.g., sandbox must exist, path must be valid), nor does it contrast with e2b_delete_sandbox (which removes an entire sandbox) or e2b_move (which can relocate files). An agent must infer usage from the name and schema.

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

• e2b_connect_sandboxB
  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 of behavioral disclosure. It correctly discloses that the tool will resume a paused sandbox and return fresh details, which is useful. However, it omits other potential side effects (e.g., whether timeout is reset, what happens if the sandbox doesn't exist, or if the connection itself mutates state beyond resume). The mention of resume is a positive, but more transparency is expected.

  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 conveys the core function and the key behavioral nuance (resume) without wasted words. It is front-loaded with the primary action, making it easy to scan. No redundancy exists.

  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 minimal and lacks important context for an operation that connects to and potentially resumes a sandbox. It doesn't explain what 'fresh sandbox details' means, how the timeout parameter relates to the connection, or any error scenarios. Given there is no output schema and no annotations, the description leaves several operational aspects vague, making the tool less predictable for an agent.

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

  Parameters2/5

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

  Schema description coverage is only 50% (timeout has a description, sandboxId does not). The tool description adds no parameter-specific information and does not compensate for the missing sandboxId semantics. It only mentions 'sandbox details' generally, offering no insight into how parameters influence behavior. Thus, the description fails to bridge the gap left by 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 connects to a sandbox, with explicit behavior of resuming if paused and returning fresh details. It uses a specific verb ('connect') and resource ('sandbox'), which is clear. However, it doesn't explicitly differentiate from sibling tools like e2b_refresh_sandbox or e2b_set_sandbox_timeout, though the purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives is provided. It implies usage for connecting to an existing sandbox, but there is no mention of when not to use it or how to choose among the many sibling tools (e.g., create vs. connect vs. pause). The only contextual hint is the resume behavior, but this isn't framed as a decision rule.

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

• e2b_pause_sandboxB
  3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for disclosing side effects. It states only "pause... resumed later" but does not explain whether the sandbox is snapshotted, whether running processes are affected, or what resource/state impact a paused sandbox has.

  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 one short, front-loaded sentence with no filler or repetition of the tool name. Every word contributes to the core meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a state-changing operation with no annotations and no output schema, so the behavioral context matters. A single sentence does not fully inform the agent about side effects, cold-boot differences, or failure conditions, even though the memory parameter is partially documented in the schema.

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

  Parameters2/5

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

  Schema description coverage is 50%, and the description adds no parameter-level value beyond that. The memory parameter is well explained in the input schema, but the required sandboxId lacks description in both the schema and the tool description, and the description does not compensate.

  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 gives a specific action (pause), a resource (sandbox), and an outcome (resume later). It is clear and does not get confused with destructive siblings like e2b_delete_sandbox or state queries like e2b_list_sandboxes_v2.

  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 "running sandbox" implies a prerequisite and "so it can be resumed later" implies a preservation-focused intent. However, it does not explicitly state when not to use it or how it compares with related operations like setting a timeout or deleting the sandbox.

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

• e2b_refresh_sandboxB
  3/5.0
  Behavior3/5

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

  With no annotations available, the description carries the full burden. It does disclose the core behavioral effect: extending the sandbox's time to live. However, it leaves key behavior implicit, such as what happens when duration is omitted and whether the operation has side effects beyond refreshing the TTL.

  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 one short sentence that gets straight to the purpose and effect. No waste and the core idea is 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?

  For a 2-parameter tool with no annotations and no output schema, the description is sparse. It omits the distinction from e2b_set_sandbox_timeout, doesn't explain what happens if duration is omitted, and provides no sense of expected behavior when the sandbox is already expired.

  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% with sandboxId undocumented, and the description adds little beyond the schema. 'Extending its time to live' maps to the duration parameter, but the description does not clarify the exact relationship between duration, the refresh action, or any default behavior for omitted duration.

  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 clear verb-resource pair ('Refresh a sandbox') and states the primary effect ('extending its time to live'). However, it does not explicitly distinguish itself from the sibling e2b_set_sandbox_timeout, which may cover an overlapping 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 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 instead of e2b_set_sandbox_timeout or any other alternative. The description states only what the tool does, not the context or conditions that should prompt an agent to call it.

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

• e2b_moveB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral impact. It only says 'Move or rename' which implies a mutating filesystem operation, but it doesn't mention whether it overwrites destinations, error behavior (e.g., if source doesn't exist), permission requirements, or side effects. This is minimal for a mutation tool and leaves the agent guessing about safety and failure modes.

  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-formed sentence with no redundant words. It states the core operation and resource clearly. It is appropriately front-loaded and concise, ideal for quick comprehension.

  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 that there is no output schema, no annotations, and a moderate number of parameters (6, with 3 required), the description is too sparse. It does not specify return values, error handling, overwrite behavior, or any operational caveats. An agent would need to infer many critical details to use the tool reliably.

  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% (sandboxId, accessToken, port have descriptions; source, destination, username do not). The description does not explain what source and destination represent or their format. It only hints at the action, not the parameter details. The description adds no extra meaning beyond the schema, so it fails to compensate for the missing parameter documentation.

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

  Purpose5/5

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

  The description states a clear verb ('Move or rename') and a specific resource ('a file/directory in a sandbox'). It naturally distinguishes from sibling tools like list, create, remove, or read, so an agent can tell what operation it performs without ambiguity.

  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 gives no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or exclusions. For example, it doesn't clarify whether this should be used for moving within the sandbox vs. uploading/downloading, or what happens with overwrites. An agent has to infer usage from the tool name and parameter names.

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

• e2b_statB
  3.1/5.0
  Behavior1/5

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

  No annotations provided, so description must disclose behavioral traits. It does not mention side effects, permissions, error behavior, or response format. Only states the basic purpose.

  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 concise sentence, no fluff.

  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?

  No output schema, so description should explain return value. It says 'metadata' but does not specify fields or format. Leaves the agent guessing about the response.

  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 provides some descriptions for connection parameters, but description adds little beyond saying 'in a sandbox'. Does not clarify path semantics (e.g., relative vs absolute) or the meaning of sandboxId beyond schema's minimal 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?

  Clearly states the action (get), resource (metadata of a file/directory), and context (in a sandbox). Distinguishes from sibling tools like list_dir or read_file.

  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?

  No explicit guidance on when to use vs alternatives, but the description implies it is for metadata rather than content. Does not specify conditions or exclusions.

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

• e2b_run_commandB
  3.2/5.0
  Behavior3/5

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

  The description discloses the wait-up-to-timeoutMs behavior, the collected outputs (stdout/stderr/exit status), and the underlying streaming RPC. However, with no annotations, it does not warn about potential side effects, permission requirements, or behavior on timeout/non-zero exit. The transparency is partial and lacks caveats that could affect the agent's decision to call it.

  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 two sentences, front-loading the core action and output, with the second sentence adding a useful technical detail about the RPC. It is succinct, avoids redundancy, and includes no filler. The structure is efficient, though slightly under-specified for the parameter complexity.

  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 9 parameters, no output schema, and no annotations, the description alone is insufficient for correct invocation in all cases. It does not explain error handling, how to construct argument arrays, or the meaning of cwd/envs/username. It also omits guidance on when to use this vs interactive process tools, leaving gaps that could lead to misusage.

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

  Parameters2/5

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

  Schema description coverage is 67%, with several parameters (cmd, args, port, sandboxId, timeoutMs, accessToken) already having descriptions, but cwd, envs, and username lack schema descriptions. The tool description does not add any clarification for those undocumented parameters and only indirectly mentions timeoutMs. It adds no value beyond the schema, so parameters like envs and username remain ambiguous for the agent.

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

  Purpose5/5

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

  The description states a specific verb ('Run') and resource ('command in a sandbox'), and explicitly describes the wait-and-collect behavior and return values (stdout/stderr/exit status). This clearly differentiates it from sibling tools like e2b_list_dir (directory listing) and e2b_send_stdin (interactive input), which serve different purposes.

  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 conditions for choosing this over e2b_send_stdin for interactive processes or e2b_list_processes for process monitoring. The description only states what it does, leaving decision-making to the agent with no explicit exclusions or prerequisites.

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

• e2b_resize_ptyB
  3.3/5.0
  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 core action and selection mechanism, but it does not disclose side effects, permissions, return behavior, or failure modes. The note about inferring the shape from process.PTY.Size and verifying docs signals uncertainty rather than providing behavioral clarity.

  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 short and front-loaded, with the core operation stated first. The second sentence is a useful caveat but could be tighter; overall there is no filler or redundant repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 parameters, no output schema, no annotations, and related process-control siblings, the description is incomplete. It omits required sandboxId, selection constraints, return information, and error behavior. The 'verify docs' note is not a substitute for describing how the tool behaves.

  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 low (38%), so the description must compensate. It adds meaning by explaining that pid/tag select the process and cols/rows are the dimensions to resize. However, it does not explain the role of username, port, or accessToken, nor whether pid and tag are mutually exclusive or one is required.

  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 names a specific operation ('Resize the PTY'), a target ('a running process'), the selectors ('pid or tag'), and the relevant fields ('cols/rows'). Among the sibling tools, none offer PTY resizing, so the purpose is unmistakable and well-differentiated.

  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 makes the use case clear implicitly: use this when a running process's terminal dimensions need changing. However, it does not explicitly state when not to use it, whether a PTY must already exist, or which sibling tools are alternatives for interacting with a process.

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

• e2b_close_stdinB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It does clearly say that the operation sends EOF, which is meaningful. It does not, however, disclose potential side effects such as the process exiting or how the operation behaves if stdin is already closed.

  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 the key action and target front-loaded. Every part earns its place, and there is no redundant or filler wording.

  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 six parameters, no annotations, no output schema, and partial schema descriptions, the tool definition is not complete enough. It omits important calling context such as whether pid or tag is required, mutual exclusivity, authentication considerations, and expected success/error 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 description adds value by clarifying that 'pid or tag' selects the process, which is not clear from the schema alone. However, schema coverage is only 50%, and the description does not explain username, accessToken, or the relationship/optionality between pid and tag.

  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 action ('Close stdin (send EOF)') and the target resource ('non-PTY process running in a sandbox'), with a selection method ('by pid or tag'). It is specific and understandable, though it does not explicitly name sibling alternatives.

  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 provides useful context about when this tool applies: it is for non-PTY processes and selects by pid or tag. However, it does not explicitly contrast with related tools like e2b_send_stdin or state when not to use it, so usage guidance is mostly implied.

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

• e2b_get_template_by_aliasB
  3.4/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 behavioral burden. It discloses that the tool performs an existence check and returns a template id, but it does not describe what happens when the alias is not found, what the full response shape is, or any authorization 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?

  The description is a single, efficient sentence with no wasted words. It front-loads the core behavior and result, making it easy for an agent to parse quickly.

  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 lookup, the description is mostly adequate, but since there is no output schema, it should clarify the return format and the behavior when the template does not exist. The current wording leaves ambiguity about whether a missing alias produces an error or an empty result.

  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 only defines alias as a string with no description, so the tool description must compensate. It adds meaningful context by clarifying that the parameter is a template alias/name, which is sufficient for this single-parameter tool, though no format or example is provided.

  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 a specific operation: check existence of a template by alias/name and retrieve its id. It identifies the resource and action well, though it does not explicitly contrast itself with the sibling e2b_get_template.

  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 e2b_get_template. The intended use is implied by the tool name, but the description does not state conditions, exclusions, or when a different tool would be more appropriate.

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

• e2b_list_processesB
  3.4/5.0
  Behavior3/5

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

  The description implies a read-only operation by using 'list', but it does not explicitly state side effects, whether it is non-mutating, or what it returns (e.g., process details, format). Since no annotations are present, the description should cover behavioral aspects, but it only provides basic functionality.

  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 directly states the tool's purpose without extraneous information. It is well-structured and easy to parse.

  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 simplicity of the tool, the description covers the basic purpose but lacks essential context such as output format, potential errors, or parameter details. It does not fully equip an agent to use the tool correctly, especially with incomplete parameter descriptions.

  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?

  The schema includes parameters like sandboxId and username without descriptions, and the tool description adds no additional meaning. While port and accessToken have descriptions, the purpose of username and the role of sandboxId are not explained, leaving ambiguity. The tool description does not clarify parameter usage.

  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 function: 'List running processes started via envd in a sandbox.' It is specific about the resource (processes) and the context (envd in a sandbox), allowing it to be distinguished from sibling tools like e2b_list_dir or e2b_run_command.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  The description does not provide any guidance on when to use this tool versus alternatives. It lacks context such as 'use this to check running processes' or how it compares to running 'ps' via e2b_run_command. No usage 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.

• e2b_send_signalA
  3.6/5.0
  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 merely says 'send signal' without explaining that sending SIGKILL is forceful and irreversible, that the process will be terminated, or that the operation requires an active sandbox and appropriate permissions. This is a significant gap for a potentially destructive action.

  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 filler. It front-loads the action and the key selection details, making it immediately scannable and concise.

  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 7 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the return value/error behavior, whether pid and tag are mutually exclusive or both optional, the purpose of username and accessToken, or any prerequisites. An agent would be uncertain how to structure a valid call.

  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 only 43% (3 of 7 parameters documented). The description adds meaningful context by clarifying that pid or tag are selection mechanisms, and it reiterates the signal enum values. It does not, however, explain the relationship between pid and tag (e.g., whether one is required or how they interact). This partial compensation raises the score above baseline.

  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 SIGTERM or SIGKILL), the target (a process in a sandbox), and the selection mechanism (by pid or tag). It effectively distinguishes this from sibling tools like e2b_list_processes (which lists) and e2b_send_stdin (which sends input).

  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 compare with alternatives like e2b_list_processes or e2b_send_stdin, nor does it state when to use this tool versus others. The intended use case is implied by the purpose, but there is no explicit guidance on exclusions 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.

• e2b_send_stdinA
  3.6/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full burden. It discloses a schema-reliability caveat ('field names are inferred... check the E2B docs'), which is useful. However, it does not describe effects on the process, whether a newline is appended, what happens if the process is not found, or success/error behavior.

  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 core functionality is front-loaded in a single concise sentence, with a helpful caveat appended as a second sentence. No wasted words, though the caveat could be slightly shorter.

  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 7-parameter tool with no annotations, no output schema, and a schema-reliability warning, the description is thin. It lacks guidance on how the tool behaves on success/failure, how to choose pid vs tag, and what the response looks like. The caveat helps, but the overall picture 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?

  Schema description coverage is 57%, so the schema provides some parameter descriptions (port, input, sandboxId, accessToken). The description adds semantic context that pid and tag are alternative selectors, but does not clarify their mutual exclusivity or the roles of username/accessToken. Overall it adds some value but does not compensate for the undocumented parameters.

  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 ('send'), the resource ('stdin of a running process'), and the selection mechanism ('by pid or tag'). This is specific enough to distinguish it from siblings like e2b_send_signal and e2b_close_stdin without needing to inspect their schemas.

  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?

  It implies the tool is for interacting with running processes by pid or tag, but does not explicitly state when to use it over alternatives such as e2b_close_stdin for EOF or e2b_send_signal for signals. No conditions or exclusions are provided, leaving the agent to infer the right context.

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

• e2b_upload_fileA
  3.7/5.0
  Behavior4/5

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

  Explicitly discloses that it creates parent directories and overwrites existing files, which are key side effects. It does not mention authentication or error scenarios, but with no annotations, 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 a single, concise sentence that communicates the core action and key behaviors without redundancy, making it easy to parse.

  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?

  While it covers the main action and important behaviors, it does not mention prerequisites (e.g., sandbox existence), error handling, or whether the operation is idempotent. Given the lack of an output schema, this is acceptable but leaves some 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 provides descriptions for most parameters (path, port, content, sandboxId, accessToken) covering 71% coverage. The description adds behavioral context (directory creation, overwrite) but does not clarify ambiguous parameters like encoding or username beyond the schema's own 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?

  Clearly states it uploads/writes a file into a sandbox, creating parent directories and overwriting existing files. This distinguishes it from sibling tools like e2b_read_file or e2b_list_dir.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, it does not mention when to prefer this over e2b_read_file or other file operations, leaving the agent to infer usage from context.

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

• e2b_set_sandbox_timeoutA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It delivers two key insights beyond the tool name: the timeout is relative ('N seconds from now') not absolute, and it overwrites any prior TTL. These are genuinely useful for an agent reasoning about idempotency and repeated calls. Could have added what happens on expiry but is robust for the tool's simplicity.

  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 — no fluff. The core semantic ('N seconds from now') and the side-effect ('overwrites previous TTL') are each given a single sentence. Nothing is missing, nothing is extra.

  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 only 2 parameters, no nested objects, and no output schema, the description covers the essentials. It could briefly mention edge cases like timeout=0 (disable expiry?) or negative values (though schema min=0 handles that), but these are minor given the tool's simplicity and the sibling context.

  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 50% — 'timeout' benefits from an inline schema description, while 'sandboxId' has none. The main description reinforces that 'timeout' is relative ('N seconds from now') and clarifies the overwrite semantics, adding a bit beyond the schema. However, 'sandboxId' semantics are left entirely to inference, and the description doesn't fill that 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 ('Set') + resource ('sandbox timeout') and clarifies the exact behavioral semantics: 'it will expire N seconds from now.' This clearly distinguishes it from sibling tools (e.g., pause, refresh, delete) which deal with other lifecycle aspects. The scope is unmistakable even without naming a sibling.

  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?

  While no explicit 'use this instead of X' is provided, the description strongly implies the usage context: call this when you need to set or overwrite a sandbox's expiration TTL. The clarification that it 'overwrites any previous TTL' signals the idempotent/replacement nature. Loses a point for not explicitly routing away from alternatives like e2b_pause_sandbox or e2b_refresh_sandbox, but the intent is clear.

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