create_curve

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, required prerequisites (e.g., having an active scene), what happens to existing objects, return values, or any limitations. The list of types gives no insight into the tool's behavior.

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?

While the text is extremely short, it is under-specified rather than concise. It lacks any structural elements like an imperative verb, example, or lead statement about the tool's purpose. The minimalism is not effective because it omits essential information, similar to the 'process' example.

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 curve creation tool with three parameters and an output schema, the description is grossly incomplete. It does not explain what a curve is, how to define its geometry (e.g., control points), what the different types mean for the resulting object, or how the tool interacts with the current scene. None of the information an agent needs to call this correctly is present.

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% per the metrics, and the description's only parameter mention is the 'type' values, which merely repeats the schema's default and enum-like possibilities. It does not explain what each curve type means, how they differ, or how 'name' and 'location' influence the result. The description adds no meaningful semantics beyond the bare parameter list.

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 'type: BEZIER, NURBS, PATH' merely lists possible values for the 'type' parameter without stating that the tool creates a curve. It does not communicate the tool's primary action or resource, relying on the name to imply purpose. It is close to a tautology since it only restates parameter options.

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?

There is no guidance on when to use this tool versus the many sibling creation tools or how it fits into a workflow. No context is provided about scenarios where creating a curve is appropriate or about alternatives like create_object or convert_to_mesh. The description offers zero usage direction.

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