rhino_create_surface_from_points

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

Annotations provide only false hints (readOnlyHint, destructiveHint, idempotentHint all false), so the description carries the full burden of behavioral disclosure. It merely states that a surface is created, without mentioning that it creates a new object, does not modify existing geometry, or any side effects. It does not contradict annotations, but offers minimal behavioral insight beyond the obvious creation action.

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 a single, concise sentence that front-loads the primary action and resource. There is no wasted verbiage, and it is easy to scan. However, it lacks any structural elements like bullet points or a breakdown of prerequisites, and it is slightly under-specified given the tool's complexity.

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 six parameters (points, u_count, v_count, degrees, name, layer) and an output schema, the description is far from complete. It does not explain the requirement that points.length equals u_count * v_count, the degree limits (1–11), or that the surface is added to the document. An agent would need to rely entirely on the schema to understand constraints, and even then, the description omits behavioral context like object creation semantics. The presence of an output schema helps, but the description still leaves significant gaps.

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%, meaning the tool description does not help explain any of the parameters. The description only mentions 'grid of control points', which partially aligns with the 'points' parameter, but it ignores u_count, v_count, degrees, name, and layer. Since the schema itself has decent descriptions (e.g., row-major, degrees), the description fails to compensate for the low coverage and adds no value for parameter understanding.

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 states a clear verb ('Create') and a specific resource ('NURBS surface') and includes a differentiator ('from a grid of control points'). This distinguishes it from sibling tools like rhino_create_planar_surface or rhino_create_patch, though it does not explicitly name alternatives. It is unambiguous and specific enough for an agent to understand the core function.

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 other surface creation tools (e.g., loft, patch, planar_surface). It does not mention prerequisites, the necessity of a rectangular grid, or when an alternative would be more appropriate. The usage context is only implied by the phrase 'grid of control points' and the schema's u_count/v_count, but no explicit advice is given.

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