Model Review MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MODEL_REVIEW_DIR | No | Where screenshots and feedback.json are saved, one folder per model shown. | ~/.model-review/reviews |
| MODEL_REVIEW_PORT | No | Port of the local viewer. When it is taken, for example by a second session, a free port is used. | 8765 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| review_show_modelA | 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
|
| review_get_feedbackA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.