Generate two orthogonal sets of section ribs from a surface or Brep to create waffle-style fabrication pieces. Specify axes and counts to produce bridge-only rib geometry.
Generate two orthogonal sets of section ribs (waffle-style fabrication, bridge only).
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with readOnlyHint=false by indicating a generative/write operation, and it adds the bridge-only compatibility constraint. However, it does not disclose whether the source object is modified, whether new objects are created on a specific layer, or other side effects beyond generation.
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 entire description is one efficient sentence that front-loads the core action and then packs the two most valuable qualifiers ('waffle-style fabrication', 'bridge only') into a short parenthetical. There is no wasted or redundant wording.
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?
Given that an output schema exists and the input schema provides descriptions for the key parameters, the short description is mostly sufficient. It clearly communicates the high-level operation and restrictive context, though it could be slightly stronger about what exactly is produced or how the source object is treated.
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?
The schema already documents object_id, axis_a, axis_b, and doc_id, and count_a/count_b are self-describing through names and min/max constraints. The description's mention of 'two orthogonal sets' adds high-level intent for axes and counts, but it does not explain parameter defaults or the layer parameter, leaving that responsibility to the schema.
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 names a specific action ('Generate'), a specific resource ('two orthogonal sets of section ribs'), and adds a clear fabrication context ('waffle-style'). It distinguishes this tool from generic sectioning or single-rib tools by emphasizing the orthogonal two-set output and bridge-only scope.
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 parenthetical 'waffle-style fabrication, bridge only' gives a clear usage context and an explicit restriction about where the tool applies. It does not name alternative tools or explicitly state when not to use them, but the intended use case is reasonably well communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.