Start a game prop from a brief

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

Annotations declare openWorldHint=true and readOnlyHint=false, but the description adds substantial behavioral value beyond those: it discloses the credit cost profile up front ('SPENDS IMAGE CREDITS ONLY' and not 3D credits), and reveals the transformation behavior (loose brief → reconstruction-grade prompt). No contradiction with annotations. It could go further on details like generation time or failure modes, which keeps it from a 5.

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?

Three dense sentences with zero filler. The most critical operational fact (credit spending) is front-loaded in all caps, followed by the workflow and the design rationale. Every sentence earns its place; the structure mirrors the tool's purpose as an entry point.

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 tool with 9 parameters, a nested object, and no output schema, the description covers the workflow and handoff chain well but leaves parameter semantics to the schema, which is only 44% covered. The output shape ('candidate reference images') is hinted but not detailed. Given the strong sibling differentiation and workflow clarity, this is mostly complete with minor gaps around parameters and return details.

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 only 44%, and the description does not compensate by explaining individual parameters — it focuses on workflow. The schema itself carries descriptions for name, description, and dimensionsMeters, but parameters like category, artDirection, gameplayPurpose, waitSeconds, and targetTriangleCount have no descriptions and are not touched in the tool description. This is a real gap given the low coverage.

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-resource pair ('takes a loose brief, builds a reconstruction-grade prompt, and generates N candidate reference images') and explicitly frames itself as a 'convenience entry point' that deliberately stops short of 3D generation. It names the exact sibling tools it hands off to (select_reference, create_3d_asset), making the differentiation unambiguous without needing to open their schemas.

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?

Provides an explicit sequential workflow: 'look at the returned candidates, call select_reference with your choice, then create_3d_asset.' It also states when NOT to use it indirectly by declaring that it stops at reference generation and spends no 3D credits — the agent knows this is the reference-stage tool, not the modeling stage. The rationale ('so art direction stays with you') gives clear context for selection.

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