production.mesh_candidate_create

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

Annotations already declare readOnly=false, destructive=false, openWorld=false, so the safety profile is covered; the description adds genuinely new information — the resulting copy is excluded from render, the call requires a prior checkpoint and asset guard, and per-dependency preservation is reported. There is mild tension between the stated reuse behavior and idempotentHint=false, but 'same source state' is a conditional rather than a strict input-equality guarantee, so it is not a flat contradiction.

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?

Two tight sentences with the artifact definition front-loaded and the reuse semantics appended. Dense but no filler; it does lean on internal jargon ('asset guard', 'preservation per dependency') that an unfamiliar agent must infer.

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?

An output schema exists, so return values needn't be spelled out. But for a mutation tool with two required, entirely undocumented parameters and an unnamed prerequisite ('asset guard'), the description should do more to make the call executable on the first attempt.

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 0% and all three parameters (object_name, source_fingerprint, operation_id) are bare. The description never explains what a source fingerprint is, how to compute it, or what operation_id is used for, so it fails to compensate for the schema gap.

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+resource pair ('Create a candidate mesh') and clarifies what the artifact actually contains: an object plus a mesh copy hidden from render. An agent knows what it gets, but nothing distinguishes this from sibling candidate creators like character_create_candidate or retopology_create_candidate, so the scope is only partly bounded.

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?

'after checkpoint and asset guard' encodes an ordering precondition, which is real guidance. However there is no explicit when-not, no named alternative, and the reuse rule ('Reuses the existing candidate of the same source state') describes behavior rather than when an agent should or should not call it.

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