FacetCue MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ASM_INSTANCE | No | The session ID shown in the target Blender panel. Only needed when several Blender instances are running; one Blender instance is discovered automatically. Update it after restarting that connection. |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_surface_annotationsA | Read user surface marks/TODOs from the current Blender file in one call. Call with no arguments first. Returns all statuses from all scenes, including hidden objects and hidden overlays: full notes, stable IDs, current 3D positions, anchor validity, and automatically selected viewport visibility. No selection, saving, Python code or screenshot is required. Includes unsaved edits. No viewport still returns notes and 3D positions. Pagination: follow next_offset if has_more. Each page is a fresh read. scene_name optionally narrows the file; limit is 1..200. Set include_visibility=false for a lighter read. Blender must be running with FacetCue for Blender enabled. |
| submit_annotation_changesA | After model edits succeed, mark 1..200 affected annotations as MODIFIED. Pass the scene_name, marker_id and expected_revision from the read before editing, plus a brief summary of actual completed work. The whole batch is validated before status writes. Same revision/summary retries are safe. This adds a blue review badge; it does not change geometry, approve work, overwrite user notes, or infer which objects were edited. A revision conflict requires rereading and reconciling the updated user request. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| current_annotations | The same default live read for clients that support MCP resources. |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one reads annotations, the other submits changes. There is no overlap in functionality, and their descriptions make the read vs. write separation obvious.
Both tools follow a consistent verb_noun pattern in snake_case (get_surface_annotations, submit_annotation_changes). The naming is predictable and easy to parse.
With only 2 tools, the count is slightly below the typical 3–15 range, but it fits the narrow read-and-update workflow. No additional tools are needed for the stated purpose, so the count is reasonable.
The server covers reading all annotations and marking affected ones as MODIFIED after edits, which closes the core loop. It intentionally omits creating or deleting annotations (done in Blender) and only supports the MODIFIED status, a minor gap for broader annotation management.