e2b_connect_sandbox

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.

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.

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.

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.

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.

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.