blend-ai

Overview Schema Source Related Servers Discussions Admin

create_threaded_shaft

Generates a cylindrical shaft with helical external threads at specified diameter and length, suitable for creating threaded fasteners or boolean-union onto screw-heads.

Instructions

Create a cylindrical shaft with helical external threads.

Produces a single mesh object: a threaded rod at the given diameter and length, with helical thread ridges following the specified pitch. Suitable for boolean-union onto a screw-head or direct use as a threaded fastener.

Thread geometry: a 60-degree V profile swept along a Z-axis helix via the Screw modifier.

Args: diameter: Major diameter of the shaft (outer thread peaks). Must be > 0. length: Axial length of the shaft (under-head length, like real fastener spec). Must be > 0. pitch: Distance between thread peaks along the axis. Must be > 0 and <= length. thread_depth: Radial depth of the thread (major radius - minor radius). If 0 (default), auto-computed as pitch * 0.54. segments: Rotational resolution of the helix (steps per revolution). Range: 3-256. Higher = smoother helix, more geometry. thread_runout: Smooth (unthreaded) region at the top of the shaft. Defaults to 0 (full-length threads), which gives the strongest print because threads under the head form a continuous stress path. Leaving a smooth runout creates a thin-walled neck at minor_r that snaps under torque in FDM prints. Pass a positive value only if a head's deep hex socket would otherwise reach thread peaks. name: Optional name for the object. Auto-generated if empty. location: XYZ position of the shaft base as a 3-element list/tuple.

Returns: Dict with the created object's name, diameter, length, pitch, and the number of thread iterations actually generated.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`pitch`	Yes
`length`	Yes
`diameter`	Yes
`location`	No
`segments`	No
`thread_depth`	No
`thread_runout`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.2.2May 3, 2026

TDQS

A4.5/5.0

Behavior4/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 well: it discloses the geometry method (60-degree V profile swept along a Z-axis helix via Screw modifier), the auto-computed thread_depth behavior, the print-strength consequences of runout, and that it returns a single mesh object. It omits any permission, side-effect, or scene-state caveats, but for a pure geometry-creation tool those are minor.

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?

Well front-loaded and sectioned (purpose, geometry, Args, Returns) so an agent can stop reading at any point. The thread_runout guidance is longer than strictly needed, but every sentence carries actionable information 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?

For an 8-parameter tool with zero schema coverage, the description fully documents inputs, constraints, and behavior, and even restates the return payload. Nothing an agent needs to invoke 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 description coverage is 0%, so the description must compensate fully, and it does: every one of the 8 parameters is documented with meaning, units, valid ranges, and defaults (e.g. diameter is 'outer thread peaks,' segments range 3-256, thread_depth defaults to pitch*0.54). This is meaning the schema alone cannot convey.

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 ('Create a cylindrical shaft with helical external threads') and immediately narrows scope with 'single mesh object.' An agent can distinguish this from generic primitives like create_curve or sweep_profile_along_path without opening the 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?

Gives clear context ('Suitable for boolean-union onto a screw-head or direct use as a threaded fastener') and even conditional guidance on the runout parameter ('Pass a positive value only if a head's deep hex socket would otherwise reach thread peaks'). It does not, however, explicitly compare itself to sibling modeling tools or state when a different primitive should be chosen instead.

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

Deploy Server