meshy-bottube-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
Disambiguation5/5
Each tool has a clearly distinct purpose: individual generation tools (image, multi-image, text), retexturing, rigging, animation, rendering, video preparation, and upload. The one-shot pipeline tools (e.g., animate_to_bottube, image_to_bottube) are differentiated by their input type and are well-described, leaving no ambiguity.
Naming Consistency5/5
Tool names consistently use snake_case with a verb_noun pattern (e.g., animate_model, render_turntable, upload_to_bottube). Pipeline tools follow a predictable 'X_to_bottube' convention. The naming is uniform and easy to understand for an agent.
Tool Count5/5
With 15 tools, the server covers a complex multi-step workflow (3D generation, rigging, animation, rendering, video creation, upload) without unnecessary bloat. Each tool is justified and the count feels appropriate for its scope.
Completeness5/5
The tool set covers the entire pipeline from text/image to 3D model to video upload, including tasks like retexturing, rigging, animation, status checking, and video processing. There are no obvious gaps that would cause agent failures for its intended use case.
Average 3.4/5 across 15 of 15 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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 provided, the description must disclose all behavioral traits. It only mentions the input/output format and returns a task ID, but does not explain side effects, async nature, permission requirements, or the effect of parameters like 'should_texture', 'enable_pbr', or 'timeout'. This leaves significant behavioral 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 very concise (one short sentence) and front-loads the core purpose. No unnecessary words, but could be restructured to include key parameter details without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the processing flow, return value structure, parameter dependencies, or error handling. The agent would have little context to use the tool correctly.
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 explanation for any of the 6 parameters. It only mentions the 'image' input implicitly, but does not describe 'texture_prompt', 'enable_pbr', 'should_texture', 'should_remesh', or 'timeout'. This fails to help an agent understand parameter semantics.
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 states the tool converts a photo/render (single image) to a textured .glb file, and mentions output format. It implicitly distinguishes from sibling 'generate_3d_from_images' by specifying singular input. However, it could be more explicit about the tool's specific role among many 3D 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like 'generate_3d_model' or 'retexture_model'. It only implies usage for single-image input, but lacks explicit context or exclusion criteria.
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 provided. Description only states basic function without disclosing behaviors like overwriting, missing frames handling, or numbering format expectations.
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?
Single sentence, no wasted words, front-loaded with verb and key details. Efficient but at the cost of missing necessary 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?
Lacks explanation of expected frame naming pattern, output location, and handling of defaults. With no output schema, the agent has minimal context.
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%. The description does not explain any parameters (frames_dir, fps, duration), leaving the agent without guidance on their meaning or format.
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 clearly states verb 'Combine', resource 'numbered PNG frames', and output 'raw H.264 mp4'. It is specific and distinguishes from sibling tools which focus on 3D models and animations.
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 on when to use this tool versus alternatives like prepare_video. No mention of prerequisites or when not to use.
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 provided; description fails to disclose side effects, whether modification is in-place, return format, or permissions needed.
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?
Single sentence, no filler, but could benefit from more structured detail.
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?
Minimal info for a 1-param tool; no explanation of output, process, or assumptions given lack of output schema.
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 coverage 0%; description adds no info about the single parameter 'video_path' beyond its name.
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 transforms a video to meet BoTTube upload constraints (720x720, faststart, audio). Distinguishes from siblings like upload_to_bottube and frames_to_video.
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 on when to use vs alternatives, no explicit context or prerequisites. Only implies it should be used before uploading.
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 fully disclose behavior. It states the tool 'always returns a dict' and is 'one-shot', but does not explain what the dict contains, whether the operation is asynchronous (returning a task ID), or how errors are handled. This leaves critical gaps for an AI agent.
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 concise, with two sentences that efficiently convey the core pipeline and a use case. However, the extreme brevity sacrifices necessary detail for parameter understanding, making it less effective overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 parameters, no output schema, and a complex pipeline (retexture + turntable + upload), the description is severely incomplete. It does not explain which inputs are essential (e.g., model_url or input_task_id), the meaning of video parameters, or the structure of the return value. An agent cannot reliably invoke this tool based solely on the description.
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 there are 14 parameters. The description provides no explanation for any parameter beyond their names. For example, the required 'title' parameter is not elaborated, and parameters like 'frames', 'resolution', 'fps', 'duration' are ambiguous (likely for the video but not specified). The agent cannot determine proper values without additional context.
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 performs a one-shot retexture of an existing model, generates a turntable animation, and produces a BoTTube video. It specifically mentions its use for publishing texture variants, distinguishing it from sibling tools like retexture_model (which likely only retextures) and upload_to_bottube (which uploads existing content).
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 provides a use case ('great for publishing texture variants of one model') but does not specify when to avoid using this tool or suggest alternatives among the many siblings (e.g., animate_to_bottube, image_to_bottube). Usage context is implied but no explicit guidance on selection.
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 exist, so description carries full burden. It discloses input constraints (1-4 images) and output format, but does not mention behavioral traits like processing time, error conditions, or limitations on subject consistency. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with key info, but it omits necessary parameter details, making it under-specified for effective use.
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 (multi-image 3D generation), zero schema coverage, and no output schema, the description is incomplete. It fails to explain parameters or process details, leaving significant gaps.
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 provides no explanations for any of the 6 parameters (e.g., texture_prompt, enable_pbr). The agent cannot infer parameter semantics from the description alone.
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 it converts 1-4 reference images into a textured .glb model, specifying the input constraints (one subject, multiple images) and output format. It distinguishes from sibling 'generate_3d_from_image' by emphasizing multi-image input and higher fidelity.
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 use when multiple images are available for higher quality, implicitly contrasting with single-image tool. However, it lacks explicit 'when not to use' guidance or alternatives for other scenarios.
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 bears full responsibility for behavioral disclosure. It mentions the output format (new .glb path) but does not discuss side effects, synchronization, permissions, rate limits, or error conditions. For a mutation tool, this is insufficient.
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 concise (two sentences, 30 words) and front-loads the primary purpose. Every sentence adds essential value without redundancy.
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 6 parameters (0 required), no output schema, and no annotations, the description is incomplete. It lacks details on parameter behavior, synchronization model, error handling, and constraints, which are critical for correct tool 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%, meaning the description adds no parameter documentation beyond the schema's property names. While it groups parameters into source identifiers and style descriptors, it fails to explain parameters like enable_pbr or timeout, leaving their semantics unclear.
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 action ('re-texture'), the resource ('existing model'), and the outcome ('new variant'). It also specifies the valid sources (input_task_id or model_url) and style inputs (text_style_prompt or image_style_url), making it unambiguous and distinct from sibling tools.
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 provides usage guidance by explaining how to identify the source model and describe the desired look. However, it does not explicitly state when to use this tool over alternatives (e.g., generate_3d_model, rig_model), nor does it mention when not to use it or any prerequisites.
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?
The description discloses the return format (dict with ok+watch_url or error+failed_stage+partial artifacts) and the sequential pipeline steps. However, it does not mention potential side effects, resource usage, or authentication needs. With no annotations, this is moderately helpful but leaves 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 two sentences long, with the first sentence front-loading the main pipeline and the second covering the return type. No unnecessary words, but given the tool's complexity, more detail could be added without sacrificing brevity.
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?
With 13 parameters, no annotations, no output schema, and many siblings, the description is insufficient. It lacks parameter explanations, prerequisites, failure behavior details, and differentiation from siblings like meshy_to_bottube or animate_to_bottube. The return format hint is helpful but incomplete.
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%. The description does not explain any of the 13 parameters (e.g., image, title, enable_pbr, frames). It only mentions the pipeline but provides no details about parameter purpose or constraints, failing to compensate for the missing 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 pipeline: image -> Meshy image-to-3D -> turntable -> BoTTube video. This specific verb+resource sequence distinguishes it from siblings that handle only intermediate steps (e.g., generate_3d_from_image, upload_to_bottube).
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 when to use this tool: when you want to go directly from an image to a BoTTube video. It does not explicitly state when not to use it or suggest alternatives, but the pipeline definition provides clear context.
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. The description discloses that the operation uses the user's API key and is intentional for publishing. It does not describe side effects like overwriting or rate limits, but the core behavior is transparent.
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?
Compact two-sentence format. The first sentence states the core action; the second adds a practical note. No extraneous text, though it could list parameters more systematically.
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?
Missing output schema and details on error handling, file size limits, or result feedback. For a 5-parameter tool with no annotations, the description is adequate but not thorough.
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 coverage is 0%. The description explains 'tags' is comma-separated and 'category' with examples, adding value. However, 'video_path', 'title', and 'description' are not elaborated, leaving them to rely on bare schema.
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 states it uploads a finished mp4 to BoTTube. It specifies the file format and destination, but does not explicitly differentiate from sibling tools like animate_to_bottube or image_to_bottube.
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 mentions uploading local files under your own API key, implying use when you have a local mp4. However, it lacks when-not-to-use guidance or explicit alternatives, leaving some ambiguity.
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, description carries full burden. Discloses Blender dependency, writes to fresh temp dir (no side effects), returns path. Does not detail any side effects or edge cases, but core behavior is 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?
Two efficient sentences. Front-loaded with purpose and prerequisite, followed by output behavior. No wasted words.
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?
Lacking parameter descriptions for 'frames' and 'resolution', and no output schema or return value detail beyond 'path is returned'. Incomplete for a 3-parameter tool with no annotations.
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 description adds no parameter details. 'GLB model' hints at 'glb_path' but does not explain 'frames' or 'resolution'. Agent cannot understand parameter semantics from description alone.
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 verb 'Render', resource 'GLB model', output 'PNG frames as 360° turntable', and prerequisite 'requires Blender'. Distinct among sibling tools like 'animate_model' which may produce video or other outputs.
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?
Mentions Blender requirement and output location, but does not provide explicit when-to-use vs alternatives or exclude scenarios. Context is implied but not articulated.
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 input constraints and implies the output is an animated .glb, but it does not mention important behaviors like asynchronous processing, authentication needs, or whether the tool is destructive. The description adds some context but leaves gaps.
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 concise sentences with no unnecessary words. It front-loads the primary action and then provides specific parameter details. Every sentence adds value.
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 no output schema and 4 parameters, the description covers the core functionality but lacks details on return format, asynchronous behavior, and the role of rig_task_id. The context of sibling tools suggests async execution but is not explained.
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 coverage is 0%, so the description must explain parameters. It explains action_id (with examples) and fps (with supported values), but it does not explain rig_task_id (a required parameter) or timeout. This leaves half of the parameters undocumented in 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 clearly states the tool applies a motion to a rigged model to produce an animated .glb file. It specifies the action_id parameter with examples from Meshy's library and fps constraints, making the purpose unambiguous. It distinguishes from sibling tools like animate_to_bottube by mentioning the output format.
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 provides some usage guidance by enumerating valid action_ids and fps values, but it does not explicitly state when to use this tool versus alternatives like rig_model or animate_to_bottube. It lacks when-not scenarios and prerequisites such as requiring a previously rigged model.
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 adds some behavioral context: it always returns a dict, and the clip length is capped. However, it lacks information on side effects, authentication, or error handling, which are important for a multi-step creation 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?
The description is extremely concise—two sentences that front-load the core functionality and key constraints. Every sentence provides valuable information without redundancy.
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 (11 parameters, combined pipeline, no output schema), the description is incomplete. It fails to explain the return dict structure, required prerequisites, or the meaning of most parameters, leaving significant gaps for correct usage.
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 schema description coverage is 0%, and the description only mentions 'action_id' and 'title' (required), ignoring the other 9 parameters. It does not explain the meaning or usage of optional parameters like 'model_url', 'fps', or 'resolution', leaving the agent without necessary guidance.
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: it takes a humanoid model, applies Meshy rig, animates with a specified action_id, renders the motion, and publishes a video to BoTTube. It explicitly distinguishes itself from a turntable, making the function unambiguous.
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 context by comparing the output to a turntable and noting it is a one-shot pipeline. However, it does not explicitly list when to use this tool versus siblings like 'animate_model' followed by 'upload_to_bottube', but the distinction is implied.
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?
The description discloses a conditional side effect (downloading a GLB file) but fails to specify the return value when download conditions are not met, or what happens if the file already exists. With no annotations, the description carries the full burden and provides only partial 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?
The description is a single efficient sentence conveying core purpose and conditional behavior. Every word contributes value, with no redundancy.
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 lacks critical information: what is returned (status object, path), error handling, behavior for pending tasks, and download path details. The agent cannot fully anticipate the tool's output or side effects.
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 the 'download' parameter's effect when true, but barely clarifies 'task_id' beyond 'by id'. The description adds some meaning but not enough for full parameter understanding.
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 clearly states the verb 'inspect' and the resource 'Meshy task by id', making the primary action unambiguous. It also specifies a conditional side effect (download if conditions met), which further defines the tool's 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 implies when to use (checking a task's status, potentially downloading result) but does not explicitly exclude alternatives or mention when not to use. Sibling tools are all different operations, so differentiation is clear.
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 responsibility. It discloses the core behavior (auto-rigging) and input/output flow but does not mention edge cases (e.g., conflicting inputs), error handling, or side effects. Adequate but not exhaustive.
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, no redundancy. Front-loads the purpose, then efficiently details inputs and output linkage. Every sentence is essential.
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 tool with 4 parameters, no required fields, and no output schema, the description captures the primary workflow and connects to a sibling tool. However, the lack of explanation for height_meters and timeout reduces completeness slightly.
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 coverage is 0%, so description must compensate. It explains input_task_id and model_url as identification methods, adding meaning to these parameters. However, height_meters and timeout are not mentioned, leaving gaps in parameter understanding.
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 auto-rigs a humanoid model for animation, specifies inputs (input_task_id or model_url), and output (rig_task_id), distinguishing it from sibling tools like animate_model by directly linking the output.
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 clear context on how to identify the model (via prior task ID or public URL) and directs the agent to feed the result to animate_model. Lacks explicit when-not-to-use or alternatives but is sufficient given sibling differentiation.
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 burden. It discloses the blocking behavior, the two-stage process (preview then refine), details about texturing (enable_pbr, texture_prompt), and the return of local .glb path and task IDs. This is rich context, though it does not cover failure modes or timeout handling.
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 concise and well-structured, using line breaks and bullet-style listing for art_style and texture options. Every sentence adds value: purpose, workflow, parameter hints, and return info. No superfluous text.
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 the absence of output schema, the description helpfully specifies the return values. It covers the main workflow and key parameters. However, it omits details on error handling, the meaning of task IDs, and the 'should_remesh' parameter. For a tool with 6 parameters and no output schema, it is mostly complete but could be improved.
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 the description must compensate. It explains prompt (required), art_style (lists values), enable_pbr and texture_prompt for refinement, and timeout (blocks). However, it fails to explain the 'should_remesh' parameter, which is present in the schema but absent from the description, leaving a gap.
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 generates a 3D model from a text prompt via Meshy.ai, with a preview-to-refine workflow. It lists art style options and distinguishes from sibling tools like generate_3d_from_image or animate_model by focusing on text-to-3D generation.
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 briefly mentions the refine stage textures the model and that the tool blocks until ready, but does not explicitly state when to use this tool versus alternatives (e.g., generate_3d_from_image) or provide contraindications. The context of sibling tools helps, but direct guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden. It discloses preflight dependency checks, single working directory usage, return dict structure, success/failure details, and artifact preservation. This is comprehensive behavioral disclosure.
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 extremely concise for the complexity, using bullet points and short sentences. It front-loads the pipeline summary and then adds essential behavioral details without redundancy.
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 14 parameters and no output schema, the description covers the return value well and explains the pipeline flow. However, it lacks parameter semantics and could include a note on required inputs. Still, it is largely complete for a complex 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?
The description adds no information about the 14 parameters beyond the schema. With 0% schema description coverage, the description should compensate by explaining key parameters like art_style, texture_prompt, frames, etc., but it does not.
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: a one-shot pipeline from text prompt to BoTTube upload, passing through Meshy 3D, turntable rendering, and video generation. It distinguishes itself from sibling tools by combining multiple steps into a single invocation.
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 when to use this tool (for a full pipeline) and provides behavioral context (preflights, error handling). However, it does not explicitly contrast with alternatives like using individual steps, but the unique combination makes the use case 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-bottube-mcp MCP server](https://glama.ai/mcp/servers/Scottcjn/meshy-bottube-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Scottcjn/meshy-bottube-mcp)

Score Badge

Copy to your README.md:

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

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