repair_mesh

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

Annotations already flag destructiveHint=true, but the description goes well beyond them by enumerating exactly what is mutated (vertices welded, degenerate faces/edges dissolved, loose geometry deleted, holes filled, normals flipped, empty slots stripped and their faces reassigned). It also discloses a key limitation the annotations cannot convey: non-manifold edges of 3+ faces are reported but "not repaired."

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 effect, then parameter semantics, then the return payload and the workflow hint — no filler sentences. It is dense and runs long as a single compounded sentence, but every clause carries parameter or behavior information that the structured fields lack.

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 no output schema, the description still documents the returned `removed` counters and before/after counts (open_edges, non_manifold_edges, doubles, zero_faces, junk_vertices), covers all eight parameters, and states the use case. Nothing an agent needs to invoke it correctly is missing.

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%, so the description carries the full load and does: `weld` is expressed in metres with default-following and skip semantics, `hole_sides` 0 means any size, `fill_holes=false` skips the step, and the remaining booleans are mapped to their effects. This is a strong compensation for otherwise undocumented parameters.

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 ("Heal one mesh in place") and enumerates the full composite pipeline, which distinguishes it from single-operation siblings like `weld`, `subdivide`, or `boolean`. An agent can tell this is a multi-step repair pass rather than a single edit without opening the schema.

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 one concrete when-to-use trigger: "Run it before boolean on parts you cut or joined by hand," which ties the tool to a clear workflow stage. It does not name alternative repair tools or state when not to use it, so it falls short of the explicit alternatives-plus-exclusions bar.

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