Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@meshy-mcp Generate a 3D model of a vintage leather messenger bag"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
meshy-mcp is a Model Context Protocol server that connects Claude to the Meshy AI 3D generation API.
Once connected to Claude Desktop (or any MCP client), you can say:
"Generate a 3D model of a vintage leather messenger bag" "Turn this product photo into a 3D model" "Apply a carbon fiber texture to this model" "Build me a 3D showroom environment for my clothing brand"
…and Claude will call Meshy, poll until the model is ready, and hand you back download links for GLB, FBX, OBJ, and USDZ files — all without leaving the conversation.
Related MCP server: Meshy MCP Server
Sign up at app.meshy.ai → Settings → API Keys → Generate Key.
Open your config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"meshy-3d": {
"command": "npx",
"args": ["-y", "meshy-mcp"],
"env": {
"MESHY_API_KEY": "msy_your_key_here"
}
}
}
}Restart Claude Desktop. Done — Claude now has 3D generation tools.
See docs/setup.md for custom MCP clients, running from source, and troubleshooting.
Six tools are exposed to Claude:
Tool | What it does |
| Text → 3D model (GLB, FBX, OBJ, USDZ) |
| Upgrade preview to production quality with PBR textures |
| Image URL → 3D model |
| Apply AI-generated textures + PBR maps to any model |
| Poll status of any running task |
| List recently generated models |
Full parameter reference: docs/tools.md
Paste any of these into Claude after connecting meshy-mcp:
Generate a 3D model of a puffer jacket with a reflective quilted surface, realistic style, quad topology.Turn this image into a 3D model and apply a woven denim texture: https://example.com/jacket.jpgGenerate a minimalist luxury showroom environment — white walls, concrete floor, warm spotlights — for a clothing brand website.Generate a low-poly voxel sneaker for a game. Target 5000 polygons.Create a 3D wristwatch model, then refine it to production quality with PBR textures.Turn product descriptions or photos into 3D assets for e-commerce, AR try-on, and marketing. Works for fashion, furniture, electronics, and more.
Generate scene props and environments, export GLB files, and embed them with Three.js or Babylon.js. Build interactive 3D landing pages, virtual showrooms, and immersive brand experiences — all by describing them to Claude.
Generate photorealistic garment mockups, brand kit 3D assets, and complete lookbook scenes. Use alongside ThreadForge for the full clothing brand workflow.
Generate props, characters, and environment pieces with game-ready topology. Export FBX for Unreal Engine or Unity.
USDZ output works with Apple AR Quick Look and visionOS. Generate and share AR-viewable 3D models directly from Claude.
Meshy is not just a tool — it's one of the most well-engineered AI data flywheels in the 3D space. Understanding how they built it changes how you think about using and building on top of their API.
The short version:
The 4-variant limit per generation is not a cost-saving measure — it's a training data architecture decision
Every model you pick over the others is a free preference signal (RLHF without asking)
The free tier exists to collect data, not out of generosity
After millions of generations, Meshy holds a (prompt → accepted output) dataset that no competitor can buy
Every developer who builds on the API (like this repo) extends their distribution for free
Read the full breakdown: docs/how-meshy-built-a-3d-ai-empire.md
Covers: the technical stack, the data flywheel, the Midjourney parallel, pricing power risk, self-hosting alternatives, and the exact blueprint for replicating this in any vertical.
meshy-mcp/
├── src/
│ ├── index.ts # Entry point
│ ├── server.ts # MCP server + tool router
│ ├── meshy/
│ │ ├── client.ts # Meshy REST API client
│ │ ├── types.ts # Full TypeScript type definitions
│ │ └── poller.ts # Async task completion poller
│ ├── tools/
│ │ ├── text-to-3d.ts # generate_3d_model
│ │ ├── refine-3d.ts # refine_3d_model
│ │ ├── image-to-3d.ts # generate_3d_from_image
│ │ ├── texture.ts # add_texture
│ │ └── status.ts # check_task_status + list_3d_models
│ └── utils/
│ └── format.ts # Markdown output formatters
├── docs/ # Setup + tool reference
├── examples/ # Claude Desktop config + prompt walkthroughs
├── CLAUDE.md # AI agent context (for Claude Code)
└── .env.exampleProtocol: stdio MCP (compatible with Claude Desktop, Cursor, Zed, and any MCP client)
Language: TypeScript 5, ESM, Node.js 20+
Dependencies: @modelcontextprotocol/sdk, zod — nothing else
Variable | Required | Default | Description |
| ✅ | — | From app.meshy.ai → Settings → API Keys |
| — |
| Override API base URL |
| — |
| Max wait per task |
| — |
| Polling frequency |
Fork → create a branch → npm run typecheck before committing
New tool? Follow the pattern in any existing file in src/tools/
Open a PR — see CLAUDE.md for the full contributor guide
Meshy AI — the 3D generation API powering this server
Model Context Protocol — the open protocol for Claude tool use
ThreadForge — clothing brand mockup platform (pairs well with meshy-mcp)
Claude Desktop — the MCP client used in examples
How Meshy Built a $20M+ 3D AI Business — deep dive into the data flywheel, training strategy, and business model
Keywords: MCP server 3D generation · Claude 3D model tool · Meshy AI MCP · text to 3D Claude · image to 3D AI · 3D environment generator · Claude Desktop MCP · AI 3D design tool · model context protocol 3D · Meshy API integration · AI texture generation · GLB FBX generator · Three.js asset generation · 3D website environment AI · anthropic tool use 3D
Apply AI-generated textures to an existing 3D model using Meshy AI.
Takes a GLB or OBJ model URL and generates: • Base color map • Metallic map • Roughness map • Normal map (for surface detail without extra polygons)
Returns a fully textured GLB/FBX ready for Three.js, Babylon.js, Unity, Unreal Engine, or Blender.
Use cases: • Apply brand-specific textures to clothing 3D models • Add realistic material finishes (leather, fabric, metal, wood) • Generate texture variants for A/B testing product visuals • Style website 3D environments with custom looks
| Name | Required | Description | Default |
|---|---|---|---|
| model_url | Yes | ||
| object_prompt | Yes | ||
| style_prompt | No | ||
| negative_prompt | No | ||
| art_style | No | realistic | |
| resolution | No | 2048 | |
| enable_pbr | No | ||
| seed | No | ||
| wait_for_completion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only partially discloses behavior: it states outputs (maps and formats) but omits side effects, limitations, or authentication needs. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and use cases, front-loading the main action. While it is not extremely terse, every sentence adds value and supports understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and no output schema, the description is incomplete. It lacks parameter explanations, return structure, and error handling, making it insufficient for an AI agent to invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains the model_url parameter implicitly, leaving other parameters (object_prompt, style_prompt, etc.) unexplained. This fails to compensate for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool applies AI-generated textures to an existing 3D model, specifying the input format (GLB/OBJ) and generated maps. It also lists use cases that differentiate it from sibling tools like generate_3d_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists use cases but does not explicitly guide when to use this tool versus alternatives. It implies context via examples but lacks explicit when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status and progress of any Meshy generation task.
Returns current status (PENDING, IN_PROGRESS, SUCCEEDED, FAILED), progress percentage, and download links once complete.
Use this when you started a task with wait_for_completion: false, or to check on a previously started generation.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| task_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses return values (status, progress, download links). It implies a read-only operation, though it could explicitly mention polling safety. Still, the key behavior is documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the core purpose and provide details without waste. Each sentence earns its place, making it efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check tool, it explains return values but lacks parameter descriptions and output schema. Given the absence of schema descriptions, more detail on parameters would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to explain parameters. It does not describe task_id or task_type beyond the purpose statement, leaving the agent to infer from context. The enum values are only in schema, not in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks status and progress of a Meshy generation task, listing possible statuses and returned fields. It effectively distinguishes from sibling generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: for tasks started with wait_for_completion: false, or to check on previous generations. This provides clear guidance and implies not for starting tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn any image into a 3D model using Meshy AI.
Best inputs: • Product photos (sneakers, bags, furniture, clothing items) • Objects on white or clean backgrounds • Front-facing or 3/4-view photos • Logos or illustrations to extrude into 3D
Returns GLB, FBX, OBJ, and USDZ download links with optional PBR textures.
Use cases: • Turn a clothing brand's product photo into a 3D asset • Generate 3D models from design mockups or sketches • Convert reference images into scene props
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | ||
| enable_pbr | No | ||
| ai_model | No | meshy-4 | |
| topology | No | quad | |
| target_polycount | No | ||
| should_remesh | No | ||
| wait_for_completion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output: 'Returns GLB, FBX, OBJ, and USDZ download links with optional PBR textures.' However, it omits important behavioral traits such as whether the operation is asynchronous (despite the 'wait_for_completion' parameter), any side effects, or requirements like API keys. It provides some transparency but has notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening line, bullet points for best inputs and use cases. It is relatively concise, though the use case bullets are somewhat redundant with the best inputs. Each section serves a purpose, making the description easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is incomplete. It covers purpose and high-level usage but lacks details on parameter behavior, error handling, asynchronous behavior, and response format specifics. A more comprehensive description is needed for an agent to use this tool correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 only indirectly references 'image_url' (as the input image) and 'enable_pbr' (through 'optional PBR textures'). Parameters like 'ai_model', 'topology', 'target_polycount', 'should_remesh', and 'wait_for_completion' are not explained. The description adds minimal meaning beyond the schema's raw structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Turn any image into a 3D model using Meshy AI.' It specifies the action (turn image into 3D model) and the resource (image). It also distinguishes itself from siblings by being explicitly image-to-3D, while siblings like 'generate_3d_model' might accept other inputs. The use cases and best inputs further clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool through 'Best inputs' (e.g., product photos, clean backgrounds) and 'Use cases' (e.g., turning product photos into 3D assets). It does not explicitly state when NOT to use or suggest alternatives, but the context is sufficient for typical usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 3D model from a text description using Meshy AI.
Returns download links for GLB, FBX, OBJ, and USDZ formats, plus a thumbnail and turntable video preview.
Use cases: • Product 3D assets for e-commerce or AR • Game and scene props • Architectural models • Fashion and clothing items • Characters and creatures
After generating a preview, call refine_3d_model for production-quality output, or add_texture to apply custom textures.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text description of the 3D object to generate. Be specific: materials, shape, style, and context. Example: 'A weathered leather armchair with brass nail-head trim, realistic style' | |
| art_style | No | realistic | |
| negative_prompt | No | ||
| ai_model | No | meshy-4 | |
| topology | No | quad | |
| target_polycount | No | ||
| seed | No | ||
| wait_for_completion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that the initial output is a 'preview' and needs refinement for production-quality, implying a two-step generation process. Also states return formats (download links, thumbnail, video). Does not discuss rate limits or auth, but for a generation tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: opens with purpose, lists return formats, enumerates use cases, and ends with workflow guidance. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main generation flow and output format but omits detailed behavior of 7 out of 8 parameters. No output schema and no annotations. The description is adequate for a high-level understanding but incomplete for full parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (only prompt has a description). Description adds value for prompt (specificity, example) but does not explain other parameters (art_style, negative_prompt, ai_model, topology, target_polycount, seed, wait_for_completion). With low coverage, description fails to compensate for missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a 3D model from text using Meshy AI. Lists specific output formats (GLB, FBX, OBJ, USDZ, thumbnail, video) and diverse use cases (e-commerce, games, architecture). Distinguishes from sibling tools by mentioning refine_3d_model and add_texture as follow-up steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit follow-up workflow: call refine_3d_model for production quality or add_texture for custom textures. Lists use cases to guide when to use. Does not explicitly mention when not to use, but the sibling differentiation is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your recently generated 3D models from Meshy.
Returns task IDs, prompts, statuses, and download links for your most recent text-to-3D generations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions returning recent models and specific fields but does not explain ordering, pagination, authentication needs, or rate limits. The vagueness of 'recent' and lack of behavioral details reduce transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: the first states the primary purpose, the second lists returned fields. Every word adds value, and the description is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately outlines the return fields (task IDs, prompts, statuses, download links). However, it omits details on pagination, ordering, and the exact meaning of 'recent', leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (limit) with 0% description coverage. The description does not mention the limit parameter or its effect on results. This is a significant gap; the description fails to add meaning beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recently generated 3D models from Meshy, specifying the action, resource, and source. It distinguishes itself from sibling tools like generate_3d_model or check_task_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recently generated models, but does not explicitly state when to use this tool versus alternatives like check_task_status. It provides clear context but lacks exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refine a preview 3D model to production quality using Meshy AI.
Run this after generate_3d_model to get: • Higher polygon detail • PBR texture maps (base color, metallic, roughness, normal) • Production-ready GLB/FBX/OBJ files suitable for Unreal Engine, Unity, Blender, Three.js, or AR
Requires a completed preview task ID from generate_3d_model.
| Name | Required | Description | Default |
|---|---|---|---|
| preview_task_id | Yes | ||
| texture_richness | No | high | |
| enable_pbr | No | ||
| wait_for_completion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses outputs (GLB/FBX/OBJ, PBR maps) and the prerequisite, but does not reveal potential behavioral traits like processing time, cost implications, or whether the original preview is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core statement, then uses bullet points for benefits, and concludes with a requirement. It is efficient but could be slightly more concise by integrating the parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema or annotations, the description provides adequate context for basic usage but lacks depth on parameter behavior, error handling, and output specifics beyond file types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains the preview_task_id parameter; texture_richness, enable_pbr, and wait_for_completion are left undefined. Though parameter names are self-explanatory, the description should clarify their role, especially given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'refine' and resource 'preview 3D model', distinguishing it from generate_3d_model and siblings like add_texture. It specifies the outcome: production quality with higher detail and PBR maps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Run this after generate_3d_model' and requires a completed preview task ID. Provides context on when to use, but does not mention when not to use or alternative tools like add_texture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_texturecheck_task_statusgenerate_3d_from_imagegenerate_3d_modellist_3d_modelsrefine_3d_modelEach tool has a clearly distinct purpose: generation from text vs image, refinement, texturing, status checking, and listing. No two tools overlap in functionality, reducing the risk of misselection.
All tool names follow a consistent verb_noun pattern with underscores (e.g., generate_3d_model, add_texture). The naming is predictable and uniform across the entire set.
With 6 tools, the surface is well-scoped for a 3D generation service, covering the core workflow (generate, refine, texture) plus necessary management tools (list, check status).
The tool set covers the primary generation and texturing workflow, but lacks a delete or update operation for models, and there's no upload tool for custom models (only URL-based). These are minor gaps that agents can work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn text or an image into an animation-ready 3D model (GLB): generate, rig, animate, retexture.
Turn any LLM multimodal; generate images, voices, videos, 3D models, music, and more.
3D avatar/asset foundry: text/image -> rigged, validated, engine-ready GLB via x402.
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zyadhajaji/meshy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
