Skip to main content
Glama
meshy-dev

Meshy MCP Server

Official
by meshy-dev

Repair Model Topology for 3D Printing

meshy_repair_printability

Repairs 3D models for printing by fixing non-manifold edges, holes, and degenerate faces to make them watertight; can thicken thin walls for FDM, SLA, or full-color prints.

Instructions

Repair a model for 3D printing (FDM, SLA/resin or full-color): fixes non-manifold edges, degenerate faces and holes and makes it watertight. Cost: 10 credits. Textures are removed (retexture afterwards if needed).

Output format: input_task_id → GLB; model_url → the input's format (.stl → STL, .obj → OBJ…). To keep a Meshy model as OBJ, pass its OBJ URL (model_urls.obj) as model_url. With printer_type and/or a print size it also thickens walls that are too thin, when over 5% of the surface is. The model keeps its scale (meshy_resize scales it).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_urlNoPublic URL of a .glb / .gltf / .obj / .fbx / .stl model (max 400 MB), or a GLB data URI (max 100 MB).
printer_typeNoSets the minimum wall: fdm 1.0 mm, sla 0.8 mm, full_color 2.0 mm (fdm when only a size is sent). Without a size: 150 mm tall for GLB / tasks, an STL's own size, else 150 mm longest side.
input_task_idNoA SUCCEEDED text-to-3d, image-to-3d, multi-image-to-3d, remesh or retexture task, or a print-analyze task (which passes on its printer and size). Wins over model_url.
alpha_thumbnailNoAlso return a transparent-background preview (alpha_thumbnail_url).
response_formatNomarkdown (default) or jsonmarkdown
intended_print_height_mmNoPrint height in mm (1–1000); GLB / input_task_id only. At most one print size.
intended_print_longest_side_mmNoPrint's longest side in mm (1–1000); any format. At most one print size.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.4

TDQS

A4.6/5.0
Behavior5/5

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

Despite existing annotations, the description adds substantial behavioral detail: 10-credit cost, that textures are removed, the input→output format mapping, the OBJ-preservation trick, conditional wall thickening, and scale preservation. This is exactly the extra context annotations can't convey.

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 core action, then behaviors, then the output-format mechanics. Dense but every sentence carries information; no filler. Slightly paragraph-heavy but structurally sound.

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 no output schema, the description explains the return format (input_task_id → GLB, model_url → input format), cost, side effects, and conditional behavior. An agent has everything needed to invoke it correctly.

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 already 100%, so the baseline is 3, but the description adds real meaning: the output format for model_url, the note 'to keep as OBJ, pass model_urls.obj', and how printer_type interacts with a print size to trigger wall thickening.

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 ('Repair a model for 3D printing') and enumerates exactly what it fixes (non-manifold edges, degenerate faces, holes, watertightness). It also distinguishes itself from siblings by naming meshy_resize and retexture.

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?

Explains the printing use case and the follow-up route ('retexture afterwards if needed'), plus when wall-thickening kicks in (with printer_type/size and >5% thin surface). It doesn't explicitly contrast against meshy_remesh or meshy_analyze_printability, but context is clear.

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