Skip to main content
Glama

add_thread

Generate real helical ISO 60° thread geometry as a solid for FreeCAD, producing external studs or internal taps with specified diameter, pitch, and length.

Instructions

Generate a REAL helical ISO-style 60-degree thread as a static solid.

Unlike hole/list_thread_options (which only flag a thread as metadata), this cuts actual helical geometry: a truncated triangular rib swept along a helix and fused to a core cylinder.

All lengths in mm, angles in degrees. diameter: nominal MAJOR (crest) diameter, mm. For internal=True this is the bore the tap fits. pitch: thread pitch, mm per turn (e.g. M8 coarse = 1.25). length: threaded length along +Z from z=0, mm. internal: False (default) -> a finished externally-threaded stud. True -> a TAP/insert cutting-tool solid sized to the bore; fuse it into (or cut it from) a bored hole in your part to produce a threaded bore. starts: number of thread starts, >=1. Multi-start repeats the helix rotated by 360/starts and uses lead = pitch*starts. grade: optional material / property class as ordered ("8.8", "A2"). Changes no geometry; it completes the DIN 976-1 threaded-rod designation stamped on an EXTERNAL single-start thread — that solid is studding, a thing you buy by the metre. An internal thread is a tap-shaped cutting tool and a multi-start is not a stock item, so neither is designated at all. placement: optional [x, y, z] mm translation of the solid's base (default at the origin, axis along +Z). name: optional object name.

Geometry note: the modeled minor (root) uses the ISO 5H/8 truncation; the reported minor_diameter uses the standard ISO formula diameter - 1.0825*pitch. Fallback behaviour: if the helical sweep cannot produce a valid solid the tool returns a plain cylinder tagged with the thread spec and modeled=False (this is rare for sane M-series inputs); always check the modeled flag.

Returns {handle, name, volume (mm^3), major_diameter (mm), minor_diameter (mm), pitch (mm), length (mm), starts (int), internal (bool), modeled (bool), designation, orderable, catalog}. Studding is bought by the bar and cut, so any length up to the longest stock bar reads as stocked with a note that it is a cut. Mating numbers: drill/bore minor_diameter to tap an internal thread; clear a major_diameter (+clearance) hole to pass an external stud.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoThread
gradeNo
pitchYes
lengthYes
startsNo
diameterYes
internalNo
placementNo

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 does so richly: it discloses the fallback behavior (plain cylinder tagged with modeled=False), the discrepancy between the modeled minor (5H/8 truncation) and the reported minor_diameter formula, that `grade` changes no geometry, and the mating/drill conventions. This is well beyond baseline behavioral disclosure.

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 the key differentiator and organized with per-parameter lines and labeled notes. It is somewhat long and the multi-sentence `grade`/DIN 976-1 explanation is prose-heavy, but nearly every sentence adds operative detail rather than filler.

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, so the description must explain returns, and it fully enumerates the returned fields ({handle, name, volume, major_diameter, minor_diameter, pitch, length, starts, internal, modeled, designation, orderable, catalog}) and the stocked/cut semantics. For an 8-parameter generative tool this is complete.

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 define every parameter, and it does: diameter (major/crest, and bore for internal), pitch (mm per turn with M8 example), length (along +Z from z=0), internal, starts (with lead=pitch*starts rule), grade, placement, and name. Each parameter is given meaning and units beyond the bare schema titles.

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 and resource ('Generate a REAL helical ISO-style 60-degree thread as a static solid') and immediately distinguishes itself from the metadata-only siblings `hole`/`list_thread_options` by explaining it 'cuts actual helical geometry'. An agent can tell exactly what this produces versus the alternatives without opening any schema.

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?

Explicitly names the alternative tools and the condition that selects this one over them, and details the internal=False vs internal=True modes and how to fuse/cut into a hole. It stops short of an explicit 'don't use when' clause, but the routing context is strong and unambiguous.

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