Remesh 3D Model

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, non-idempotent, open-world), so the description doesn't need to restate safety. It adds genuinely new behavioral context the annotations cannot express: a 5-credit cost, positioned against the 1-credit alternatives. It does not explain the async/task-based nature of the operation, which is the remaining behavioral gap.

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 sentences plus one example, with zero filler. The core action is front-loaded, the cost and routing guidance follow, and the example is placed last where an agent that already understands the tool can skip it.

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 13-parameter tool with a full-coverage schema, an output schema, and annotations, the description covers purpose, cost, and alternatives well. The one real gap is source selection: the schema marks nothing required, so the description never states that a model source (input_task_id or model_url) must be supplied and that the two are alternatives.

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?

With 100% schema description coverage, the schema already defines every parameter, so the baseline would be 3. The worked example adds value beyond the schema by showing a realistic, valid combination (input_task_id + topology + target_polycount + target_formats) that demonstrates how the source and output-shaping parameters are used together.

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 ("Remesh an existing model") and immediately narrows scope to the two things it changes: polygon count or topology. It also explicitly names the sibling tools it is not (meshy_convert, meshy_resize), so an agent can route correctly without opening 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?

Gives explicit when-not guidance with named alternatives and the discriminating condition: format-only changes go to meshy_convert, scaling goes to meshy_resize. Costs are attached to each option, which makes the routing decision actionable rather than merely descriptive.

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