Meshy MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Auto Split Model into Printable Parts

meshy_auto_split

Cut a 3D model into separately printable parts for oversized print beds, multi-color/material builds, or assembly, with optional connectors.

Instructions

Cut a model into separately printable parts: when it is too big for the bed, parts need different colors/materials, or it should be assembled. Cost: 10 credits. The texture is not kept.

There is no bed-size parameter: cuts follow mode and prompt, not your printer, so resize the model to the print size first (meshy_resize) when parts must fit a bed, then check the part sizes and re-split by_parts if one is still too big. Then meshy_download_model (3mf if requested) and meshy_send_to_slicer.

Example: { input_task_id: "abc-123", mode: "by_parts", prompt: "the figure and the base", target_formats: ["3mf"], connectors: true }

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	'auto' (default; Meshy picks the cuts), 'by_parts' (the parts named in prompt), or 'by_color' (the color regions named in prompt; image-to-3d / multi-image-to-3d sources only).
`layout`	No	'assembled' (default) or 'on_plate' (parts laid flat, ready to slice).
`prompt`	No	Required for by_parts / by_color: name 1–10 parts, e.g. 'head, torso, arms, legs'; the rest becomes one more part. If unreadable, the task falls back to auto, still charges, and reports prompt_ignored.
`connectors`	No	Add mortise-and-tenon connectors at each cut so the parts fit together.
`input_task_id`	Yes	A SUCCEEDED image-to-3d, multi-image-to-3d, text-to-3d preview, remesh, convert or resize task made with meshy-6, meshy-7, meshy-7.1 or latest (not low-poly or Smart Topology).
`connector_size`	No	Relative to the cut surface (default 0.5).
`connector_type`	No	Connector shape (default cube).
`target_formats`	No	Extra formats (glb is always made). 3mf gives separately selectable parts in a slicer; stl fuses them into one solid.
`response_format`	No	markdown (default) or json	markdown
`connector_height`	No	Relative extension from the cut (default 0.1).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`message`	Yes
`task_id`	Yes
`estimated_time`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.4Oct 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: cost (10 credits), the fact that texture is not preserved, and the architectural constraint that cuts follow mode/prompt rather than printer geometry. Annotations cover the write/openWorld profile, but the description carries the cost and output-fidelity disclosures the annotations cannot express.

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

Conciseness5/5

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

Front-loads purpose and motivation in the first sentence, then prerequisite workflow, then a concrete example object. Every line earns its place; no filler or restatement of the title.

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 10-parameter mutation tool, it covers cost, side effects, prerequisites, downstream steps, and a call example, while an output schema already handles return values. An agent has everything needed to invoke it correctly in the right sequence.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds real value by explicitly noting the absence of a bed-size parameter and how mode/prompt jointly determine the cuts, reinforced by a full worked example. It stops short of explaining every connector/layout nuance, which the schema already handles.

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 ('cut a model into separately printable parts') and lists the three concrete conditions that motivate it (too big for bed, differing colors/materials, assembly). It is clearly distinguishable from sibling operations like meshy_resize, meshy_remesh, and meshy_convert 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 Guidelines5/5

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

Gives explicit when-to-use triggers, plus a before/after workflow: resize first with meshy_resize because there is no bed-size parameter, check part sizes and re-split by_parts, then meshy_download_model and meshy_send_to_slicer. Alternatives and ordering constraints are named directly rather than left to inference.

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