Click on "Deploy 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., "@Model Review MCP open bracket.3mf so I can mark what needs changing"
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.
Review 3D models with your AI assistant by pointing at them. The assistant opens a model in a browser viewer, you click the exact spot you mean, write what should change and press Send feedback. The assistant gets every note with the part name, the position in millimetres, the surface direction and a screenshot with numbered pins.
Built for 3D printing: STL, 3MF and Bambu Studio / OrcaSlicer projects, with part names, plate positions and filament colours intact. Works with any MCP client, including Claude Code, Claude Desktop, Cursor, VS Code, Windsurf and Codex.
You need uv. The server runs straight from GitHub; there is nothing to clone.
Claude Code
claude mcp add model-review -s user -- uvx --from git+https://github.com/Rovey/model-review-mcp model-review-mcpClaude Desktop, Cursor, Windsurf and other clients with a JSON config:
{
"mcpServers": {
"model-review": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Rovey/model-review-mcp", "model-review-mcp"]
}
}
}VS Code uses the same entry under "servers" instead of "mcpServers".
Codex (~/.codex/config.toml):
[mcp_servers.model-review]
command = "uvx"
args = ["--from", "git+https://github.com/Rovey/model-review-mcp", "model-review-mcp"]Restart the client, then ask your assistant something like "show me box.3mf so I can mark what to change".
Related MCP server: meshcue-mcp
The assistant calls review_show_model with one or more files. A browser tab opens, or an open one reloads.
You rotate the model and click wherever something should change. Type a note and press Enter. Each note gets a numbered tag.
You press Send feedback.
The assistant reads your notes and screenshots, changes the design and can show the new version in the same tab.
review_show_modelOpens model files in the viewer. Calling it again replaces the model.
Parameter | Type | Description |
| list of strings, 1–20 | Absolute paths to |
| string, optional | Heading shown in the viewer. Defaults to the file names. |
review_get_feedbackReturns the notes from the last time the user pressed Send feedback.
Parameter | Type | Description |
| boolean, default | Block until the user sends feedback. |
| integer 1–3600, default | Maximum wait in seconds. |
Example result:
{
"model": "M5 fastener box",
"overall": "Check the lid clearance",
"view": "~/.model-review/reviews/20261014-120501/view.jpg",
"notes": [
{
"n": 1,
"text": "Make this divider 2 mm thick",
"part": "M5 box - body",
"point": [111.8, 87.5, 2.7],
"normal": [0, 0, 1],
"image": "~/.model-review/reviews/20261014-120501/note_1.jpg"
}
]
}point is in the coordinates of the file the part came from, even when several files are shown side by side.
normal is the direction of the surface that was clicked.
image shows the numbered pins as the user saw them. Every submission contains the full set of notes.
MCP tools only run when the assistant calls them, so the viewer cannot push notes into the conversation. An assistant can pick them up in either of two ways:
Background command: clients that run background commands and react when they finish (Claude Code, for example) run curl -s http://127.0.0.1:8765/wait. It prints the feedback JSON as soon as the user presses Send feedback.
Blocking call: any other client calls review_get_feedback(wait=true).
Action | How |
Rotate, pan, zoom | Drag, right-drag, scroll |
Add a note | Click the model, type, press Enter (Esc cancels) |
Standard views | Iso, Top, Front, Side |
Fit the model, keep the angle | Fit, or press F |
Hide a part | Untick it under Parts |
Light or dark theme | Theme button at the top right: Auto (follows the system), Light, Dark |
The model sits on a 10 mm grid, with a heavier line every 50 mm. Parts from Bambu Studio and OrcaSlicer projects show their filament colour. Files without colour information get neutral colours.
Environment variable | Default | Purpose |
|
| Port of the local viewer. When it is taken, for example by a second session, a free port is used. |
|
| Where screenshots and |
The viewer listens on 127.0.0.1 only.
Requests with a foreign Host header (DNS rebinding) or a foreign Origin (other websites) are refused, so a web page cannot read your model or inject notes into your assistant.
Notes are size-limited and only JPEG and PNG screenshots are accepted.
Models never leave your machine. The browser does load three.js and the Barlow font from public CDNs, so it needs internet access.
Problem | Fix |
No browser tab opens | Open the URL from the tool result yourself, usually |
Viewer shows an old model | Reload the tab. It reloads by itself unless you have unsent notes, in which case a banner offers the reload. |
Viewer stays empty | The page needs internet access for three.js. Check the browser console for blocked requests. |
"Could not read the model" | Check that the file is a valid mesh. For slicer projects, save the project in the slicer again. |
git clone https://github.com/Rovey/model-review-mcp
cd model-review-mcp
uv run pytest -q # unit tests
uv run python tests/smoke_test.py path/to/model.3mf # end-to-end check, prints "ok: ..."To run your checkout from an MCP client, use uv run --directory /path/to/model-review-mcp model-review-mcp as the command. Contributor and agent notes are in AGENTS.md.
Return the notes the user sent from the viewer for the model shown by review_show_model.
Result (JSON): model, overall (free-text note), view (path to a screenshot of the final view) and notes, each with n, text, part, point [x, y, z] and normal [x, y, z] in the file's own units (mm for printer files), and image (path to a screenshot with the numbered pins as the user saw them). Read the images to see what the user pointed at. Each submission holds the full set of notes.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Block until the user presses 'Send feedback' | |
| timeout_s | No | Maximum wait in seconds when wait=true |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real context: coordinates are in the file's own units (mm for printer files), pins are numbered and screenshots should be read, and every submission carries the full set of notes. It doesn't discuss what happens on timeout or whether old feedback is retained across calls.
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 purpose sentence is front-loaded and tight, but the field-by-field enumeration of the JSON result largely restates the existing output schema, which is waste. The genuinely valuable parts (units, image-reading instruction, full-set semantics) are buried in that list.
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 an output schema present, the description needn't enumerate return fields, yet it still supplies what the schema can't: unit conventions and the instruction to read the screenshots. Only the blocking/timeout behavior is left unaddressed.
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 coverage is 100% and both parameters are documented in the schema, so the description's silence on wait/timeout is acceptable. Notably, the description never mentions blocking behavior or timeout despite that being the tool's main operational choice, so it adds nothing over the schema here.
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?
Uses a specific verb ('Return') and resource ('the notes the user sent from the viewer') and explicitly ties the result to the model shown by review_show_model, which cleanly separates it from that sibling. An agent can tell exactly what comes back without opening the schema.
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 phrase 'for the model shown by review_show_model' establishes the required sequence, and the wait/timeout parameters imply the two modes of use. It never states exclusions or when to prefer a non-blocking call, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open 3D model files in a browser viewer where the user pins notes to exact spots on the model.
Use this when you want the user's feedback on a 3D design, or when they ask to see a model.
Supports STL, 3MF (including Bambu Studio / OrcaSlicer projects: part names, plate positions and
filament colours are kept), OBJ, PLY and GLB. Several files are laid out side by side.
Calling it again replaces the model and reloads an open viewer tab.
Next step: wait for the user's notes with review_get_feedback(wait=true), or run
curl -s <viewer url>wait as a background command if your client can.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Absolute paths of the model files to show | |
| title | No | Heading in the viewer; defaults to the file names |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: repeated calls replace the model and reload an open tab, part names/plate positions/filament colours survive 3MF import, and multiple files render side by side.
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?
Front-loaded with the one-line what-it-is, then when-to-use, formats, repeat-call semantics, and next step in a tight sequence. Slightly dense with the multi-format list and the inline curl example, but every line carries information an agent would otherwise have to guess.
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?
An output schema exists, so return values need not be spelled out, and the description still implies a viewer URL by showing the curl wait pattern. Combined with the follow-up tool pointer, an agent has enough to call and chain correctly; only the exact viewer-URL/tab lifecycle is left implicit.
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% and both parameters (paths, title) are already documented, so the schema carries the load. The description adds format-level meaning ('Supports STL, 3MF ... OBJ, PLY and GLB') and a side-by-side layout note, but nothing about path constraints or title behaviour beyond the schema defaults.
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?
States a specific verb+resource (open 3D model files in a browser viewer) plus the distinctive affordance of pinning notes to exact spots. The second sentence and format list make it unmistakable next to review_get_feedback, which only reads notes.
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?
Explicitly names the two triggering conditions ('when you want the user's feedback on a 3D design, or when they ask to see a model') and then routes to the correct follow-up tool plus a fallback (curl on the viewer URL) for clients that can't block. That is when-to-use, what-next, and an alternative all in one.
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.
v1.0.0review_get_feedbackreview_show_modelScored across 2 tools
The two tools are cleanly split by direction of data flow: review_show_model pushes a model to the viewer, while review_get_feedback pulls user notes back. The descriptions even spell out the call order ('next step: wait for the user's notes with review_get_feedback'), leaving no room for misselection.
Both names follow the same review_<verb>_<noun> pattern (review_show_model, review_get_feedback) with a shared resource prefix. Consistent snake_case and action verbs make the pair obviously related.
Two tools is the honest minimum for a show-and-collect-feedback loop, and each earns its place with no filler. It is thinner than the 3-15 ideal, but the stated purpose is narrow enough that no third tool is obviously needed.
The surface covers the core lifecycle: open the viewer with a model and retrieve notes tied to model, point, part and image. Minor gaps exist — no way to close the viewer, list prior sessions, or clear stale notes other than by re-showing a model — but agents can work around these.
CAD in ChatGPT and Claude: editable parts, STEP/STL/drawings, in-chat 3D, automatic checks.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
3D printing: printable models, calculators, troubleshooting wiki, build guides, AI 3D + CAD design.
Connect AI assistants to your approved computer for files, commands, browser and desktop tasks.
