Converts GLTF/GLB 3D model files into React Three Fiber JSX components and analyzes model structures, with support for performance optimization, mesh instancing, and texture conversion.
Generates declarative React Three Fiber components from 3D models, including TypeScript definitions, instanced meshes, animation bone layouts, and optimized rendering configurations.
Generates type-safe React components with proper TypeScript definitions when converting 3D models to JSX format.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Three convert this character model to JSX with TypeScript support"
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.
A Model Context Protocol (MCP) server specialized for working with 3D models, specifically GLTF/GLB files. This server provides tools to convert 3D models into React Three Fiber JSX components and analyze model structures.
GLTF/GLB to JSX Conversion: Convert 3D models into reusable React Three Fiber components
Model Structure Analysis: Inspect and debug 3D model hierarchies and properties
Performance Optimization: Support for instancing, mesh simplification, and texture optimization
TypeScript Support: Generate type-safe React components with proper TypeScript definitions
Related MCP server: react-devtools-mcp
gltfjsxConverts GLTF/GLB 3D model files into declarative React (react-three-fiber) JSX components.
Features:
TypeScript definitions generation
Mesh and material instancing for performance
Texture format conversion and optimization
Mesh simplification
Shadow casting/receiving setup
Bone layout for animations
Metadata preservation
get-model-structureAnalyzes and returns the structure of a GLTF/GLB model file as JSON. Useful for debugging complex models and understanding their hierarchy before conversion.
Add this server to your MCP client configuration:
{
"mcpServers": {
"mcp-three": {
"command": "npx",
"args": ["mcp-three"]
}
}
}.gltf - GLTF JSON format
.glb - GLTF Binary format
Converting 3D Models for Web Apps: Transform GLTF/GLB files into optimized React components
Model Debugging: Inspect model structure and properties before integration
Performance Optimization: Generate instanced meshes and optimized textures
Animation Setup: Prepare models with proper bone layouts for animations
This project is built using the xmcp framework.
Get the structure of a GLTF/GLB model file. This tool loads the file and returns the parsed scene structure as JSON, using GLTFStructureLoader from gltfjsx. Use this tool for complex model debugging and not implementation. For code generation use the gltfx tool.
| Name | Required | Description | Default |
|---|---|---|---|
| modelPath | Yes | The path to the GLTF/GLB model file to get the structure of. The path should be absolute on the file system. Do not use relative paths. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context about what the tool does ('loads the file and returns the parsed scene structure as JSON, using GLTFStructureLoader from gltfjsx') and its intended use case ('complex model debugging'), which goes beyond the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded with the core purpose, followed by usage guidelines. Each sentence adds clear value without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has rich annotations (readOnly, idempotent, non-destructive) and 100% schema coverage, the description adds meaningful context about the tool's behavior and use case. However, there is no output schema, and the description does not detail the return format (e.g., JSON structure), which is a minor gap for a debugging tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'modelPath' fully documented in the schema. The description does not add any additional parameter details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('structure of a GLTF/GLB model file'), and explicitly distinguishes from the sibling tool 'gltfjsx' by specifying 'For code generation use the gltfx tool.' This provides specific differentiation beyond just the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('for complex model debugging and not implementation') and when to use an alternative ('For code generation use the gltfx tool'). This gives clear context for tool selection versus the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts a GLTF/GLB 3D model file into a reusable, declarative React (react-three-fiber) JSX component. Supports options for TypeScript output, mesh/material instancing, pruning, compression, texture format, mesh simplification, and more. Useful for integrating 3D assets into React apps with optimal performance and flexibility.
| Name | Required | Description | Default |
|---|---|---|---|
| modelPath | Yes | The path to the GLTF/GLB model file to convert to JSX. The path should be absolute. The path should be absolute on the file system. Do not use relative paths. | |
| options | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, non-mutating operation. The description adds valuable context beyond annotations by specifying the output format ('reusable, declarative React JSX component') and performance aspects ('optimal performance'), though it could mention more about error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by supported features and use case, all in three concise sentences. Each sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters with extensive nested options, no output schema), the description provides a solid overview of functionality and use case. However, it could be more complete by mentioning output details (e.g., file generation, error cases) or dependencies, though annotations cover safety aspects adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50%, the description compensates by listing key options ('TypeScript output, mesh/material instancing, pruning, compression, texture format, mesh simplification, and more') that align with the input schema properties. It provides a high-level overview of parameter purposes, though it doesn't detail all 16 nested options or their interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Converts', 'Supports') and resources ('GLTF/GLB 3D model file', 'React (react-three-fiber) JSX component'). It distinguishes from the sibling tool 'get-model-structure' by focusing on conversion rather than analysis, and includes the benefits ('optimal performance and flexibility').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Useful for integrating 3D assets into React apps') but does not explicitly state when to use this tool versus alternatives like the sibling 'get-model-structure' or other 3D processing tools. It mentions the target use case but lacks explicit comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get-model-structuregltfjsxThe two tools have clearly distinct purposes: get-model-structure is for debugging and analysis by returning parsed JSON structure, while gltfjsx is for code generation by converting models into React components. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the task.
The tool names follow different conventions: get-model-structure uses kebab-case with a verb-noun pattern, while gltfjsx is a specific tool name without a clear verb. This minor deviation prevents a perfect score, but the names are still readable and descriptive enough for their functions.
With only 2 tools, the server feels thin for handling GLTF/GLB models, as it might lack operations like model validation, editing, or export. However, the tools cover core tasks of analysis and code generation, making it borderline appropriate but potentially incomplete for broader workflows.
The server covers two key aspects: model structure analysis and React component generation. However, there are notable gaps, such as no tools for model creation, updating, or deletion, and no support for non-React frameworks or basic file operations, which could limit agent capabilities in full model lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
3D avatar/asset foundry: text/image -> rigged, validated, engine-ready GLB via x402.
Turn text or an image into an animation-ready 3D model (GLB): generate, rig, animate, retexture.
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
Free text/image → 3D: generate, rig, avatar-ify, and refine GLB models. No auth, no payment.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/basementstudio/mcp-three'
If you have feedback or need assistance with the MCP directory API, please join our Discord server