사용자가 텍스트 설명이나 이미지에서 3D 모델을 생성할 수 있도록 하는 MCP(Model Context Protocol) 서버로, 다중 뷰 재구성과 OpenSCAD를 사용하여 매개 변수 3D 모델을 만드는 데 중점을 둡니다.
AI 이미지 생성 : Google Gemini 또는 Venice.ai API를 사용하여 텍스트 설명에서 이미지 생성
다중 뷰 이미지 생성 : 재구성을 위해 동일한 3D 객체의 다중 뷰를 생성합니다.
이미지 승인 워크플로 : 재구성 전 생성된 이미지를 검토하고 승인/거부합니다.
3D 재구성 : CUDA Multi-View Stereo를 사용하여 승인된 다중 뷰 이미지를 3D 모델로 변환
원격 처리 : LAN 내의 원격 서버에서 계산 집약적 작업을 처리합니다.
OpenSCAD 통합 : OpenSCAD를 사용하여 매개변수 3D 모델 생성
매개변수 내보내기 : 매개변수 속성을 유지하는 형식(CSG, AMF, 3MF, SCAD)으로 모델을 내보냅니다.
3D 프린터 검색 : 선택적 네트워크 프린터 검색 및 직접 인쇄
Related MCP server: 3D MCP Server
서버는 Python MCP SDK를 사용하여 구축되었으며 모듈식 아키텍처를 따릅니다.
지엑스피1
저장소를 복제합니다.
git clone https://github.com/jhacksman/OpenSCAD-MCP-Server.git
cd OpenSCAD-MCP-Server가상 환경 만들기:
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate종속성 설치:
pip install -r requirements.txtOpenSCAD 설치:
우분투/데비안: sudo apt-get install openscad
macOS: brew install openscad
Windows: openscad.org 에서 다운로드
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 ..
makeAPI 키 설정:
루트 디렉토리에 .env 파일을 만듭니다.
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 processing이 서버는 연산 집약적인 작업, 특히 CUDA 멀티뷰 스테레오 재구성의 원격 처리를 지원합니다. 이를 통해 LAN 내의 더 강력한 머신으로 처리 부담을 덜 수 있습니다.
서버 머신에 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 ..
make원격 CUDA MVS 서버를 시작합니다.
python src/main_remote.py서버는 Zeroconf를 사용하여 로컬 네트워크에 자동으로 자신을 광고합니다.
.env 파일에서 원격 처리를 구성하세요.
REMOTE_CUDA_MVS_ENABLED=True
REMOTE_CUDA_MVS_USE_LAN_DISCOVERY=True
REMOTE_CUDA_MVS_API_KEY=your-shared-secret-key또는 서버 URL을 직접 지정할 수 있습니다.
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-key자동 서버 검색 : 로컬 네트워크에서 CUDA MVS 서버 찾기
작업 관리 : 이미지 업로드, 작업 상태 추적 및 결과 다운로드
장애 허용 : 자동 재시도, 회로 차단기 패턴 및 오류 추적
인증 : 모든 원격 작업에 대한 보안 API 키 인증
상태 모니터링 : 지속적인 서버 상태 점검 및 상태 보고
서버를 시작합니다:
python src/main.py서버는 http://localhost:8000 에서 시작됩니다.
MCP 도구를 사용하여 서버와 상호 작용합니다.
generate_image_gemini : Google Gemini API를 사용하여 이미지 생성
{
"prompt": "A low-poly rabbit with black background",
"model": "gemini-2.0-flash-exp-image-generation"
}generate_multi_view_images : 동일한 3D 객체의 여러 뷰를 생성합니다.
{
"prompt": "A low-poly rabbit",
"num_views": 4
}create_3d_model_from_images : 승인된 다중 뷰 이미지에서 3D 모델을 만듭니다.
{
"image_ids": ["view_1", "view_2", "view_3", "view_4"],
"output_name": "rabbit_model"
}create_3d_model_from_text : 텍스트에서 3D 모델로의 완전한 파이프라인
{
"prompt": "A low-poly rabbit",
"num_views": 4
}export_model : 모델을 특정 형식으로 내보냅니다.
{
"model_id": "your-model-id",
"format": "obj" // or "stl", "ply", "scad", etc.
}discover_remote_cuda_mvs_servers : 네트워크에서 CUDA MVS 서버를 찾습니다.
{
"timeout": 5
}get_remote_job_status : 원격 처리 작업의 상태를 확인합니다.
{
"server_id": "server-id",
"job_id": "job-id"
}download_remote_model_result : 원격 서버에서 완성된 모델을 다운로드합니다.
{
"server_id": "server-id",
"job_id": "job-id",
"output_name": "model-name"
}discover_printers : 네트워크에서 3D 프린터를 검색합니다.
{}print_model : 연결된 프린터에서 모델을 인쇄합니다.
{
"model_id": "your-model-id",
"printer_id": "your-printer-id"
}서버는 다양한 이미지 생성 옵션을 지원합니다.
Google Gemini API (기본값): 고품질 이미지 생성을 위해 Gemini 2.0 Flash 실험 모델을 사용합니다.
일관된 스타일로 다중 뷰 생성을 지원합니다.
Google Gemini API 키가 필요합니다.
Venice.ai API (선택 사항): 대체 이미지 생성 서비스
flux-dev 및 fluently-xl을 포함한 다양한 모델을 지원합니다.
Venice.ai API 키가 필요합니다
사용자 제공 이미지 : 이미지 생성을 건너뛰고 사용자 고유의 이미지를 사용하세요
이미지를 서버에 직접 업로드
기존 사진이나 렌더링 작업에 유용합니다.
서버는 3D 재구성을 위한 다중 뷰 워크플로를 구현합니다.
이미지 생성 : 동일한 3D 객체의 여러 뷰 생성
이미지 승인 : 생성된 각 이미지를 검토하고 승인/거부합니다.
3D 재구성 : CUDA MVS를 사용하여 승인된 이미지를 3D 모델로 변환
LAN 내의 로컬 또는 원격 서버에서 처리 가능
모델 개선 : OpenSCAD를 사용하여 선택적으로 모델을 개선합니다.
원격 처리 워크플로를 사용하면 계산 집약적 작업을 더욱 강력한 머신으로 오프로드할 수 있습니다.
서버 검색 : 네트워크에서 CUDA MVS 서버를 자동으로 검색합니다.
이미지 업로드 : 승인된 멀티뷰 이미지를 원격 서버에 업로드합니다.
작업 처리 : CUDA MVS를 사용하여 원격 서버의 이미지를 처리합니다.
상태 추적 : 작업 상태 및 진행 상황을 모니터링합니다.
결과 다운로드 : 처리가 완료되면 완성된 3D 모델을 다운로드합니다.
서버는 다양한 형식으로 모델을 내보내는 것을 지원합니다.
OBJ : Wavefront OBJ 포맷(표준 3D 모델 포맷)
STL : 표준 삼각형 언어(3D 프린팅용)
PLY : 폴리곤 파일 형식(포인트 클라우드 및 메시용)
SCAD : OpenSCAD 소스 코드(매개변수 모델용)
CSG : OpenSCAD CSG 형식(모든 매개변수 속성 유지)
AMF : 적층 제조 파일 형식(일부 메타데이터 보존)
3MF : 3D 제조 포맷(메타데이터를 포함한 STL의 최신 대체 포맷)
서버는 다음을 위한 웹 인터페이스를 제공합니다.
다중 뷰 이미지 생성 및 승인
다양한 각도에서 3D 모델 미리 보기
다양한 형식의 모델 다운로드
http://localhost:8000/ui/ 에서 인터페이스에 접속하세요
MIT
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
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.