Meshy MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Generate 3D Model from Text

meshy_text_to_3d

Generate an untextured 3D model preview from a text prompt, then refine it with textures after approval. Use it for quick drafts before a textured image-to-3D workflow.

Instructions

Generate an untextured 3D PREVIEW from a text prompt; texture it afterwards with meshy_text_to_3d_refine once the user approves. Typically 2–3 minutes. Cost: 20 credits (meshy-7.1 / latest / meshy-6), 5 (meshy-6-lite, meshy-t2, meshy-t2.5); Ultra geometry +5.

PREFER THE IMAGE ROUTE: for higher quality and more control, generate a design image first (meshy_text_to_image), let the user approve it, then meshy_image_to_3d with input_task_id = the image task (textured in one task). Use direct text-to-3d for a quick draft or when the user explicitly asks for it.

PICK THE MODEL FROM THE PROJECT: ask what the model is for if the user hasn't said. A game asset, a character to rig, or a face-count budget: model_type "smart-topology" with meshy-t2.5 (or meshy-t2 for speed) and target_polycount, not meshy-7.1 with should_remesh. More: https://docs.meshy.ai/en/api/models

Examples:

Low-poly: { prompt: "dragon", model_type: "smart-topology", ai_model: "meshy-t2", target_polycount: 4000 }
Max detail: { prompt: "ornate knight helmet", ai_model: "meshy-7.1", geometry_resolution: "4k" }
3D print: { prompt: "cat", target_formats: ["obj"] }

Input Schema

Name	Required	Description	Default
`prompt`	Yes	What to model (max 800 characters)
`ai_model`	No	'latest' (default, = Meshy 7.1) or 'meshy-7.1' (best), 'meshy-6', 'meshy-6-lite' (fast, cheap, 2K textures only); 'meshy-7' is deprecated. With model_type smart-topology: 'meshy-t2' (the default there) or 'meshy-t2.5' (newest, sharper detail for game assets).
`topology`	No	quad or triangle (default).
`auto_size`	No	AI-estimate the real-world height and resize to it (default false).
`origin_at`	No	'bottom' or 'center' (default bottom with auto_size).
`pose_mode`	No	'a-pose' or 't-pose'; use 't-pose' when the model will be rigged or animated.
`model_type`	No	standard (default); smart-topology (ai_model meshy-t2 or meshy-t2.5): a clean, part-separated, triangle-only mesh made directly at target_polycount, ignoring remesh/decimation. lowpoly (Meshy T1) is retired: use smart-topology with meshy-t2.5.
`ultra_mode`	No	Deprecated: use geometry_resolution '2k'.
`should_remesh`	No	Remesh to target_polycount / topology (default false).
`symmetry_mode`	No	Deprecated: has no effect.
`target_formats`	No	Formats to produce (default: all but 3mf; list '3mf' to get it). Fewer formats finish faster.
`alpha_thumbnail`	No	Also return a transparent-background preview (alpha_thumbnail_url).
`decimation_mode`	No	Adaptive decimation 1 (ultra) – 4 (low); overrides target_polycount.
`response_format`	No	markdown (default) or json	markdown
`target_polycount`	No	Standard: remesh target 100–300,000, needs should_remesh true. Smart Topology: meshy-t2 100–15,000 (default 4,000), meshy-t2.5 100–30,000 (default 15,000).
`geometry_resolution`	No	Ultra geometry pass: standard (default), 2k or 4k (finest); meshy-7.1/latest with model_type standard only, +5 credits.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.7Oct 30, 2026

changedInput schema / properties / model_type / description

Previous value: -"standard (default); smart-topology (ai_model meshy-t2 or meshy-t2.5): a clean, part-separated, triangle-only mesh made directly at target_polycount, ignoring remesh/decimation; lowpoly is deprecated (billed like meshy-6, retires 2026-10-30)."New value: +"standard (default); smart-topology (ai_model meshy-t2 or meshy-t2.5): a clean, part-separated, triangle-only mesh made directly at target_polycount, ignoring remesh/decimation. lowpoly (Meshy T1) is retired: use smart-topology with meshy-t2.5."

changedInput schema / properties / model_type / enum

Previous value: -[
-  "standard",
-  "smart-topology",
-  "lowpoly"
-]New value: +[
+  "standard",
+  "smart-topology"
+]

First observedv0.6.4Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds the operationally critical facts they cannot: it produces an untextured preview requiring a separate texturing step, takes ~2–3 minutes, and costs 20 credits (5 for lite/T2 variants, +5 for Ultra geometry). That cost/latency/partial-result disclosure is exactly the context an agent needs before committing.

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 first sentence front-loads the critical preview-vs-textured distinction and the second the time/cost, which is the right ordering. The routing, model-selection and example blocks are dense rather than padded, though the all-caps directives and multi-section layout make it longer than strictly necessary for a single call decision.

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 16-parameter generative mutation tool this covers everything an agent needs to decide and configure: the preview limitation, follow-up tool, latency, credit cost, model/topology tradeoffs, and a doc link for edge cases. Return values are covered by the existing output schema, so their absence from the description is not a gap.

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?

With 100% schema coverage the baseline is 3, and the description goes beyond it by mapping project intent to parameter combinations ('model_type smart-topology with meshy-t2.5 and target_polycount, not meshy-7.1 with should_remesh') and by supplying three worked examples spanning low-poly, max-detail and 3D-print configurations. It does not explain every parameter (topology, pose_mode, alpha_thumbnail are left to the schema), so it falls short of a 5.

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 ('Generate an untextured 3D PREVIEW from a text prompt') and immediately delimits scope by naming the follow-up sibling meshy_text_to_3d_refine for texturing. An agent can distinguish this from meshy_image_to_3d and the refine tool 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?

Explicitly routes the agent: 'PREFER THE IMAGE ROUTE' via meshy_text_to_image then meshy_image_to_3d for quality/control, and reserves direct text-to-3D for quick drafts or explicit user requests. It also gives a second decision rule (ask what the model is for, then pick model_type/ai_model) and names the documentation link for further cases.

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