Un servidor de Protocolo de Contexto de Modelo (MCP) que permite a los usuarios generar modelos 3D a partir de descripciones de texto o imágenes, con un enfoque en la creación de modelos 3D paramétricos utilizando reconstrucción de múltiples vistas y OpenSCAD.
Generación de imágenes con IA : genere imágenes a partir de descripciones de texto utilizando las API de Google Gemini o Venice.ai
Generación de imágenes de múltiples vistas : cree múltiples vistas del mismo objeto 3D para su reconstrucción
Flujo de trabajo de aprobación de imágenes : revise y apruebe/rechace las imágenes generadas antes de la reconstrucción
Reconstrucción 3D : Convierta imágenes multivista aprobadas en modelos 3D utilizando CUDA Multi-View Stereo
Procesamiento remoto : procese tareas computacionalmente intensivas en servidores remotos dentro de su LAN
Integración con OpenSCAD : genere modelos 3D paramétricos utilizando OpenSCAD
Exportación paramétrica : exporta modelos en formatos que conservan las propiedades paramétricas (CSG, AMF, 3MF, SCAD)
Descubrimiento de impresoras 3D : descubrimiento de impresoras de red opcional e impresión directa
Related MCP server: 3D MCP Server
El servidor está construido utilizando el SDK de Python MCP y sigue una arquitectura modular:
openscad-mcp-server/
├── src/
│ ├── main.py # Main application
│ ├── main_remote.py # Remote CUDA MVS server
│ ├── ai/ # AI integrations
│ │ ├── gemini_api.py # Google Gemini API for image generation
│ │ └── venice_api.py # Venice.ai API for image generation (optional)
│ ├── models/ # 3D model generation
│ │ ├── cuda_mvs.py # CUDA Multi-View Stereo integration
│ │ └── code_generator.py # OpenSCAD code generation
│ ├── workflow/ # Workflow components
│ │ ├── image_approval.py # Image approval mechanism
│ │ └── multi_view_to_model_pipeline.py # Complete pipeline
│ ├── remote/ # Remote processing
│ │ ├── cuda_mvs_client.py # Client for remote CUDA MVS processing
│ │ ├── cuda_mvs_server.py # Server for remote CUDA MVS processing
│ │ ├── connection_manager.py # Remote connection management
│ │ └── error_handling.py # Error handling for remote processing
│ ├── openscad_wrapper/ # OpenSCAD CLI wrapper
│ ├── visualization/ # Preview generation and web interface
│ ├── utils/ # Utility functions
│ └── printer_discovery/ # 3D printer discovery
├── scad/ # Generated OpenSCAD files
├── output/ # Output files (models, previews)
│ ├── images/ # Generated images
│ ├── multi_view/ # Multi-view images
│ ├── approved_images/ # Approved images for reconstruction
│ └── models/ # Generated 3D models
├── templates/ # Web interface templates
└── static/ # Static files for web interfaceClonar el repositorio:
git clone https://github.com/jhacksman/OpenSCAD-MCP-Server.git
cd OpenSCAD-MCP-ServerCrear un entorno virtual:
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activateInstalar dependencias:
pip install -r requirements.txtInstalar OpenSCAD:
Ubuntu/Debian: sudo apt-get install openscad
macOS: brew install openscad
Windows: Descargar desde openscad.org
Instalar CUDA Multi-View Stereo:
git clone https://github.com/fixstars/cuda-multi-view-stereo.git
cd cuda-multi-view-stereo
mkdir build && cd build
cmake ..
makeConfigurar claves API:
Crea un archivo .env en el directorio raíz
Añade tus claves API:
GEMINI_API_KEY=your-gemini-api-key
VENICE_API_KEY=your-venice-api-key # Optional
REMOTE_CUDA_MVS_API_KEY=your-remote-api-key # For remote processingEl servidor admite el procesamiento remoto de tareas de alto consumo computacional, en particular la reconstrucción estéreo multivista CUDA. Esto permite delegar el procesamiento a equipos más potentes dentro de la red local (LAN).
Instalar CUDA Multi-View Stereo en la máquina servidor:
git clone https://github.com/fixstars/cuda-multi-view-stereo.git
cd cuda-multi-view-stereo
mkdir build && cd build
cmake ..
makeInicie el servidor CUDA MVS remoto:
python src/main_remote.pyEl servidor se anunciará automáticamente en la red local utilizando Zeroconf.
Configure el procesamiento remoto en su archivo .env :
REMOTE_CUDA_MVS_ENABLED=True
REMOTE_CUDA_MVS_USE_LAN_DISCOVERY=True
REMOTE_CUDA_MVS_API_KEY=your-shared-secret-keyAlternativamente, puede especificar una URL de servidor directamente:
REMOTE_CUDA_MVS_ENABLED=True
REMOTE_CUDA_MVS_USE_LAN_DISCOVERY=False
REMOTE_CUDA_MVS_SERVER_URL=http://server-ip:8765
REMOTE_CUDA_MVS_API_KEY=your-shared-secret-keyDetección automática de servidores : encuentre servidores CUDA MVS en su red local
Gestión de trabajos : cargue imágenes, realice un seguimiento del estado del trabajo y descargue resultados
Tolerancia a fallos : reintentos automáticos, patrón de disyuntor y seguimiento de errores
Autenticación : autenticación de clave API segura para todas las operaciones remotas
Monitoreo de la salud : controles continuos del estado del servidor e informes de estado
Iniciar el servidor:
python src/main.pyEl servidor se iniciará en http://localhost:8000
Utilice las herramientas MCP para interactuar con el servidor:
generate_image_gemini : Genera una imagen usando la API de Google Gemini
{
"prompt": "A low-poly rabbit with black background",
"model": "gemini-2.0-flash-exp-image-generation"
}generate_multi_view_images : Genera múltiples vistas del mismo objeto 3D
{
"prompt": "A low-poly rabbit",
"num_views": 4
}create_3d_model_from_images : Crea un modelo 3D a partir de imágenes multivista aprobadas
{
"image_ids": ["view_1", "view_2", "view_3", "view_4"],
"output_name": "rabbit_model"
}create_3d_model_from_text : Canalización completa desde el texto hasta el modelo 3D
{
"prompt": "A low-poly rabbit",
"num_views": 4
}export_model : Exportar un modelo a un formato específico
{
"model_id": "your-model-id",
"format": "obj" // or "stl", "ply", "scad", etc.
}discover_remote_cuda_mvs_servers : Encuentra servidores CUDA MVS en tu red
{
"timeout": 5
}get_remote_job_status : verifica el estado de un trabajo de procesamiento remoto
{
"server_id": "server-id",
"job_id": "job-id"
}download_remote_model_result : Descargar un modelo completo desde un servidor remoto
{
"server_id": "server-id",
"job_id": "job-id",
"output_name": "model-name"
}discover_printers : Descubre impresoras 3D en la red
{}print_model : Imprimir un modelo en una impresora conectada
{
"model_id": "your-model-id",
"printer_id": "your-printer-id"
}El servidor admite múltiples opciones de generación de imágenes:
API de Google Gemini (predeterminada): utiliza el modelo experimental Flash Gemini 2.0 para la generación de imágenes de alta calidad
Admite generación de múltiples vistas con un estilo consistente
Requiere una clave API de Google Gemini
API de Venice.ai (opcional): servicio alternativo de generación de imágenes
Admite varios modelos, incluidos flux-dev y fluently-xl
Requiere una clave API de Venice.ai
Imágenes proporcionadas por el usuario : omite la generación de imágenes y usa tus propias imágenes
Subir imágenes directamente al servidor
Útil para trabajar con fotografías o renders existentes.
El servidor implementa un flujo de trabajo de múltiples vistas para la reconstrucción 3D:
Generación de imágenes : genere múltiples vistas del mismo objeto 3D
Aprobación de imagen : revise y apruebe/rechace cada imagen generada
Reconstrucción 3D : Convierta imágenes aprobadas en un modelo 3D utilizando CUDA MVS
Se puede procesar localmente o en un servidor remoto dentro de su LAN
Refinamiento del modelo : opcionalmente refine el modelo usando OpenSCAD
El flujo de trabajo de procesamiento remoto le permite descargar tareas computacionalmente intensivas a máquinas más potentes:
Detección de servidores : descubre automáticamente servidores CUDA MVS en tu red
Carga de imágenes : cargue imágenes multivista aprobadas al servidor remoto
Procesamiento de trabajos : procese las imágenes en el servidor remoto utilizando CUDA MVS
Seguimiento del estado : supervise el estado y el progreso del trabajo
Descarga de resultados : descargue el modelo 3D completo cuando finalice el procesamiento
El servidor admite la exportación de modelos en varios formatos:
OBJ : formato Wavefront OBJ (formato de modelo 3D estándar)
STL : Lenguaje de triángulos estándar (para impresión 3D)
PLY : Formato de archivo poligonal (para nubes de puntos y mallas)
SCAD : código fuente de OpenSCAD (para modelos paramétricos)
CSG : formato CSG de OpenSCAD (conserva todas las propiedades paramétricas)
AMF : Formato de archivo de fabricación aditiva (conserva algunos metadatos)
3MF : Formato de fabricación 3D (reemplazo moderno de STL con metadatos)
El servidor proporciona una interfaz web para:
Generación y aprobación de imágenes multivista
Vista previa de modelos 3D desde diferentes ángulos
Descarga de modelos en varios formatos
Acceda a la interfaz en http://localhost:8000/ui/
Instituto Tecnológico de Massachusetts (MIT)
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Create a primitive, STL and four PNG views. Prefer model_type and parameters; descriptions only recognize named primitive dimensions. Use get_capabilities for defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| model_type | No | ||
| parameters | No | ||
| description | No |
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 does disclose expected outputs (STL and four PNG views) and a limitation of description-based input. However, it omits side effects, permissions, response format, or whether this is a mutating operation beyond the obvious creation act.
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?
Two sentences with no filler and the key usage tip is front-loaded. The only flaw is the slightly ambiguous first sentence, which could be parsed as creating 'a primitive' and 'STL and PNG views' as separate objects.
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?
There is no output schema, so the description must explain outputs; it mentions STL and four PNG views, which helps. It also routes the agent to get_capabilities for defaults. Still, it does not explain what primitives are available, what 'parameters' should contain, or what a successful call returns.
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 0%, so the description must compensate. It adds real meaning by saying that model_type and parameters are preferred, and that description only works for named primitive dimensions. It does not explain the structure of the parameters object or how to reference primitive dimensions, leaving some gap.
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 names a specific verb ('Create') and resource ('primitive, STL and four PNG views'), which says what the tool produces. It also distinguishes itself from the sibling create_model_from_scad by focusing on primitives. Slightly awkward phrasing makes the exact object of creation ambiguous, but the intent is recoverable.
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 gives clear parameter-level guidance: 'Prefer model_type and parameters; descriptions only recognize named primitive dimensions.' It also points the agent to a sibling tool, get_capabilities, for defaults. It does not explicitly contrast with alternatives, but the context for when this tool is appropriate is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile trusted, self-contained 3D OpenSCAD source into STL and four PNG previews. No image reconstruction or implicit AI generation.
| Name | Required | Description | Default |
|---|---|---|---|
| scad_code | Yes | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool compiles source code and produces STL and PNG outputs, and clarifies it does not perform image reconstruction or AI generation. However, it does not mention other behaviors such as validation, error handling, or whether the compilation is executed in a sandbox. Without annotations, this is a reasonable but incomplete disclosure.
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 brief and directly to the point, using one sentence to convey the primary function and a second to clarify boundaries. It avoids fluff and extra details, making it easy for an agent to parse quickly.
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?
The description mentions the output types (STL and PNG previews) but does not provide an output schema. It also lacks parameter details, as noted. However, given the simple input schema and the explicit mention of expected outputs, it provides a baseline understanding of how the tool behaves.
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?
The schema has zero description coverage for the two parameters (scad_code and description). The description implies that scad_code is the OpenSCAD source, but it does not explain the purpose of the optional description parameter or any constraints on the input. This leaves significant ambiguity about the parameters' roles and expected values.
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: compiling OpenSCAD source into STL and PNG previews. It also distinguishes itself from AI generation tools by explicitly stating 'No image reconstruction or implicit AI generation', which helps differentiate it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like create_3d_model or get_model_preview. The mention of 'trusted, self-contained' and 'No AI generation' offers only implicit hints about its intended use case, but no direct comparison or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export scad (editable source), stl/3mf (meshes), or csg (evaluated geometry tree).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | stl | |
| model_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It does not mention whether exporting creates a file, returns a URL, or has any other consequences, leaving the agent unaware of potential impacts.
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 a single, concise sentence that effectively communicates the core functionality without unnecessary verbosity. It is well-structured and easy to parse.
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?
The description lacks essential context about the output or return value. It does not state whether the export returns a file, a URL, or binary data, and there is no output schema. This leaves the agent uncertain about the result of invoking the 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?
The description partially clarifies the 'format' parameter by listing valid values, but it provides no explanation of the 'model_id' parameter. Since the schema offers no parameter descriptions, the tool description does not sufficiently compensate for the missing semantics.
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: exporting a model in specific formats (scad, stl/3mf, csg). It is distinct from sibling tools like get_model_preview or get_model by focusing on export actions.
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?
No explicit guidance is given on when to use this tool versus alternatives. It does not mention any conditions or contrast with siblings such as get_model_preview or create_3d_model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report OpenSCAD version and supported primitives with defaults (all dimensions in mm).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'Report' clearly signals a read-only, non-destructive operation, and the description adds the useful context that all dimensions are in mm. It does not explicitly state side effects are absent, but for a capability query the meaning is clear enough.
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 a single sentence of about 12 words, front-loaded with the action verb 'Report' followed by the specific output contents. Every word carries information, with no filler or repetition.
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?
For a zero-parameter introspection tool with no output schema, the description adequately states what will be returned: version, supported primitives, and defaults, with the unit convention. It is not overly detailed about output structure, but that is acceptable given the simplicity of the 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?
The tool has zero parameters and an empty input schema, so the baseline is 4. The description does not need to explain any parameters, and it adds no param-related details because none exist.
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 uses a specific verb ('Report') and states the exact resource: OpenSCAD version and supported primitives with defaults. This clearly distinguishes it from sibling tools, which all focus on model creation, modification, or export rather than environment capabilities.
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?
There is no explicit when-to-use or alternative guidance, but the nature of a capabilities report implies that it should be consulted before creating or modifying models to know supported primitives. The intended context is inferable from the tool's purpose, but the description does not state it directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a persisted model's parameters and local artifact paths.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of indicating behavior. The word 'Read' implies a non-mutating operation, but the description does not explicitly state that it has no side effects or discuss authentication, errors, or permissions. It discloses the primary behavior but lacks fuller transparency.
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 a single, focused sentence with no redundant words. It front-loads the action and resource, then specifies the exact data returned, making it highly efficient and easy to parse.
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?
For a simple read operation with one required parameter and no output schema, the description provides enough context about what the tool returns. It could be slightly more complete with explicit statements about what is not returned or how errors are handled, but it is sufficiently complete for an agent to understand the core purpose.
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?
The schema provides only the parameter name 'model_id' with no description, and the tool description does not explicitly define it. Although the context of reading a 'persisted model' implies that model_id identifies which model to read, the description adds minimal meaning beyond the parameter name itself.
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 a specific action ('Read') and resource ('persisted model') along with the exact data returned ('parameters and local artifact paths'). It also distinguishes this from sibling tools like get_model_preview or get_model_source by focusing on model parameters and artifact paths.
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 gives no explicit guidance on when to use this tool versus alternatives such as get_model_preview, get_model_source, or export_model. It relies entirely on the verb and resource naming to imply its purpose, but does not state conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return an actual PNG image to the MCP client. Views: perspective, front, top, right.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | perspective | |
| model_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of transparency. It clearly states that the tool returns a PNG image and lists the supported views, which implies a read-only operation with no side effects. It does not explicitly state that it makes no modifications, but the 'get' nature and the return of an image make this reasonably clear.
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 highly concise, consisting of just two short sentences. It gets straight to the point without unnecessary elaboration. The key information—the return type and the available view options—is presented clearly and efficiently.
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?
With no output schema, the description must explain the return type, which it does by stating 'an actual PNG image'. It also covers the main input parameter (view) with its possible values. It does not address error cases or edge situations, but for a simple preview retrieval, the description is sufficiently complete for an agent to understand what it does.
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?
The schema provides no descriptions for parameters, so the description must compensate. It partially does: it enumerates valid values for the 'view' parameter ('perspective, front, top, right'), which is helpful. However, it does not explain that 'model_id' is required, what it represents, or that 'view' has a default value. This leaves about half of the parameter semantics undocumented.
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: returning an actual PNG image to the client. It also lists the available views, making it obvious that this is a preview function. This distinguishes it from sibling tools like get_model or get_model_source, which likely return data rather than image binaries.
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 for retrieving previews but does not explicitly say when to use this tool versus alternatives like get_model or get_model_source. It does not mention any conditions or scenarios where this tool is preferred or not. The guidance is implicit rather than explicit, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the saved UTF-8 SCAD source and revision over MCP, including inside Docker. Edit scad_code and pass its revision as expected_revision to modify_3d_model.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool reads source and revision and mentions MCP/Docker context, but it omits return format, error behavior, or side effects. The behavior is partially transparent but incomplete.
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 brief and mostly to the point, with no fluff. The second sentence is slightly out of place for a read tool but still within the workflow context, keeping the overall structure reasonably efficient.
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?
The description provides some workflow context (read source, edit, pass revision to modify_3d_model) but is incomplete. It does not explain what the tool returns, how model_id is used, or any caveats, leaving important context gaps for an agent.
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?
The only parameter, model_id, has no schema description and is not mentioned in the descriptive text. Since schema coverage is 0% and the description does not compensate, the parameter semantics are essentially undocumented.
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 reads a saved UTF-8 SCAD source and its revision, which distinguishes it from siblings like get_model_preview. However, the second sentence shifts to editing and passing revision to modify_3d_model, which somewhat muddies the primary purpose.
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?
It implies a workflow by instructing to edit scad_code and pass the revision to modify_3d_model, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is suggestive rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit primitive dimensions or replace source using scad_code. Pass expected_revision from get_model/get_model_source to reject stale edits. Failed edits leave the previous revision intact.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | ||
| scad_code | No | ||
| parameters | No | ||
| modifications | No | ||
| expected_revision | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses two non-obvious behaviors: stale edits are rejected via expected_revision, and failed edits leave the previous revision intact ('Failed edits leave the previous revision intact'). It does not mention permissions or success response shape, but the failure semantics are substantive.
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?
Three short sentences with the primary action first, then the prerequisite, then the failure guarantee. Every sentence contributes a distinct operational fact, and there is no filler.
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?
The tool has five parameters, no annotations, and no output schema, so the description must carry significant weight. It covers the revision/concurrency contract well but omits how parameters and modifications should be used, when scad_code is needed versus optional, and what the success response looks like. Correct invocation remains partially underdetermined.
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 0%, so the description must compensate. It adds meaning to scad_code (source replacement) and expected_revision (concurrency guard), but leaves model_id, parameters, and modifications semantically unexplained. An agent cannot determine how to express 'primitive dimensions' or when to use parameters versus modifications.
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 uses an action verb and resource ('Edit primitive dimensions or replace source') and names two concrete use cases: changing dimensions or replacing source via scad_code. It clearly conveys that this tool modifies an existing model, which differentiates it from create/export/get siblings, though it does not explicitly name alternative tools.
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?
It gives concrete usage guidance: fetch expected_revision from get_model/get_model_source and pass it to reject stale edits. This tells the agent where to get a required input and why. However, it does not explicitly state when to prefer this tool over create_model_from_scad or other alternatives.
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.
create_3d_modelcreate_model_from_scadexport_modelget_capabilitiesget_modelget_model_previewget_model_sourcemodify_3d_modelScored across 8 tools
Most tools target distinct actions: creation, modification, preview, export, source retrieval, and capabilities. The create_3d_model and create_model_from_scad pair is slightly overlapping since both produce STL and PNG outputs, but their input modes make the boundary clear enough.
Tool names generally follow a verb_noun snake_case pattern like get_model, export_model, and modify_3d_model. Minor inconsistency exists between create_3d_model and create_model_from_scad, as well as mixing '3d_model' and 'model' variants, but the overall pattern is predictable.
Eight tools is a well-scoped size for an OpenSCAD server: it covers creation, editing, reading, previewing, export, source access, and capabilities without feeling bloated or thin.
The set covers primitive creation, SCAD sourcing, modification, source retrieval, export, preview, and capabilities. However, there is no delete tool and no list/enumerate tool, leaving notable lifecycle gaps for persisted models.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Design 3D-printable parts by chatting: create, edit, render and publish parametric forges.
Generate 3D models from images or text with AI, then retexture or convert them to STL, 3MF or OBJ.
Turn text or an image into an animation-ready 3D model (GLB): generate, rig, animate, retexture.