b123d-print-mcp

Overview Schema Source Related Servers Discussions Admin

design_metrics

Calculate per-part design review metrics before export—size, filament and cost estimates, print time, supports, slopes, edge treatment, symmetry, screws, seams, traps, and rule-based suggestions.

Instructions

Design numbers for the design review, per printable part: size and proportions, filament (simple estimate, roughly +-20 %) and cost, print time (rough estimate), supports, shallow slopes that show layer steps, edge treatment (sharp / filleted / chamfered shares, distinct radii and chamfer sizes), mirror symmetry, screw sizes, seam corners, water traps, inside corners, hole edge distance and slenderness across the layers (and the thinnest walls for a style that asks); then the suggestions the part's style triggers, each citing its DS-* rule. ALWAYS before export, after check passes; report its suggestions to the user. style: override the part's STYLE (functional, modern, least_cost, rugged, soft, structural, or a style file of the user's: list_parts shows them). up: the direction that points up in use for the water-trap check (+X, -Y, ...; default the script's UP, else +Z). as_json: the full numbers as JSON instead of the text report. Changes nothing.

Input Schema

Name	Required	Description	Default
`up`	No
`name`	Yes
`style`	No
`as_json`	No
`variant`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.12Oct 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the burden and usefully discloses that it changes nothing, that filament and print-time figures are rough estimates, and that suggestions cite DS-* rules. It does not describe failure behavior if check has not passed, but the read-only and estimation traits are clearly stated.

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?

The description is dense and run-on, but it front-loads the main purpose and the metric list before moving to workflow and parameter notes. Given the complexity of the computed outputs, most of the length is justified.

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

Completeness4/5

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

An output schema exists, so the description need not enumerate return fields, and it does cover the main workflow, metrics, and most optional parameters. The missing explanation of variant is a gap, but overall it is complete enough for this complex tool.

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

Parameters3/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. It explains style with enumerated values and list_parts reference, explains up as a direction with default behavior, and explains as_json as a report-format switch, but it leaves variant undocumented and treats name only implicitly.

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?

The description gives a specific verb and resource: it computes design numbers for a printable part, then enumerates the metrics and style-triggered suggestions it returns. It also distinguishes its place in the workflow by saying it runs after check passes and before export.

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?

It explicitly states the required sequence: "ALWAYS before export, after check passes," which tells the agent when to call it relative to sibling tools. It does not spell out when not to use it or name a direct alternative, but the workflow context is clear.

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