mesh_manage

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions that deform_mesh 'inspects and deforms an existing mesh' (implying mutation), and generate_surface_mesh 'generates' new geometry, but it does not specify whether operations are destructive, reversible, or require save_path to persist. It also omits any permission or side-effect details, leaving safety and side-effect behavior under-specified.

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?

The description is well-structured with an introductory phrase, a bulleted list of operations, and a call-shape note. It is front-loaded with the overall purpose and each line serves a distinct role. While lengthy, it is organized and avoids redundancy.

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 four operations and many parameters, the description is moderately complete. It covers the existence and purpose of each op and the call shape, but it omits return values (partially covered by the output schema), error handling, and path resolution details. Given the tool's complexity, more context on expected inputs and outputs would improve completeness.

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 0%, but the description compensates by listing each operation's parameters with defaults. However, it does not explain parameter formats or expected values (e.g., how vertices should be structured, what primitive types are valid). The description provides a basic map but lacks depth for correct invocation.

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?

The description clearly states the tool's purpose: procedural mesh synthesis, deformation, and primitive generation. It enumerates four specific operations with brief one-line descriptions, making it distinct from generic manage tools. However, it does not explicitly contrast with sibling tools like geometry_manage, leaving some ambiguity about when this is the right choice.

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?

The description provides no guidance on when to use this tool versus alternatives. It explains the call shape (canonical and flat op parameters) but does not mention scenarios where mesh_manage is preferred over other tools or when it is not appropriate. This leaves the agent to infer usage context.

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