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

Goes well beyond the annotations by describing the branching outcomes: a passing build goes live immediately with `live: true` and a play URL, a failing one returns `live: false` with `waiting` reasons, and some uploads are held for manual arcade review. It also discloses the extra returned metadata (file count, size, engine, SDK detection) and the no-index zip fallback flow. The only undisclosed trait is re-upload/idempotency behavior, which is minor.

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?

Front-loaded with the core action and accepted formats, then details the result branches. Five sentences is on the long side, but each conveys actionable information about outcomes rather than restating the schema.

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?

There is no output schema, so the description carries the return-value burden and does so thoroughly: live flag, play URL, waiting reasons, review queue, and file metadata. Combined with the fully documented input schema, an agent has everything needed to call it and interpret the response.

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 100%, so all six parameters are already documented, including entry, threads, and the 24 MB limit. The description adds only a little beyond that — the notion that a no-index zip triggers a prompt answered via set_entry, which relates to the `entry` parameter. Baseline 3 is appropriate since the schema carries the load.

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

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

States a specific verb and resource — send the browser build for a version and publish it — plus the accepted formats (single HTML or zip with index.html at root). It is clearly distinguishable from siblings like set_entry, set_cover, and create_experience.

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?

Explains the preconditions implicitly by naming the enclosing flow (version from create_experience or start_version in the schema) and routes the agent to set_entry when the zip lacks an index.html. It stops short of stating explicit exclusions or when another tool should be preferred for the initial upload.

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