Run JavaScript in an isolated Pi QuickJS sandbox. Discover native provider functions with search, then call await tools.<name>(args). Use return, text() or console.log() for output. Promise.all supports parallel requests. Only final output reaches the client. No filesystem, network, Node APIs, modules or timers. Credentials stay on the host. At most 20 provider calls; 64 MiB heap; default deadline 60 seconds. Results are raw provider JSON. Async jobs return IDs: retrieve their status in a later call. No automatic retries. Calls already made are not undone on failure. State is not persisted between executions.

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

The description goes far beyond the annotations by disclosing concrete limits (20 provider calls, 64 MiB heap, 60s default deadline), how output surfaces (return, text(), console.log; only final output reaches the client), and failure semantics (no retries, calls not undone, state not persisted). These details are consistent with destructiveHint=true and openWorldHint=true rather than contradicting them.

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 dense but well front-loaded, with capabilities stated first and constraints after. Every sentence carries a distinct rule, although the stacked constraint sentences read as a run-on list rather than grouped sections.

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

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

For a three-parameter execution tool with no output schema, it covers execution model, output mechanism, resource limits, async job IDs, retry and rollback behavior, and state persistence. An agent has everything it needs to call it correctly and interpret results.

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

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

Schema coverage is only 33%, so the description compensates: it explains how 'code' is written (await tools.<name>(args), Promise.all, return/text()) and supplies the default deadline of 60 seconds for 'timeout_ms', which the schema leaves undocumented. 'large_result_mode' is covered by the schema itself, so no gap remains there.

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?

Tautological: description restates name/title.

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

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

It prescribes the workflow: use search to discover provider functions, then invoke them inside the code. It also implies when not to expect certain behavior (no filesystem, network, modules, timers), but it never states explicit alternatives or exclusions versus 'search', such as when to use search instead of executing code.

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