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

Annotations already declare this is a non-read-only, closed-world, idempotent operation, so the safety profile is covered. The description adds useful spec detail (USDZ 64-byte alignment, per-platform target runtimes) but omits material behavior: whether compiling an inline script executes arbitrary JS, whether the binary is returned or only written when outputPath is given, and what happens on compile failure.

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?

A single front-loaded sentence that puts the inputs and outputs first, then the platform targets. The trailing platform enumeration is dense but informative rather than filler; minor cost is that the sentence is long enough to read as a run-on.

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 4-parameter, all-optional tool with no output schema, the description covers inputs, output formats, and target runtimes well. The main residual gap is return behavior — whether the .glb/.usdz bytes come back in the response or only land at outputPath — which matters because there is no output schema to answer it.

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%, including the enum for format and the code-vs-inputPath alternative, so the schema already carries parameter meaning. The description contributes nothing parameter-specific (no note on how format is inferred from outputPath, no precedence rules when both code and inputPath are supplied), leaving this at the baseline.

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 concrete verb (compile) and the exact resources involved: Three.js script, HTML document, or .glb input, producing .glb or .usdz output. The target runtimes (Filament/SceneCore, RealityKit/Quick Look, Web) make it unmistakable versus siblings three_live_validate, three_live_render, and three_live_sim, which imply checking, previewing, and simulating rather than converting.

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?

Usage is only implied by the conversion framing; there is no explicit 'use this when you need a shipping asset, use validate to check first' routing. The description never names an alternative or a precondition (e.g., validate the scene before compiling), so the agent must infer when to pick this over three_live_validate or three_live_render.

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

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

Annotations only declare readOnlyHint=false, idempotentHint=true and openWorldHint=false; the description adds real value by disclosing the zero-GPU headless execution model, the base64 return channel and the accompanying spatial diagnostics. However, with readOnlyHint=false it never clarifies when a write occurs (only via outputPath?) or what the diagnostics contain, leaving the mutation profile implied.

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 outputs in a single dense but readable sentence, followed by the return-value sentence. No filler, though the first sentence packs several output modes into one long clause chain that takes effort to parse.

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?

With 12 optional parameters and no output schema, the description does the necessary work by explaining the return value (base64 image plus spatial diagnostics) and the available output artifacts. Minor gaps remain around file-writing behavior via outputPath and what the spatial diagnostics entail, but an agent can call this correctly from the description plus schema.

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% with per-parameter descriptions and enum values, so the schema already carries full parameter meaning. The description only hints at the output-mode mapping (view modes, frames for temporal capture) without adding syntax or defaults beyond the schema, so baseline 3 applies.

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 (render) and precise resource (Three.js script, HTML document, or .glb) plus the concrete output modalities (4-up contact sheet, single viewport, filmstrip, turntable GIF). This distinguishes it cleanly from the sibling tools three_live_validate, three_live_convert and three_live_sim, which do not produce rendered images.

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?

The description implies the usage context (returns base64 directly to vision-capable agents, useful for visual inspection with spatial diagnostics) but never says when to choose this over three_live_validate or three_live_sim, nor any preconditions such as validating a script first. Usage is inferable, not stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and openWorldHint=false; the description adds that execution is deterministic and ticked at 60 Hz, which is genuinely useful behavioral context. It omits notable side effects the schema reveals, such as writing a filmstrip file to disk via outputStripPath, and says nothing about runtime cost or failure modes for a physics simulation. Given annotation coverage, this is adequate but not rich.

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?

It is a single front-loaded sentence with no filler sentences, which is good. However, '60 Hz' appears twice in near-redundant form ('60 Hz xr-live-sim rigid-body physics ... deterministically at 60 Hz'), and the dense keyword pile of feature nouns is harder to parse than a structured list would be.

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 7-parameter tool with no required inputs and no output schema, the description should clarify what the caller gets back (simulation results vs. filmstrip image blocks), what happens when neither code nor inputPath is supplied, and that file output is a side effect. None of that is covered, so the description is complete on 'what it simulates' but thin on operational behavior.

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 100%, so every parameter is already documented in the schema, including the action event types and the code/inputPath alternative. The description adds no parameter-level meaning beyond what the schema states, so the baseline of 3 applies.

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 leads with a specific verb ('Simulate') and enumerates the concrete domains covered: KHR_interactivity graphs, orbit/explode traits, rigid-body physics, character controllers, steering agents, hit zones, and objectives. An agent knows what the tool produces (a deterministic 60 Hz simulation). It does not, however, distinguish this from siblings like three_live_render or three_live_validate, so the differentiation requirement for a 5 is unmet.

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?

There is no explicit when-to-use guidance, no statement of when NOT to use it, and no mention of the sibling tools (validate/render/convert) that an agent would need to choose between. Usage is only implied by the verb 'Simulate', leaving the selection decision to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered; the description adds real value by disclosing the five specific check categories and the TL100-TL402 rule range, telling the agent what class of problems will be detected. It stops short of describing what diagnostics are emitted (severity levels, error vs warning) or whether validation halts on the first failure.

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?

A single front-loaded sentence: verb, then input formats, then the analysis performed. No filler, no restating of the name, and the most decision-relevant information (what it accepts) comes first.

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?

With 5 optional parameters, no required fields, and no output schema, the description gives the agent enough to know what to supply and what kind of analysis runs. The remaining gap is return-value shape: since no output schema exists, mentioning that it returns coded diagnostics would make it fully self-sufficient.

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 100%, so all five parameters (code, inputPath, cameraFov, cameraPosition, cameraTarget) are documented in the schema. The description adds no meaning beyond that — it references camera frustum checking but never connects it to the camera override parameters, nor clarifies the code/inputPath precedence beyond what the schema already states.

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?

Uses a specific verb ("Validate") plus three enumerated input formats (.js script, HTML document with <three-live>/<xr-live>, .glb binary) and names the concrete analysis performed (spatial, camera frustum, grounding, AABB collision, lighting linter TL100-TL402). This is clearly distinguishable from the render/convert/sim siblings, which would not be described as running a linter with rule codes.

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?

The description implies a pre-flight check workflow by framing the tool as a validator/linter, but never states when to call it versus three_live_render, three_live_convert, or three_live_sim. There are no explicit exclusions and no guidance on whether validation is a prerequisite before rendering.

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