Create a rib feature on a solid from selected curves by setting width and thickness.
Create a rib feature on a solid from selected curves.
Args:
controller: RhinoController instance.
width: Rib width.
thickness: Rib thickness.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | ||
| thickness | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It reveals that the tool creates a rib feature and depends on selected curves, but it does not mention document mutation, prerequisites, units, failure modes, or what happens to the input curves. This is a significant gap for a creation-oriented tool.
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 brief and front-loaded with the main purpose. The Args section is compact. It loses a point because the controller argument is mentioned but not reflected in the schema, and the parameter descriptions are near-tautological.
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 no annotations, two undocumented parameters, and a dependency on selected curves, the description does not provide enough context. It omits units, selection requirements, solid prerequisites, and any detail about the resulting geometry or return value, despite having an output schema.
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 must compensate. However, 'Rib width' and 'Rib thickness' essentially restate the parameter names and add no units, ranges, or behavioral meaning. The mention of 'controller: RhinoController instance' adds some context but is not present in the input schema, which may confuse an agent.
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 action and resource: 'Create a rib feature on a solid from selected curves.' It names the main inputs at a high level. However, it does not distinguish itself from related siblings like rhino_axis_ribs, so it falls short of full differentiation.
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 phrase 'from selected curves' implies that curves must be selected first, but there is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer the expected workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.