Rodin Gen-2 MCP Server

by TiGRoNdev

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

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

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description 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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![RodinGen2MCP MCP server](https://glama.ai/mcp/servers/TiGRoNdev/RodinGen2MCP/badges/card.svg)](https://glama.ai/mcp/servers/TiGRoNdev/RodinGen2MCP)

Score Badge

Copy to your README.md:

[![RodinGen2MCP MCP server](https://glama.ai/mcp/servers/TiGRoNdev/RodinGen2MCP/badges/score.svg)](https://glama.ai/mcp/servers/TiGRoNdev/RodinGen2MCP)

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