How do I use Rodin Gen-2 MCP Server?

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., "@Rodin Gen-2 MCP Server Create a 3D model of a futuristic robot in glb format" 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.

Rodin Gen-2 MCP Server

by TiGRoNdev

Overview Schema Related Servers Score Discussions

Python

Local

Rodin Gen-2 MCP Server

MCP (Model Context Protocol) сервер для интеграции с Rodin Gen-2 API - мощным сервисом генерации 3D моделей.

Возможности

🎨 Text-to-3D: Генерация 3D моделей из текстовых описаний
🖼️ Image-to-3D: Создание 3D моделей из изображений (до 5 изображений)
📊 Проверка статуса: Отслеживание прогресса генерации
💾 Загрузка результатов: Автоматическое скачивание готовых 3D моделей
🔧 Гибкая настройка: Поддержка различных форматов, материалов и параметров качества
🚀 MCP протокол: Интеграция с любыми MCP-совместимыми клиентами (Claude Desktop, и др.)

Related MCP server: universal-image-mcp

Требования

Python 3.10 или выше
API ключ Rodin Gen-2 (получить здесь)
uv (рекомендуется) или pip

Установка

Вариант 1: Использование uv (рекомендуется)

Установите uv:

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

Использование

Добавьте в конфигурацию любого IDE, поддерживающего MCP протокол:

{
  "mcpServers": {
    "rodin-gen2-mcp": {
      "command": "uvx",
      "args": ["rodin-gen2-mcp"],
      "env": {
        "RODIN_API_KEY": "your_api_key_here"
      }
    }
  }
}

Доступные инструменты

1. generate_3d_text_to_3d

Генерирует 3D модель из текстового описания.

Параметры:

prompt (обязательно): Текстовое описание модели
seed: Seed для воспроизводимости (0-65535)
geometry_file_format: Формат файла (glb, usdz, fbx, obj, stl)
material: Тип материала (PBR, Shaded, All)
mesh_simplify: Упростить меш (true/false)
quality_override: Количество полигонов
bbox_condition: Размеры bounding box [width, height, length]

Пример в Claude:

Создай 3D модель футуристического робота

2. generate_3d_image_to_3d

Генерирует 3D модель из изображения(й).

Параметры:

image_paths (обязательно): Список путей к изображениям (до 5)
prompt: Дополнительное текстовое описание
use_original_alpha: Использовать альфа-канал
seed: Seed для воспроизводимости (0-65535)
geometry_file_format: Формат файла (glb, usdz, fbx, obj, stl)
material: Тип материала (PBR, Shaded, All)
mesh_simplify: Упростить меш (true/false)
quality_override: Количество полигонов
condition_mode: Режим для множественных изображений
bbox_condition: Размеры bounding box [width, height, length]

Пример в Claude:

Создай 3D модель из изображения C:\Users\user\image.jpg

3. check_task_status

Проверяет статус задачи генерации.

Параметры:

task_uuid (обязательно): UUID задачи

Пример в Claude:

Проверь статус задачи 123e4567-e89b-12d3-a456-426614174000

4. download_result

Загружает готовую 3D модель.

Параметры:

task_uuid (обязательно): UUID завершенной задачи
output_path: Путь для сохранения (опционально)

Пример в Claude:

Загрузи результат задачи 123e4567-e89b-12d3-a456-426614174000

Примеры использования

Полный рабочий процесс

Генерация из текста:

Создай 3D модель красного спортивного автомобиля в формате fbx

Проверка статуса:

Проверь статус задачи <UUID из предыдущего ответа>

Загрузка результата:

Загрузи результат задачи <UUID>

Генерация из изображения

Создай 3D модель из этих изображений:
- C:\Users\user\front.jpg
- C:\Users\user\side.jpg
с материалом PBR и упрощением меша

Поддерживаемые форматы

Форматы файлов

GLB (по умолчанию) - GL Transmission Format Binary
USDZ - Universal Scene Description
FBX - Filmbox
OBJ - Wavefront Object
STL - Stereolithography

Типы материалов

PBR (по умолчанию) - Physically Based Rendering
Shaded - Затененный материал
All - Все типы материалов

Цены

Базовая стоимость: 0.5 кредита за генерацию
HighPack addon: +1 кредит за генерацию

Дополнительные параметры бесплатны.

Устранение неполадок

Сервер не отображается в Claude Desktop

Проверьте правильность путей в claude_desktop_config.json
Убедитесь, что используете абсолютные пути
Перезапустите Claude Desktop полностью (Quit, не просто закрытие окна)
Проверьте логи: ~/Library/Logs/Claude/mcp*.log (macOS) или %APPDATA%\Claude\logs\ (Windows)

Ошибка "RODIN_API_KEY не установлен"

Убедитесь, что файл .env существует в корне проекта
Проверьте, что в .env правильно указан ключ: RODIN_API_KEY=your_key
Перезапустите сервер

Ошибки при генерации

Проверьте интернет-соединение
Убедитесь, что API ключ действителен
Проверьте баланс кредитов в вашем аккаунте Rodin
Для Image-to-3D: убедитесь, что пути к изображениям корректны

Разработка

Установка зависимостей для разработки

pip install -e ".[dev]"

Запуск тестов

Проект покрыт комплексным набором unit и integration тестов.

Запуск всех тестов

pytest

Запуск с покрытием кода

pytest --cov=. --cov-report=html --cov-report=term

HTML отчет будет доступен в htmlcov/index.html

Использование скрипта запуска

# Базовый запуск
python run_tests.py

# С покрытием кода
python run_tests.py --coverage

# С HTML отчетом
python run_tests.py --coverage --html

# Подробный вывод
python run_tests.py -v

# Конкретный тест
python run_tests.py -t tests/test_main.py

Покрытие кода

Тесты покрывают:

✅ FastAPI сервер (main.py)
- Все эндпоинты
- RodinClient класс
- Обработка ошибок
✅ MCP сервер (rodin_gen2_server.py)
- Все MCP инструменты
- HTTP запросы к API
- Валидация параметров
- Фоновая загрузка файлов
- Обработка ошибок и edge cases

Подробная документация: tests/README.md

Форматирование кода

black rodin_gen2_server.py main.py
ruff check rodin_gen2_server.py main.py

CI/CD

Проект включает GitHub Actions workflow для автоматического запуска тестов на:

Ubuntu, Windows, macOS
Python 3.10, 3.11, 3.12

См. .github/workflows/tests.yml

Ссылки

Лицензия

MIT

Available Tools

6 tools

check_download_result_statusA

Проверяет прогресс фоновой загрузки, запущенной start_download_result.

Удобен для LLM: его можно вызывать периодически, чтобы отслеживать статус фоновой загрузки без долгих блокировок одного запроса.

Args: task_id: Идентификатор задачи загрузки, полученный из start_download_result.

Returns: Человекочитаемое сообщение со статусом задачи и, при завершении, списком файлов.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that it returns a human-readable status message and list of files on completion, and implies non-blocking behavior. However, it does not explicitly state idempotency, side effects, or potential rate limits, leaving some 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 concise, front-loaded with the main purpose, and includes an Args section in a clear structure. Every sentence adds value with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown but indicated), the description's mention of a human-readable message and file list is sufficient. It covers the tool's simple purpose and references siblings, making it complete for a polling tool.

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?

The input schema has one parameter with 0% description coverage. The description adds meaning by explaining that task_id is obtained from start_download_result, which is clear and sufficient for a single parameter.

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 it checks the progress of a background download started by start_download_result, using a specific verb and resource, and it distinguishes itself from siblings like check_task_status and start_download_result.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It notes that the tool is convenient for LLM to call periodically to track status without long blocking, providing clear usage context. It does not explicitly state when not to use it, but implies its role in polling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_task_statusA

Проверяет статус задачи генерации

Args: subscription_key: Subscription key задачи (jobs.subscription_key из ответа generate_3d_*)

Returns: Текущий статус всех подзадач

ParametersJSON Schema

Name	Required	Description	Default
`subscription_key`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that it returns the current status of all subtasks and ties the parameter to generate_3d_* responses. It does not cover error handling, idempotency, or rate limits.

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, with two short sentences for purpose and two lines for args/returns. No wasted words.

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?

The tool is simple with one parameter and an output schema exists, reducing the need for extensive return descriptions. The description covers purpose, parameter source, and return summary. Could mention error states but is adequate for a status check.

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 coverage is 0%, so the description must add meaning. It explains that subscription_key is the key from generate_3d_* responses, adding context beyond the schema's bare name. More detail on format would be beneficial.

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 uses a specific verb 'Проверяет' (checks) and resource 'статус задачи генерации' (status of generation task). It distinguishes from sibling tools by specifying generation tasks and referencing subscription keys from generate_3d_* responses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after calling generate_3d_* tools by specifying the source of subscription_key. However, it does not explicitly state when not to use this tool or mention alternatives like check_download_result_status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

download_resultA

Синхронно загружает результаты генерации 3D модели по UUID задачи.

Этот инструмент блокирующий: LLM дожидается завершения загрузки в рамках одного вызова. Обычно предпочтительнее использовать пару start_download_result + check_download_result_status, но download_result удобен для простых сценариев и небольших объёмов данных.

Args: task_uuid: UUID задачи из generate_3d_* (поле uuid, не subscription_key). output_dir: Папка для сохранения файлов; по умолчанию — текущая директория.

Returns: Человекочитаемое сообщение с директорией, суммарным размером и списком загруженных файлов либо сообщение об ошибке.

ParametersJSON Schema

Name	Required	Description	Default
`task_uuid`	Yes
`output_dir`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must cover behavioral traits. It does so by stating 'This tool is blocking: LLM waits for the download to complete within a single call.' This is key behavior beyond the obvious. Also mentions the return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: first sentence states purpose, then blocking nature, then comparison with alternatives, then parameter descriptions, then return value. All sentences are relevant, though slightly verbose. Front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, download operation), the description covers all necessary aspects: purpose, blocking behavior, alternative usage, parameter details, and return format. It is complete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description adds essential meaning. It clarifies that task_uuid is 'the uuid field from generate_3d_*, not subscription_key' and describes output_dir as 'Folder to save files; default is current directory.' This is highly informative.

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: 'Synchronously downloads the results of 3D model generation by task UUID.' It also distinguishes itself from the sibling tool pair start_download_result + check_download_result_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides guidance on when to use this tool versus the alternative: 'Usually it is preferable to use the pair start_download_result + check_download_result_status, but download_result is convenient for simple scenarios and small data volumes.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_3d_image_to_3dA

Генерирует 3D модель из изображения(й) (Image-to-3D)

Args: image_paths: Список путей к изображениям (до 5 файлов) prompt: Текстовое описание. Опционально (если не указано, будет сгенерировано AI) use_original_alpha: Использовать оригинальный альфа-канал. По умолчанию False seed: Seed для воспроизводимости (0-65535). Опционально geometry_file_format: Формат файла (glb, usdz, fbx, obj, stl). По умолчанию glb material: Тип материала (PBR, Shaded, All). По умолчанию PBR mesh_simplify: Упростить меш. По умолчанию False quality_override: Переопределение качества. Опционально condition_mode: Режим для множественных изображений (concat). По умолчанию concat bbox_condition: Условие bounding box [width, height, length]. Опционально

Returns: UUID задачи для проверки статуса и загрузки результата

ParametersJSON Schema

Name	Required	Default
`image_paths`	Yes
`prompt`	No
`use_original_alpha`	No
`seed`	No
`geometry_file_format`	No	glb
`material`	No	PBR
`mesh_simplify`	No
`quality_override`	No
`condition_mode`	No	concat
`bbox_condition`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description partially covers behavioral traits: it mentions the return value is a UUID for task tracking. However, it does not disclose any side effects, authentication requirements, rate limits, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with 'Args' and 'Returns' sections, front-loading the main purpose. It is somewhat long due to listing all parameters, but each sentence adds information. Could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 10 parameters and no annotations, the description covers the main purpose and parameter details. However, it lacks usage examples, thorough explanations of optional parameters, and behavioral context. It is adequate but not fully comprehensive.

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%, but the description adds meaning beyond the input schema by providing parameter names, defaults, and constraints (e.g., up to 5 files, seed range 0-65535, format options). Some parameters like 'quality_override' and 'bbox_condition' lack detailed explanation, but overall it compensates significantly.

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 'Генерирует 3D модель из изображения(й) (Image-to-3D)', providing a specific verb and resource. It distinguishes from the sibling tool 'generate_3d_text_to_3d' by specifying the input type (image vs text).

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 explicit guidance on when to use this tool versus alternatives. The description implies image-to-3D conversion but does not state when not to use it, prerequisites, or compare with text-to-3D or other siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_3d_text_to_3dA

Генерирует 3D модель из текстового описания (Text-to-3D)

Args: prompt: Текстовое описание 3D модели для генерации seed: Seed для воспроизводимости (0-65535). Опционально geometry_file_format: Формат файла (glb, usdz, fbx, obj, stl). По умолчанию glb material: Тип материала (PBR, Shaded, All). По умолчанию PBR mesh_simplify: Упростить меш. По умолчанию False quality_override: Переопределение качества (количество полигонов). Опционально bbox_condition: Условие bounding box [width, height, length]. Опционально

Returns: UUID задачи для проверки статуса и загрузки результата

ParametersJSON Schema

Name	Required	Default
`prompt`	Yes
`seed`	No
`geometry_file_format`	No	glb
`material`	No	PBR
`mesh_simplify`	No
`quality_override`	No
`bbox_condition`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description adds context by stating the return is a UUID for checking status and downloading, indicating asynchronous behavior. However, it does not disclose rate limits, auth needs, or failure modes beyond what is obvious.

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?

Description is well-structured with separate Args and Returns sections. It is reasonably concise, listing all parameters without excessive verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex generative tool with 7 parameters and no annotations, the description provides the return format (UUID) but does not explicitly outline the asynchronous workflow or the need for polling status. Adequate but missing key workflow context.

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?

With 0% schema description coverage, the description fully compensates by providing brief explanations for each parameter (e.g., seed range, material options, bounding box format). Adds meaning beyond mere names.

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 it generates a 3D model from text (Text-to-3D), using specific verb and resource. It implicitly distinguishes from sibling 'generate_3d_image_to_3d' which does image-to-3D.

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?

Description implies usage for text prompts, but no explicit guidance on when to use this vs alternatives or prerequisites. Context is clear but lacks explicit when-not-to-use or alternative comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_download_resultA

Запускает фоновую загрузку результатов 3D-задачи по её UUID.

Предназначен для LLM-агентов:

Вызывается после того, как генерация завершена (см. check_task_status).
Не блокирует диалог — только стартует фоновую загрузку.
Возвращает идентификатор task_id, который нужно передать в check_download_result_status.

Returns: Человекочитаемое сообщение с task_id фоновой задачи загрузки.

ParametersJSON Schema

Name	Required	Description	Default
`task_uuid`	Yes
`output_dir`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the tool starts a background download (non-blocking), returns a task_id, and specifies the source of task_uuid. It could be more explicit about error handling or idempotency, but the main behavioral traits are covered.

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 well-structured with numbered steps and explicit Args/Returns sections. It is concise with no superfluous information, every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description covers all necessary aspects: purpose, parameters, usage context, and follow-up actions. It is complete for an agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 task_uuid as the UUID from generate_3d_* (not subscription_key) and output_dir as the folder for files with a default. This adds significant meaning beyond the schema's null titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool starts a background download of 3D task results, specifying the verb ('запускает фоновую загрузку') and resource ('результаты 3D-задачи'). It distinguishes from sibling tools like check_download_result_status and generate_3d_* by indicating it is used after generation completion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: after generation is completed (check_task_status). It clarifies the tool is non-blocking and that the returned task_id should be passed to check_download_result_status. This provides clear sequential guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.5Jun 17, 2026
- First observedcheck_download_result_status
- First observedcheck_task_status
- First observeddownload_result
- First observedgenerate_3d_image_to_3d
- First observedgenerate_3d_text_to_3d
- First observedstart_download_result

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a distinct purpose: two generation methods (image-to-3D, text-to-3D), two status checks (task and download), and two download variants (sync and async). No overlap or ambiguity.

Naming Consistency4/5

Tools follow a verb_noun pattern (generate_3d_*, check_*, download_*). Minor inconsistency: check_download_result_status vs check_task_status are slightly different in specificity, but overall predictable.

Tool Count5/5

Six tools cover the core 3D generation workflow—creation, status polling, and retrieval—without unnecessary bloat or missing essentials.

Completeness4/5

The toolset covers the full lifecycle: generate, poll status, download. Missing operations like listing or deleting models are minor gaps, but the pipeline is fully functional.

Maintenance

ActivityInactive

ResponsivenessNo issues

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-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
mcp-wanOAuth
io.github.AceDataCloud
MCP server for Wan AI video generation
AI & Machine Learning Image & Video Processing
21
Gessa: game asset generation for AI agentsOAuth
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-veoOAuth
io.github.AceDataCloud
MCP server for Google Veo AI video generation
Multimedia Processing Image & Video Processing Entertainment & Media
23

Related MCP Servers

Pixal3D-MCP
AI & Machine Learning Image & Video Processing
Lightfielder
F
license
Not graded
quality
B
maintenance
Standalone MCP server for generating high-fidelity 3D assets from a single image using Pixal3D inference.
Updated 4 months ago (2026-05-14 10:00 UTC)
2
-
universal-image-mcp
AI & Machine Learning Image & Video Processing
manu-mishra
A
license
A
quality
D
maintenance
MCP server for multi-provider AI image generation (AWS Bedrock, OpenAI, Google Gemini) enabling image generation, transformation, and editing through a unified interface.
Updated 6 months ago (2026-03-04 19:20 UTC)
4
1
MIT
3D Agent MCP
AI & Machine Learning Image & Video Processing Autonomous Agents
teslaproduuction
A
license
Not graded
quality
A
maintenance
MCP server for generating print-ready 3D models from text descriptions via a multi-agent pipeline, enabling AI assistants to create and optimize STL files.
Updated 2 months ago (2026-06-23 16:04 UTC)
1
MIT
pixmax-mcp
huikku
A
license
A
quality
B
maintenance
MCP server for Pixmax API enabling generation of images, video, text, audio, and 3D across dozens of models like Midjourney, Kling, and ElevenLabs.
Updated a month ago (2026-07-28 00:23 UTC)
10
MIT

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/TiGRoNdev/RodinGen2MCP'

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