render_build

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

With no annotations, the description carries the full burden and does disclose useful traits: it produces a file and "Returns the file path," and it requires a WebGPU-capable browser. It does not say whether the output file is overwritten, whether rendering is slow/expensive, or whether it replays ingestion or only existing data.

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 purpose is front-loaded in the first clause, then the visual sequence, then the return value and the environment requirement. Dense but every sentence carries information; the middle replayed-build sentence is long but justified by the tool's unusual visual semantics.

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?

Return value is stated (file path) and the browser prerequisite is called out, which covers the two things an agent most needs for a render tool with no output schema. Gaps remain around the site_id parameter, cost/runtime, and how it relates to render_site, making it adequate but not complete.

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 0% and the sole required parameter site_id is never mentioned in the description, so nothing is added beyond the bare schema field name. The agent must infer that site_id comes from list_sites and what a 'site' means here.

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?

Specific verb+resource: "Render the graph construction process as a self-contained WebGPU viewer," with concrete detail on what is visualized (chapter rings, evidence edges, per-dimension waves, HUD counters). It does distinguish itself from the query siblings by scoping itself to human inspection, but it never names or contrasts with render_site, the closest sibling.

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 frames itself as the "human inspection path" and states that "AI-facing queries stay on search/neighbors/ask," which is real when-not-this-tool guidance. The obvious remaining alternative, render_site, is not mentioned, so the agent must infer which renderer to pick.

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