Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

add_rib

Adds a reinforcing rib inside a PartDesign Body by converting an open sketch spine into a wall that fuses with surrounding material.

Instructions

Add a reinforcing rib/web inside a PartDesign Body by thickening an OPEN sketch profile into a wall that fuses with the body's surrounding material.

Args: body: handle of the PartDesign Body (from make_body) to add the rib to. sketch: handle of a sketch holding an OPEN spine (a single line, arc, or connected polyline) that defines where the rib runs. Must NOT be a closed loop. The sketch's attachment plane sets the rib's orientation. thickness: rib wall thickness in mm (> 0). midplane: if True (default) the wall is centered on the spine, growing thickness/2 to each side; if False it grows from one side. reversed: flip the extrusion sense (use if the rib lands on the wrong side of its sketch plane). name: object label.

Returns a dict: {handle (starts 'rib_'), name, volume (the whole Body's Shape.Volume in mm^3 after the rib — strictly greater than before the rib, since a rib only adds material), thickness}.

Fallback behaviour the caller should know: FreeCAD's native PartDesign::Rib type is unavailable in AnkusDrive's headless runtime, so the rib is built as an equivalent midplane PartDesign::Pad — the open spine is offset by +/-thickness/2 into a closed footprint and padded across the body so it reaches the surrounding walls. For the usual straight or smoothly-curved spine this matches a Rib; very intricate spines may differ from the native tool. Raises ValueError if the profile is closed/empty/degenerate or thickness <= 0, and RuntimeError if the rib adds no material (spine does not span between walls).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes
nameNoRib
sketchYes
midplaneNo
reversedNo
thicknessYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: it discloses the fallback implementation (native Rib unavailable, built as Pad), the material-adding guarantee (volume strictly greater), and precise raise conditions. This is exactly the behavioral context an agent needs beyond the name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then Args, Returns, and fallback sections. Well organized and nearly every sentence earns its place, though the length is substantial and the fallback paragraph could be marginally tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description spells out the return dict (handle prefix 'rib_', name, volume, thickness) and every failure mode. For a complex PartDesign feature tool, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it documents all six parameters with real meaning: body source, open-spine requirement, thickness units (>0), midplane semantics (thickness/2 each side), reversed flip sense, and name as label. The sketch attachment-plane note adds orientation semantics not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Add a reinforcing rib/web inside a PartDesign Body') and the mechanism (thickening an open sketch profile into a wall that fuses with surrounding material). This clearly distinguishes it from siblings like pad, sweep, or loft.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides rich context: the sketch must be an OPEN spine and not a closed loop, reversed is for landing on the wrong side, and the ValueError/RuntimeError conditions define failure boundaries. It stops short of explicitly naming alternative tools (e.g., pad/sweep) or stating when to prefer them, keeping it from a 5.

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

Deploy Server

Other Tools