blend-ai

Overview Schema Source Related Servers Discussions Admin

check_3d_printability

Checks a Blender mesh for 3D printability, catching reversed normals, self-intersections, and thin walls that slicers reject.

Instructions

Check whether a mesh will 3D print, using Blender's 3D Print Toolbox.

Catches three defects a mesh can carry while still passing analyze_mesh_quality, because each one leaves the mesh manifold, watertight and free of degenerate faces:

Bad contiguous edges: a shell whose normals agree with each other but collectively face inward. Recalculating normals reports nothing to fix, and the slicer rejects the file as having reversed faces.
Intersect faces: the surface passing through itself.
Thin faces: walls thinner than the nozzle, which slice away to nothing.

It also reports shell count, zero-area faces and edges, non-flat faces, sharp edges and overhanging faces. Index lists are capped at 50 samples and can be fed straight to select_by_index to see the problem in Blender.

Requires the 3D Print Toolbox extension, which ships with Blender but is off by default. If it is disabled this returns an error saying how to enable it; suggest_extensions also reports whether it is on.

Args: object_name: Name of the mesh object to check. checks: Which checks to run - any of SOLID (non-manifold and bad contiguous edges), INTERSECT, DEGENERATE (zero faces and edges), THICKNESS, SHARP, OVERHANG, NONPLANAR. Omit or pass an empty list to run everything, which also reports shell count. Counts are only returned for checks that actually ran. overhang_angle: Overhang threshold in RADIANS. Faces steeper than this need support. 0.785 (45 degrees) is the usual FDM limit. Leave unset to keep the toolbox's current setting. min_thickness: Minimum wall thickness in Blender units. Set it to your nozzle width. Leave unset to keep the current setting. sharp_angle: Sharp-edge threshold in RADIANS. nonplanar_angle: Non-flat face threshold in RADIANS. zero_threshold: Area below which a face counts as zero-area.

Returns: Dict with a count (and sample indices) per check that ran, plus checks_run, issues_found, and print_blocking: the defects that stop a print, as opposed to overhangs and sharp edges which are advisory.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`checks`	No
`object_name`	Yes
`sharp_angle`	No
`min_thickness`	No
`overhang_angle`	No
`zero_threshold`	No
`nonplanar_angle`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.7.0Sep 28, 2026

TDQS

A4.9/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: it defines each defect semantically, discloses the 50-sample index cap, explains the error returned when the toolbox extension is disabled, and distinguishes print_blocking defects from advisory ones like overhangs. Safety-relevant behavior (read-only check, no mutation) is implied clearly.

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-loads purpose and defect rationale, then Args/Returns; each section earns its place, though the bulleted defect explanations and extension note make it longer than strictly minimal. Structure is clear and navigable.

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 a 7-parameter tool with a non-trivial domain, the description covers purpose, defect semantics, parameter meanings, error behavior, sampling limits, and return shape. Even with an output schema present, the extra description of print_blocking vs advisory adds necessary context.

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, and it does: it enumerates the SOLID/INTERSECT/DEGENERATE/THICKNESS/SHARP/OVERHANG/NONPLANAR values, states radians and gives a 45-degree FDM example for overhang_angle, and explains unset defaults for every optional angle/threshold. This is far beyond what the JSON schema provides.

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 ('check whether a mesh will 3D print') and immediately differentiates from the sibling analyze_mesh_quality, naming the exact defect classes that pass that tool but fail here. An agent can tell the two apart without opening a schema.

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

Usage Guidelines5/5

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

Explicitly frames when to use this over analyze_mesh_quality, explains the checks option (omit/empty list runs all), documents the extension prerequisite, notes the error path when disabled, and points to suggest_extensions for checking its state. Alternatives and conditions are spelled out.

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

Deploy Server