meshy-youtube-mcp

by Scottcjn

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target a distinct pipeline stage: generation, retexturing, rigging, animation, rendering, video encoding, and upload. The four *_to_youtube pipeline tools intentionally overlap with the step-wise tools, but their one-shot descriptions and naming make the intended choice clear.
Naming Consistency4/5
Core tools follow a consistent verb_noun snake_case pattern (generate_3d_model, retexture_model, rig_model, animate_model). The *_to_youtube pipeline tools are internally consistent but deviate from the verb-first pattern, and get_meshy_task_status embeds the brand name.
Tool Count5/5
14 tools are well-scoped for a generation-to-YouTube pipeline. Each stage has dedicated tools, and the four pipelines add useful high-level entry points without becoming bloated.
Completeness4/5
The surface covers the full workflow from text/image/model input through retexture, rig, animate, render, encode, and upload, with status checks throughout. The main gap is that animate_model refers to Meschy's action library without a tool to list available actions.
Average 3.7/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It only states the transformation and validates enum-like values. It does not mention that the operation is likely asynchronous, that a task id may need to be polled via get_meshy_task_status, or what side effects or return values to expect.
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 sentences, all information is load-bearing: the operation, the output format, and the two key constraints. No fluff or repetition.
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 no output schema and no annotations, the description should state what the caller receives (e.g., a task id vs. a downloadable file) and how it fits into the sibling pipeline. It only describes the core transformation, which is incomplete for an async Meshy workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaningful details for action_id (Meshy library with concrete IDs) and fps (allowed values), but leaves rig_task_id and timeout unexplained beyond their bare titles.
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 clear action ('Apply a motion to a rigged model') and the concrete output ('animated .glb'), which distinguishes it from sibling tools like rig_model (rigging) and generate_3d_model (generation). The action_id and fps constraints further scope the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance about when to choose animate_model over sibling tools such as animate_to_youtube, nor about prerequisite steps like first calling rig_model. The need for a rig_task_id is implied but never stated as a precondition. Only operational constraints on action_id and fps are provided.
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 behavioral disclosure burden. It transparently reveals that the call is a multi-step pipeline and that it 'Always returns a dict,' which is useful. However, it does not mention the long-running/external side effects of uploading to YouTube, authentication requirements, or failure behavior, so transparency is only partial.
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?
The description is a single tight sentence plus one useful guarantee, with no filler or repetition. The pipeline is front-loaded and every word carries information.
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?
For a tool with 16 parameters, no output schema, and no annotations, this is too sparse. It omits how the retexture is specified (style/prompt vs reference), what the returned dict contains, how long the operation takes, and how the final upload behaves, leaving an agent under-equipped for correct invocation.
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%, and the description names no parameters. The phrase 'existing model' hints that input is via model_url or input_task_id, and 'YouTube video' implies title/upload-related fields, but the remaining 14 parameters (e.g., fps, frames, privacy, enable_pbr, image_style_url, text_style_prompt) are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific composite operation: take an existing model, re-texture it, render a turntable, and produce a YouTube video. The 'One-shot' framing and arrow pipeline differentiate it from piecemeal sibling tools like render_turntable, frames_to_video, and upload_to_youtube, though it does not name them explicitly.
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 phrase 'One-shot' implies this tool is for performing the whole retexture-to-YouTube pipeline in a single call rather than chaining individual siblings, but the description gives no explicit when-to-use or when-not-to-use guidance. No alternatives are named, leaving the routing decision to inference.
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 carries the full burden. It discloses input types and output format, but omits critical behavioral details such as whether this is an asynchronous task, whether it returns a job ID or the .glb directly, and how it interacts with get_meshy_task_status. This is a significant gap for a generation tool.
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?
One compact arrow-syntax sentence front-loads the purpose and communicates input constraints, output format, and quality expectation with no filler. Every phrase earns its place.
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?
For a tool with 6 parameters, no output schema, and no annotations, this description is too thin. It does not explain the remaining parameters, the return contract, or asynchronous behavior, and it does not situate the tool within the surrounding workflow of status checking and downstream video/youtube steps.
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%, and the description only adds meaning for the images parameter by specifying URL/path formats and a count range. The other five parameters (timeout, enable_pbr, should_remesh, should_texture, texture_prompt) are left entirely to their property names, with no explanation of effect or trade-offs.
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 function: converting 1-4 reference images of one subject into a textured .glb model. The 'Multi-image' qualifier and image-count range distinguish it from the sibling single-image tool. Format of output is explicit.
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?
Provides clear context that the tool accepts 1-4 images of one subject, which implies the multi-image use case. However, it does not explicitly name alternatives like generate_3d_from_image or state when one should be preferred over the other, leaving some routing up to inference.
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 carries the full burden of behavioral disclosure. It explicitly describes the return contract: ok=True with watch_url on success, and ok=False with error/failed_stage and partial artifacts on known stage failures. It does not mention external side effects beyond the obvious YouTube upload or long-running execution, but the pipeline framing and timeout parameter partially cover that.
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?
The description is very compact: one pipeline line and one short return-contract paragraph. It is front-loaded with the core purpose and every sentence provides useful information without fluff or repetition.
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?
This is a multi-stage, 16-parameter tool with no output schema and no annotations, yet the description only provides high-level pipeline context and the return format. It does not explain the stages, parameter semantics, expected failures, or the relationship between all the configuration knobs, leaving an agent under-informed for correct invocation.
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% and the description does not explain any of the 16 parameters. Only 'prompt' appears in the pipeline, and 'title' is implied by YouTube upload, but there is no guidance on fps/frames/duration, should_emesh, texture_prompt, category_id, privacy, or made_for_kids. The description fails to compensate for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly shows a one-shot end-to-end pipeline from prompt to YouTube upload, which distinguishes it from sibling stage tools. It lacks an explicit action verb like 'orchestrates' or 'executes,' but the arrow chain makes the purpose unmistakable.
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 word 'One-shot' implies this tool should be used when the complete pipeline is desired in a single call rather than manually assembling sibling tools. However, it does not explicitly name alternatives, prerequisites, or situations where the user should instead call generate_3d_model, upload_to_youtube, etc. individually.
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 burden and does add some behavioral detail: the final clip shows the character performing the action, duration follows the animation, and the tool always returns a dict. However, it does not disclose side effects such as actually publishing/uploading to YouTube, auth requirements, failure behavior, or effects of defaults like privacy.
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 compressed sentences deliver the pipeline, the observable output trait, and a guaranteed return type with no filler. The chain is front-loaded and every clause earns its place.
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 13 parameters, no schema descriptions, no output schema, and no annotations, this is far from complete. The description gives a high-level pipeline and return type but omits prerequisites, parameter semantics, YouTube upload behavior, error handling, and model-source selection, leaving an agent under-informed for a complex one-shot mutation tool.
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% for 13 parameters, and the description only mentions action_id inside the pipeline, giving it a role (the action to animate). All other parameters—model_url vs input_task_id, resolution, fps, title, privacy, timeout, made_for_kids—are left without any meaning beyond their names and schemas, so the description fails to compensate for the low coverage.
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 names a specific end-to-end pipeline: take a humanoid model, rig via Meshy, animate by action_id, render the motion, and send it to YouTube. This clearly distinguishes it from its pipeline-step siblings like animate_model, render_turntable, and upload_to_youtube.
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?
'One-shot' implies this is for doing the whole animation-to-YouTube chain in a single call rather than by composing individual sibling tools, but the description never explicitly states when to choose this over alternatives or when not to use it. The usage context is only implied.
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?
There are no annotations, so the description carries the behavioral burden. It discloses the output contract ('Always returns a dict'), success/failure shape, and failure granularity ('error/failed_stage'). It also reveals the major side-effecting pipeline stages. It stops short of noting cost, auth requirements, latency, or YouTube publishing visibility, which would make it fully transparent.
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?
The description is two tightly packed sentences with no filler. The pipeline is front-loaded, and the return contract is stated immediately. Every phrase adds information.
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?
For a composite 15-parameter tool with no annotations and no output schema, the description is too thin. It gives the high-level flow and return shape but leaves out parameter semantics, usage trade-offs, side effects, and prerequisites. An agent knows what the tool roughly does but not enough to invoke it confidently with correct values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning beyond the implicit 'image' in the pipeline. None of the 15 parameters are explained, including required title, fps, frames, privacy, timeout, should_remesh, or made_for_kids. An agent has to infer or guess the semantics of most parameters.
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 end-to-end purpose: take an image, generate a 3D model via Meshy, create a turntable, and produce a YouTube video. The pipelined wording ('One-shot: ... -> ... -> ...') distinguishes this from granular sibling tools like generate_3d_model or upload_to_youtube, which handle only one stage.
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 'One-shot' phrasing implies use of this tool for the entire pipeline, while sibling tools cover individual stages. However, the description does not explicitly state when to prefer this composite tool over calling the individual steps, nor does it mention alternatives such as meshy_to_youtube or animate_to_youtube.
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 behavioral burden and does disclose the core conversion behavior: PNG frames become an H.264 mp4 that is YouTube-ready. But it does not describe where the output file is written, whether existing files are overwritten, or how fps and duration affect the encoding.
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?
The description is a single compact sentence that front-loads the verb and object. Every phrase ('numbered PNG frames', 'H.264 mp4', 'YouTube-ready as-is') contributes useful information with no filler.
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 low-complexity tool with three simple parameters, the description gives the essential input and output shape. However, it omits the meaning of fps/duration and says nothing about the return value or output file location, which are not covered by an output schema.
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 for missing parameter docs. It adds meaning only for frames_dir by specifying 'numbered PNG frames'; fps and duration are left entirely to their names and defaults, with no explanation of how they control the output.
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 states a specific action ('Combine'), a precise input ('numbered PNG frames'), and a concrete output ('H.264 mp4'), which clearly distinguishes this tool from the sibling generation and upload tools. 'YouTube-ready as-is' adds useful output context.
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 implies when to use the tool: when you have numbered PNG frames and want a video file. However, it does not explicitly mention when not to use it or name alternatives such as upload_to_youtube for the upload step.
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 usefully discloses the output format (PNG frames), the input type (GLB), and an external requirement (Blender). However, it does not describe side effects like file output locations, runtime, failure modes, or whether existing files are overwritten.
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 compact and front-loaded with the core action in the first sentence. The second sentence is slightly insider-y with 'BoTTube' but still concise and adds rationale for the default resolution.
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 no annotations, no output schema, and multiple sibling pipeline tools, the description is incomplete. It gives high-level purpose and one prerequisite, but an agent is left guessing about output paths, return values, frame count behavior, and how this tool fits into the broader frames-to-video/YouTube pipeline.
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 partially does by implying glb_path and mentioning '1080²' for resolution, but the frames parameter is not explained at all, and the description does not clarify parameter relationships or units. This is insufficient for three parameters with zero 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 opens with a specific verb, resource, and output format: 'Render a GLB as a 360° turntable to PNG frames.' It clearly distinguishes this tool from siblings like frames_to_video and generate_3d_model, and adds the Blender dependency as a distinguishing prerequisite.
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 gives clear context: it is for turntable-style rendering of GLB files into PNG frames, and it notes that Blender is required. It does not explicitly name when-not-to-use or alternatives, but the context is strong enough for an agent to infer appropriate invocation.
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 transparency burden. It does disclose the core behavior (image in, .glb out) and the return shape, which is useful, but it omits whether the operation is asynchronous, whether it blocks until the Meshy task completes, and what happens on failure.
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?
A single compact sentence front-loads the main purpose and then conveys the return value. There is no filler or repetition of schema titles.
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?
The tool has six parameters, no output schema, and no annotations, but the description covers only the input and coarse output. It lacks guidance on the optional parameters, polling/task behavior, and how to chain it with siblings such as get_meshy_task_status or render_turntable.
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%, so the description must compensate. It adds meaning only for the image parameter (public URL or local file path); timeout, enable_pbr, should_remesh, should_texture, and texture_prompt are left unexplained by both schema and 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 names a specific transformation ('Image-to-3D'), the accepted input type (photo/render via public URL or local file path), the output format (textured .glb), and the return payload (local path plus Meshy task id). This is specific enough to distinguish it from siblings like generate_3d_model or generate_3d_from_images.
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?
It clearly indicates when this tool applies: when the user has a single photo/render as input rather than a text prompt or multiple images. It does not explicitly name sibling alternatives or exclusion conditions, but the input-type context is unambiguous.
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 are provided, so the description carries the full burden. It does disclose that a new variant is produced and the .glb path is returned, but it omits important behavior like whether the task is asynchronous, whether the original model is modified, or whether any polling is required. Some useful context, but not complete.
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 efficient sentences with no filler. The core action is front-loaded, and the output path is stated at the end, making it easy to parse.
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?
No annotations or output schema exist, so the description is the only guide. It covers the primary workflow and output, but misses two parameters, fails to state whether exactly one source is required, and says nothing about asynchronous execution or status checking. This is a significant gap for a 6-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates for four of six parameters by explaining their roles and 'or' relationships. It ignores timeout and enable_pbr, leaving their purpose unclear, so compensation is only partial.
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 'Re-texture' and resource 'existing model', clearly distinguishing it from generation, rigging, and animation siblings. It also names the input modes and output path, so an agent understands exactly what the tool does.
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 gives clear context: use this when you want a new variant of an existing model. It also explains the either/or relationships for source and style parameters, which is useful guidance. However, it does not explicitly mention alternatives or conditions when not to use it.
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 burden. It discloses inputs and that it returns a rig_task_id, implying an asynchronous task, but it does not say that the returned ID must be polled/used with a status tool or what side effects occur beyond creating the rig task.
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 short sentences, front-loaded with the action, then source identification, then return value. Every sentence earns its place; no filler or repeated schema metadata.
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?
The core call is understandable: pass a prior task ID or public URL and receive a rig_task_id. However, there are no annotations or output schema, and the description omits whether at least one of the two identifiers is required, what height_meters does, and how to follow up on the returned task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 clarifies the meaning and relationship of input_task_id and model_url, but it leaves timeout and height_meters completely unexplained, so an agent knows two of four parameters well.
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 names a specific verb and resource ('Auto-rig a humanoid model for animation') and distinguishes the outcome from generation or animation siblings by specifying the returned rig_task_id. It is immediately clear this is the rigging stage in the pipeline.
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?
It gives explicit input alternatives ('input_task_id (a prior Meshy generation) or a public model_url'), which tells the agent how to identify the model. It does not explicitly exclude cases or direct to a sibling like animate_model, but the context is clear enough.
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 burden of behavioral disclosure. It does reveal the conditional download side effect ('on success'), which is useful. However, it does not describe what happens for failed or pending tasks, or what the returned status payload contains.
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?
A single, front-loaded sentence with no filler. It conveys the core purpose and the optional behavior efficiently.
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?
For a two-parameter status tool, the description is largely sufficient. It names the resource, the action, and the optional download behavior. Minor omissions like result format and failure behavior prevent a perfect score, especially without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 does clarify that 'download' triggers a .glb download on success, and 'a Meshy task' ties back to task_id. But task_id itself is not explicitly described beyond the schema title.
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?
Description uses a specific verb ('inspect') with a specific resource ('a Meshy task') and adds the optional side effect of downloading the .glb on success. This clearly distinguishes the tool from generation, rendering, animation, and upload siblings.
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 this tool is used to inspect a task created by generation workflows and optionally fetch its result. It states a clear context, but does not explicitly name siblings or state when not to use it.
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 provided, the description carries the full behavioral burden. It discloses that the tool blocks until ready, runs through preview and refine stages, applies textures, and returns the local .glb path and Meshy task IDs. This is solid behavioral context, though it omits failure modes or side effects.
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?
The description is three tightly written sentences with no filler. Core purpose is front-loaded, and pipeline details, parameter clarifications, and return information each earn their place.
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 6-parameter tool with no annotations and no output schema, the description covers key return values and blocking behavior, but leaves several parameters unexplained and provides no usage constraints or examples. It is adequate but has clear information gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 explains enable_pbr and texture_prompt, and implicitly covers prompt, but leaves timeout, art_style, and should_remesh undocumented. The partial coverage is helpful but not sufficient for all six parameters.
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 a specific verb and resource: 'Generate a 3D model from a text prompt via Meshy.ai'. The preview→refine pipeline adds process detail, and the text-prompt input immediately distinguishes it from image-based siblings like generate_3d_from_image and generate_3d_from_images.
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 clearly implies when to use this tool: when you have a text prompt and want a 3D model. It does not explicitly name alternatives or exclusions, but the 'from a text prompt' framing provides enough contextual guidance given sibling names.
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 carries the disclosure burden and does it well: it surfaces OAuth, account ownership, default privacy, the COPPA flag, and the fact that any local path will be published to YouTube. It doesn't cover every side effect, such as return value or reversibility, but the meaningful behavioral cautions are present.
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?
Compact and well-organized: one-sentence purpose, then parameter-specific notes, then a deliberate safety note. No redundant language or restatement of the schema.
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?
For a state-changing external upload tool without annotations or output schema, it is fairly complete for invocation: auth, path, privacy, COPPA, and the intentional local-file behavior are covered. It lacks explicit return/behavior after upload and category_id semantics, but these don't block a correct basic call.
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 description coverage is 0%, so this description is the only semantic source for parameters. It explains tags format, privacy enum/default, and made_for_kids' COPPA implications. It leaves category_id unaddressed and doesn't elaborate on title/video_path, but those are relatively self-evident and the non-obvious parameters get meaningful definitions.
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 action ('Upload a finished video to YouTube') with the resource and auth context (OAuth), and adds a clarifying note that it uploads an arbitrary local path under the user's own account. This differentiates it from sibling pipeline tools such as image_to_youtube and meshy_to_youtube, which handle generated assets.
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?
Gives clear context for when the tool is appropriate: the video must be finished, and any local path can be uploaded to the user's own YouTube account. It doesn't explicitly list sibling alternatives or exclusion criteria, but the note about publishing videos made elsewhere implies the intended scope, so the context is clear.
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-youtube-mcp MCP server](https://glama.ai/mcp/servers/Scottcjn/meshy-youtube-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Scottcjn/meshy-youtube-mcp)

Score Badge

Copy to your README.md:

[![meshy-youtube-mcp MCP server](https://glama.ai/mcp/servers/Scottcjn/meshy-youtube-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Scottcjn/meshy-youtube-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/Scottcjn/meshy-youtube-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server