complete_mesh

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

With annotations declaring destructiveHint=true, readOnlyHint=false, and idempotentHint=false, the safety profile is already covered. The description adds real value beyond that: it warns credits are spent, discloses the async pattern (returns task_id immediately rather than the result), and routes to wait_for_task. It does not say whether the source segment_mesh task is altered or how much credit is consumed by default.

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, front-loaded with what the tool does and followed by the cost/async caveat and next step. Every clause earns its place with no filler.

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-value detail is unnecessary, and annotations cover the destructive/async profile. The description supplies the credit-spend warning and the wait_for_task hand-off, leaving only minor gaps around which completion mode to choose and whether the source task is mutated.

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%, so every parameter already carries its own description including the credit costs in the completion_mode enum. The only added meaning is 'optionally only the named ones' for part_names, which the schema already conveys. Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Fill in the parts of a segment_mesh task.' It ties the tool to the segment_mesh sibling whose task_id it consumes, so an agent can place it in the pipeline without opening the schema. It stops short of explicitly distinguishing itself from smart_segment, so a 4 rather than 5.

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?

'optionally only the named ones' signals the part_names use case, and 'then call wait_for_task' gives the essential follow-up step, which is strong workflow guidance. However, it never states when to prefer ai_completion vs quick_cap beyond the inline enum text, and offers no explicit exclusions.

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