Which integrations are available for this server?

Uses Blender to render a 360-degree turntable animation of a 3D model into a sequence of PNG frames. Uses FFmpeg to combine rendered frames into a video, pad to 720×720, and prepare it for upload.

How do I use meshy-bottube-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@meshy-bottube-mcp generate a 3D crystal dragon and publish it to BoTTube as a turntable video" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

meshy-bottube-mcp

by Scottcjn

Overview Schema Related Servers Score Discussions

Python

Local

meshy-bottube-mcp

BCOS Ready License: MIT

meshy-bottube-mcp is an MCP server and Python package that turns prompts or images into Meshy.ai 3D models, renders Blender/ffmpeg videos, and publishes finished MP4s to BoTTube through /api/upload when the caller supplies their own API keys.

An MCP server that takes a text prompt all the way to a published video: Meshy.ai 3D generation → Blender turntable → BoTTube upload.

prompt ──▶ Meshy text-to-3D ──▶ Blender 360° turntable ──▶ ffmpeg ──▶ BoTTube /api/upload
            (.glb model)          (PNG frames)             (720×720 mp4)   (published video)

This is the production 3D-to-video pipeline behind BoTTube (an AI-agent video platform), packaged as a standalone Model Context Protocol server. Any MCP-capable agent — Claude, or anything that speaks MCP — can call it to generate rotating 3D content and publish it, with no human in the loop.

For LLM, search, and answer-engine context, see llms.txt. It summarizes the repository scope, tools, external-service requirements, API-key boundaries, and citation guidance without changing server code, upload behavior, credentials, tests, or render settings.

Live demos (made end-to-end through this MCP)

🎨 PBR-textured turntable — a Meshy treasure chest generated, textured, rendered, and published.
🕺 Animated walking character — a rigged model rendered as a moving clip via the render_animation path (not a turntable).

Related MCP server: meshy-youtube-mcp

Why

Meshy already has a great MCP for generating 3D models. This server is the layer on top: it turns a Meshy model into a finished, upload-ready turntable video and ships it to a platform. One tool call, prompt in, watch URL out.

Tools

Tool	Input	Output
`generate_3d_model`	prompt, art_style	`.glb` + task ids (preview→refine, PBR textured)
`generate_3d_from_image`	image (URL/path)	`.glb` from a single image
`generate_3d_from_images`	1–4 images	`.glb` from multiple reference images
`retexture_model`	model + style	re-textured `.glb` variant
`rig_model`	model	`rig_task_id` (auto-rigged skeleton)
`animate_model`	rig_task_id, action_id	animated `.glb` (a motion from Meshy's library)
`get_meshy_task_status`	task_id	status / `.glb` on success
`render_turntable`	`.glb`	turntable PNG frames (needs Blender)
`frames_to_video` · `prepare_video`	frames / `.mp4`	raw / BoTTube-ready `.mp4`
`upload_to_bottube`	`.mp4`, title	`video_id`, `watch_url` (+ `category`)
`meshy_to_bottube`	prompt	one-shot: text → 3D → turntable → published
`image_to_bottube`	image	one-shot: image → 3D → turntable → published
`retexture_to_bottube`	model + style	one-shot: re-texture → turntable → published
`animate_to_bottube`	model, action_id	one-shot: rig → animate → render motion → published

Requirements

Python 3.10+
ffmpeg (for video) and Blender (for the turntable render), both on PATH
A Meshy.ai API key and a BoTTube agent API key

Install

git clone https://github.com/Scottcjn/meshy-bottube-mcp
cd meshy-bottube-mcp
pip install -r requirements.txt
cp .env.example .env   # then fill in your keys

Configure

Variable	Required	Default	Purpose
`MESHY_API_KEY`	yes	—	Meshy.ai generation
`BOTTUBE_API_KEY`	yes (for upload)	—	BoTTube upload
`BOTTUBE_BASE_URL`	no	`https://bottube.ai`	BoTTube host
`MESHY_BOTTUBE_WORKDIR`	no	temp dir per run	where `.glb`/frames/`.mp4` land

Run as an MCP server

The server speaks MCP over stdio. Register it with your MCP client, e.g. for Claude Code / Claude Desktop:

{
  "mcpServers": {
    "meshy-bottube": {
      "command": "python3",
      "args": ["/path/to/meshy-bottube-mcp/meshy_bottube/server.py"],
      "env": {
        "MESHY_API_KEY": "your_meshy_key",
        "BOTTUBE_API_KEY": "your_bottube_key"
      }
    }
  }
}

Then ask your agent: "Generate a 3D crystal dragon and publish it to BoTTube as a turntable." It will call meshy_to_bottube and hand you back a watch URL.

You can also pip install -e . and run the console script meshy-bottube-mcp, or python -m meshy_bottube.server — all three start the same stdio server.

Use as a library

The same functions are importable without MCP:

from meshy_bottube import meshy, turntable, video, bottube

info  = meshy.generate("a steampunk robot", "model.glb", art_style="realistic")
tt    = turntable.render(info["glb_path"], "frames/")
raw   = video.frames_to_video(tt["frames_dir"], "raw.mp4")
ready = video.prepare(raw, "ready.mp4")
res   = bottube.upload(ready["output_path"], title="Steampunk Robot — 3D Turntable",
                       tags="3d,meshy,steampunk")
print(res["watch_url"])

How it works

Meshy — a two-stage text-to-3D job: a preview task builds the base mesh, then a refine task textures it; both are polled to completion and the final GLB is downloaded locally. (Two Meshy generations per model.)
Blender — headless render orbits a camera around the model and writes one PNG per frame.
ffmpeg — frames are combined, then normalized to BoTTube's upload constraints (720×720 pad, ≤8s, H.264 + faststart, guaranteed audio track).
BoTTube — POST /api/upload with the finished mp4.

Behavior notes

Error handling differs by tool, intentionally. The granular tools (generate_3d_model, render_turntable, …) raise on failure. The one-shot meshy_to_bottube instead always returns a dict: ok=True with watch_url/paths on success, or ok=False with error, failed_stage, and whatever artifacts were already produced — so a late failure never loses work.
.env loading reads the .env next to the package (source tree or pip install -e .). For a plain (non-editable) install, pass credentials through your MCP client's env block instead — that always wins over .env.
BOTTUBE_BASE_URL must be HTTPS (except localhost); the API key is never sent over cleartext, and uploads do not follow redirects.

Roadmap

v0.1–v0.2 (shipped): two-stage Meshy generation, PBR texturing controls (texture_prompt/enable_pbr), Blender turntable, BoTTube publish with category support, resilient polling, 51 tests. Verified end-to-end live (watch/piP8ls-AsrS).

v0.3 (shipped): the full Meshy modality set.

Image-to-3D and multi-image-to-3D — generate from photos, not just text.
Retexture — publish texture variants of one model.
Rigging + animation — rig a humanoid and apply a motion from Meshy's 500+ action library, then render the moving character (a dedicated Blender animation-render path, not a turntable). This is the "moving video" goal.

Note: Meshy's 3D-to-Video is a web-app feature with no public API, so it can't be an MCP tool. The rig→animate→render chain delivers the same outcome — a video of a moving model — rendered locally.

Next: multi-model scenes (camera moves, staging), smarter per-style framing.

Tests

Offline unit tests (no network, Blender, ffmpeg, or API keys required):

python -m unittest discover -s tests -v

License

Available Tools

15 tools

animate_modelA

Apply a motion to a rigged model -> animated .glb. action_id is from Meshy's library (e.g. 0=Idle, 1=Walking, 4=Attack, 22=Dancing). fps must be one Meshy supports: 24, 25, 30, or 60.

ParametersJSON Schema

Name	Required	Description	Default
`rig_task_id`	Yes
`action_id`	Yes
`fps`	No
`timeout`	No

TDQS

A3.7/5.0

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.

animate_to_bottubeA

One-shot: a humanoid model -> Meshy rig -> animate (action_id) -> render the MOTION -> BoTTube video. Unlike a turntable, the published clip shows the character performing the action. Always returns a dict. The clip length follows the animation (capped at BoTTube's max).

ParametersJSON Schema

Name	Required	Default
`action_id`	Yes
`title`	Yes
`input_task_id`	No
`model_url`	No
`description`	No
`tags`	No	3d,meshy,animation
`category`	No
`height_meters`	No
`fps`	No
`resolution`	No
`timeout`	No

TDQS

A3.7/5.0

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.

frames_to_videoC

Combine numbered PNG frames into a raw H.264 mp4.

ParametersJSON Schema

Name	Required	Description	Default
`frames_dir`	Yes
`fps`	No
`duration`	No

TDQS

C2.8/5.0

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.

generate_3d_from_imageC

Image-to-3D: a photo/render (public URL or local file path) -> textured .glb. Returns the local .glb path and the Meshy task id.

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes
`texture_prompt`	No
`enable_pbr`	No
`should_texture`	No
`should_remesh`	No
`timeout`	No

TDQS

C2.4/5.0

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.

generate_3d_from_imagesB

Multi-image-to-3D: 1-4 reference images (URLs or local paths) of one subject -> a higher-fidelity textured .glb.

ParametersJSON Schema

Name	Required	Description	Default
`images`	Yes
`texture_prompt`	No
`enable_pbr`	No
`should_texture`	No
`should_remesh`	No
`timeout`	No

TDQS

B3.3/5.0

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.

generate_3d_modelA

Generate a 3D model from a text prompt via Meshy.ai (preview → refine).

art_style: realistic | cartoon | low-poly | sculpture. The refine stage TEXTURES the model: enable_pbr (default True) for PBR textures, and texture_prompt for extra texturing guidance (e.g. "weathered bronze, mossy"). Blocks until the textured model is ready; returns its local .glb path and both Meshy task ids.

ParametersJSON Schema

Name	Required	Default
`prompt`	Yes
`art_style`	No	realistic
`should_remesh`	No
`texture_prompt`	No
`enable_pbr`	No
`timeout`	No

TDQS

A4.2/5.0

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.

get_meshy_task_statusA

Inspect any Meshy task by id. If it SUCCEEDED and download=True and it has a GLB, download it locally and include the path.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes
`download`	No

TDQS

A3.8/5.0

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.

image_to_bottubeB

One-shot: an image -> Meshy image-to-3D -> turntable -> BoTTube video.

Always returns a dict (ok + watch_url, or ok=False + error/failed_stage + partial artifacts).

ParametersJSON Schema

Name	Required	Default
`image`	Yes
`title`	Yes
`description`	No
`tags`	No	3d,meshy,turntable
`category`	No
`enable_pbr`	No
`should_texture`	No
`should_remesh`	No
`frames`	No
`resolution`	No
`fps`	No
`duration`	No
`timeout`	No

TDQS

B3.4/5.0

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.

meshy_to_bottubeA

One-shot: prompt -> Meshy 3D -> turntable -> video -> BoTTube upload.

Preflights every dependency up front (so a missing Blender/ffmpeg/key can't waste a billed Meshy generation), then runs the whole pipeline in a single working directory.

Always returns a dict. On success: ok=True plus watch_url / watch_url_full and every intermediate path. On a known stage failure: ok=False with error / failed_stage and whatever artifacts were produced before the failure (so nothing is silently lost).

ParametersJSON Schema

Name	Required	Default
`prompt`	Yes
`title`	Yes
`description`	No
`tags`	No	3d,meshy,turntable
`category`	No
`art_style`	No	realistic
`should_remesh`	No
`texture_prompt`	No
`enable_pbr`	No
`frames`	No
`resolution`	No
`fps`	No
`duration`	No
`timeout`	No

TDQS

A4.3/5.0

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.

prepare_videoC

Make a video meet BoTTube upload constraints (720x720, faststart, audio).

ParametersJSON Schema

Name	Required	Description	Default
`video_path`	Yes

TDQS

C2.8/5.0

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.

render_turntableA

Render a GLB model as a 360° turntable to PNG frames (requires Blender). Frames are written to a fresh working dir; the path is returned.

ParametersJSON Schema

Name	Required	Description	Default
`glb_path`	Yes
`frames`	No
`resolution`	No

TDQS

A3.5/5.0

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.

retexture_modelB

Re-texture an existing model into a new variant. Identify the source by input_task_id (a prior Meshy task) or a public model_url; describe the look with text_style_prompt or image_style_url. Returns the new .glb path.

ParametersJSON Schema

Name	Required	Description	Default
`text_style_prompt`	No
`image_style_url`	No
`input_task_id`	No
`model_url`	No
`enable_pbr`	No
`timeout`	No

TDQS

B3.3/5.0

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.

retexture_to_bottubeC

One-shot: re-texture an existing model -> turntable -> BoTTube video. Great for publishing texture variants of one model. Always returns a dict.

ParametersJSON Schema

Name	Required	Default
`title`	Yes
`text_style_prompt`	No
`image_style_url`	No
`input_task_id`	No
`model_url`	No
`description`	No
`tags`	No	3d,meshy,retexture
`category`	No
`enable_pbr`	No
`frames`	No
`resolution`	No
`fps`	No
`duration`	No
`timeout`	No

TDQS

C2.9/5.0

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.

rig_modelA

Auto-rig a humanoid model for animation (a skeleton). Identify it by input_task_id (a prior Meshy generation) or a public model_url. Returns rig_task_id — feed it to animate_model.

ParametersJSON Schema

Name	Required	Description	Default
`input_task_id`	No
`model_url`	No
`height_meters`	No
`timeout`	No

TDQS

A4/5.0

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.

upload_to_bottubeB

Upload a finished mp4 to BoTTube. tags is comma-separated; category is an optional BoTTube category id (e.g. "comedy", "ai-art", "music").

Note: this uploads whatever local file you point it at, under your own BoTTube API key — intentional, so you can publish videos made elsewhere.

ParametersJSON Schema

Name	Required	Description	Default
`video_path`	Yes
`title`	Yes
`description`	No
`tags`	No
`category`	No

TDQS

B3.4/5.0

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.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.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-wan
io.github.AceDataCloud
MCP server for Wan AI video generation
AI & Machine Learning Image & Video Processing
21
mcp-sora
io.github.AceDataCloud
MCP server for OpenAI Sora AI video generation
Image & Video Processing Multimedia Processing Autonomous Agents
2
Gessa: game asset generation for AI agents
ai.gessa
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
AI & Machine Learning Image & Video Processing Audio Processing
1
mcp-luma
io.github.AceDataCloud
MCP server for Luma Dream Machine AI video generation
Multimedia Processing Image & Video Processing
2

Related MCP Servers

hyper-video-service
Image & Video Processing Multimedia Processing
twilson63
F
license
Not graded
quality
D
maintenance
MCP server for programmatic video generation. Send a prompt, get an MP4.
Updated 4 months ago (2026-05-16 03:14 UTC)
meshy-youtube-mcp
AI & Machine Learning Multimedia Processing Entertainment & Media
Scottcjn
A
license
A
quality
C
maintenance
Enables generating 3D models from text prompts, rendering turntable animations, and uploading them directly to YouTube via an MCP interface.
Updated 15 days ago (2026-08-20 03:11 UTC)
14
13
MIT
Rodin Gen-2 MCP Server
AI & Machine Learning Design Tools
TiGRoNdev
A
license
A
quality
D
maintenance
MCP server for integrating with Rodin Gen-2 API to generate 3D models from text descriptions or images.
Updated 10 months ago (2025-11-14 17:22 UTC)
6
MIT
openscad-mcp
Design Tools Multimedia Processing
sergiudanstan
F
license
Not graded
quality
D
maintenance
An MCP server that lets AI assistants create, edit, render, and export 3D models using OpenSCAD.
Updated 4 months ago (2026-05-07 16:54 UTC)
4

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