meshy-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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).
Completeness4/5
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.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/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 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![meshy-mcp MCP server](https://glama.ai/mcp/servers/zyadhajaji/meshy-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zyadhajaji/meshy-mcp)

Score Badge

Copy to your README.md:

[![meshy-mcp MCP server](https://glama.ai/mcp/servers/zyadhajaji/meshy-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zyadhajaji/meshy-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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