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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, but the description adds substantial behavior beyond them: a 64 MiB combined-data cap, no additional extraction/meshing, preservation of surface colours/quality evidence/display-only warnings, the fragment-preserving viewer_url handoff, no HTML embedding in chat, and the async pending operation_id pattern. The only gap is that it doesn't say what the workspace response contains beyond viewer_url, which the output schema likely covers.

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, then constraints, then the async and browser-handoff rules — a logical order with almost no filler. It is long and a couple of clauses (e.g. the awaiting_decision rationale) are dense, but each carries operational meaning rather than restating annotations or 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?

Given an output schema, annotations covering safety, and only two parameters, the description covers everything an agent needs: input provenance, size/scope limits, preparation prerequisites, async continuation, and how to present the result. Nothing material is left to inference.

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 50% (title undocumented, artifact_ids documented), and the description compensates well by specifying provenance ('same mesh job'), the exact accepted artifact types (engineering_view/mesh_section) and explicit exclusions (mesh_cgns, PNG, HTML IDs), plus the 2–8 range. Only the title parameter's role is left to the schema/default.

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 — combining 2–8 prepared mesh surface/section view artifact IDs from one mesh job into an interactive browser workspace — and implicitly separates itself from view_mesh/view_mesh_section (which prepare artifacts) and assemble_simulation_viewer (different domain). An agent can tell what this produces (a viewer_url workspace) without opening the schema.

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?

Explicitly routes preparation: surfaces via view_mesh, true volume-cell cuts via view_mesh_section, and requires pending operations to be completed first. It also gives a negative rule (don't create unrequested sections just to assemble) and a recovery path (get_operation at retry_after_seconds, don't resubmit), which is unusually complete when-to/when-not guidance.

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