spz-mcp
This server is an MCP bridge between an LLM agent and StableProjectorz, dynamically exposing the app's tools. It allows you to:
Check bridge status via
spz_bridge_status(always available) to diagnose connectivity.Discover tools dynamically with
describe.Inspect app state via
get_app_state(version, WebUI connections, loaded model, UDIM tiles, selection, generation status).Capture and view the viewport as an MCP image with
get_viewport_screenshot.List generations (
list_generations) and registered UI events (list_events), then invoke those events (invoke_event) to trigger UI actions.Connect with custom host, port, and token settings. New app-level tools are automatically republished without server updates.
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., "@spz-mcpCapture a viewport screenshot and describe what you see."
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.
spz-mcp
An MCP server that lets an LLM agent drive StableProjectorz — inspect the loaded 3D model, read the app's state, look at the viewport, and trigger UI actions.
It talks to the agent bridge built into the app: a loopback-only JSON socket.
Claude Code / Claude Desktop ──MCP(stdio)──► spz-mcp ──TCP 127.0.0.1:8765──► StableProjectorzThe server knows nothing about StableProjectorz
On every tools/list, it asks the running app for its catalogue via the bridge's
describe command and republishes it as MCP tools, building each JSON Schema from the
parameter descriptions the app supplies.
Nothing is hard-coded here. Adding a tool to the app does not require a new release of this server — which is exactly what allows the app and this server to live in separate repositories without drifting apart.
Related MCP server: BlenderMCP
Setup
1. Enable the bridge in StableProjectorz
Add this to spz.config, next to the executable (or at the project root when running
from the Unity Editor), then restart the app:
--agent-bridgeOptional:
--agent-bridge-port=8765
--agent-bridge-token=some-secret # pins your own secret; normally unnecessaryThe Unity console should log [SPZ_Agent_Bridge] listening on 127.0.0.1:8765.
About the token. The bridge requires one on every request. If you don't pin one,
the app generates a secret on first launch and writes it to
%LOCALAPPDATA%/StableProjectorz/agent-bridge.token (~/.local/share/... elsewhere).
This server reads that same file, so there is nothing to configure — and because it
re-reads until it finds one, starting this server before the app is fine.
2. Register the server
Claude Code:
claude mcp add spz -- uvx --from git+https://github.com/redDwarf03/spz-mcp spz-mcpClaude Desktop — in claude_desktop_config.json:
{
"mcpServers": {
"spz": {
"command": "uvx",
"args": ["--from", "git+https://github.com/redDwarf03/spz-mcp", "spz-mcp"]
}
}
}For a non-default port, add "env": {"SPZ_PORT": "8765"}. The token is picked up
automatically.
From a local checkout
pip install -e ".[dev]"
spz-mcp --port 8765Tools
The list comes from the app at runtime. With the current bridge you get:
Tool | What it does |
| Protocol version and tool catalogue |
| Version, WebUI connections, loaded model, UDIM tiles, selection, generation status |
| Viewport capture, returned as a real MCP image the agent can see |
| Stored generation counts per kind, and the latest GUID |
| Every registered |
| Fire a |
Plus one tool this server adds itself:
Tool | What it does |
| Whether the app is reachable, and how to enable the bridge if not |
spz_bridge_status is also the only tool published while the app is down, so an agent can
diagnose the situation instead of finding an unexplained empty toolbox.
Options
Flag | Env | Default |
|
|
|
|
|
|
|
| read from the token file |
|
| the app's well-known location |
Protocol
One JSON object per line over TCP:
-> {"id":"1","tool":"get_app_state","params":{}}
<- {"id":"1","ok":true,"result":{"app_version":"2.4.5","sd_connected":true, ...}}
<- {"id":"1","ok":false,"error":"unknown tool 'foo'. Call 'describe' for the catalogue."}The app serves one request at a time per connection, so this client serialises calls
behind a lock rather than multiplexing on id.
Notes and limits
The bridge is opt-in and loopback-only, but it is an unauthenticated local control channel unless you set a token. Any process on the machine can connect. Enable it only while you are using it.
Screenshots wait on an async GPU readback, so they can take a moment; overlapping captures are rejected rather than left hanging.
Managers in the app live in additively-loaded scenes, so calls made during startup may report that a subsystem is not ready yet.
Tests
pip install -e ".[dev]"
pytestThe suite runs a fake bridge over a real TCP socket, so the client is exercised end to end without needing StableProjectorz running. Each test has a 30 s timeout: these all talk to a local socket and finish in milliseconds, so a hang is a bug and should fail rather than block the suite.
Linting and formatting use ruff:
ruff check .
ruff format .CI/CD
ci.yml runs on every push to main and every pull request:
lint —
ruff checkandruff format --checktest — Python 3.10 through 3.14 on Linux, plus one Windows leg (the app this server drives is Windows-first)
build — builds the wheel and sdist and validates the metadata with
twine check
release.yml runs on a v* tag. It refuses to proceed if the tag does not match the
version in pyproject.toml, then builds and attaches the distributions to a GitHub
release with generated notes.
Publishing to PyPI is off by default, since the server installs fine straight from git. To enable it:
claim the
spz-mcpname on PyPIadd a trusted publisher for this repo, workflow
release.yml, environmentpypiset the repository variable
PUBLISH_TO_PYPItotrue
No token is stored anywhere — publishing authenticates over OIDC.
License
MIT — see LICENSE.
The StableProjectorz app itself is AGPL-3.0. This server is a separate program that communicates with it over a socket, and is deliberately kept in its own repository so it can be reused and relicensed independently.
Available Tools
1 toolspz_bridge_statusCheck the StableProjectorz bridgeARead-onlyIdempotent
Check whether StableProjectorz is reachable and report how to enable the agent bridge. Use this when the other tools are missing or failing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by explaining that the tool not only checks reachability but also reports how to enable the bridge, which is a behavioral detail beyond the annotations.
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 two sentences, front-loaded with the core action, and contains no filler. Every word is purposeful, making it highly 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?
Given the tool's simplicity (no params, no output schema), the description provides sufficient context: what it checks, what it reports, and when to use it. There is no missing information for the agent to invoke it correctly.
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 0 parameters, so the description is not required to explain param semantics. The baseline for 0 params is 4, and the description is consistent with that by not introducing any ambiguous parameter references.
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 ('Check') and clearly identifies the resource ('StableProjectorz reachability') and what it returns ('report how to enable the agent bridge'). It is distinct and unambiguous, even without 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?
Explicit usage guidance is provided: 'Use this when the other tools are missing or failing.' This tells the agent exactly when to invoke this tool, which is strong guidance for a tool with no siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
spz_bridge_status
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The tool's purpose is clearly limited to checking bridge status, and no other tools exist to compete with it.
The single tool name 'spz_bridge_status' is descriptive and clear. It does not follow a verb_noun pattern, but with only one tool there is no inconsistency to penalize.
At just one tool, the server is severely under-scoped. The tool description references 'other tools' that are expected to exist, but they are absent, so the count is far too low for the apparent purpose of managing a StableProjectorz bridge.
The tool only reports status and suggests how to enable the bridge; there are no tools to actually enable, configure, or interact with StableProjectorz. This is a severely incomplete surface, as agents cannot perform any meaningful operations beyond checking availability.
Maintenance
Related MCP Connectors
MCP server for AI dialogue using various LLM models via AceDataCloud
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for Hailuo (MiniMax) AI video generation
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Related MCP Servers
- FlicenseBqualityCmaintenanceAn MCP server that bridges AI clients with a frontend 3D visualization application to control model properties, lighting, and camera settings via WebSocket. It enables real-time manipulation of 3D scenes through natural language commands for scaling, rotating, and coloring models.61-
- AlicenseNot gradedqualityDmaintenanceMCP server that integrates Blender with CSM.ai 3D assets and LLM agents, enabling AI-assisted 3D modeling and animation through natural language commands.MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that enables AI assistants like Codex or ChatGPT to inspect and control a local Blender scene, including creating objects, editing materials, setting cameras and lights, rendering previews, and saving safe copies of .blend files.MIT
- AlicenseNot gradedqualityCmaintenanceMCP server for Meshwright, enabling agents to create 3D models from text prompts via a LangGraph pipeline. Supports configurable image providers, background removal, and TRELLIS reconstruction backends.MIT