Curated, reproducible proof of what DCC-MCP can do inside real DCC hosts.
Every entry here is a real artifact — a GIF, an image, or a video — produced by running one proposition end to end in a real host, plus one sentence on what it proves and the exact host and adapter versions it was verified on.
| Date | Group | Proposition | Adapter | What it proves | Preview | Host environment | Verified up to |
|---|---|---|---|---|---|---|---|
| awaiting first approved entry |
Adapter names the repository the sample was produced against — for example dcc-mcp/dcc-mcp-blender — so every row links back to the adapter it proves.
The gallery is empty on purpose. Artifacts are drafted internally and published here one at a time, after review. Nothing lands in this repository by default.
- The artifact was produced in a real host — not a mock, and not a screenshot of a unit test.
- One sentence stating what it proves. An artifact without that sentence is not an entry.
- Host version, adapter and core versions, and the verification level reached:
- in-host — the host really executed it
- gateway — the instance registered and routed
- real tool return — the tool returned real values, not a wrapped
successover a backend error - cross-host conservation — data survived a transfer (vertex counts, bounding boxes, units, up-axis)
- Failures are entries too. A reproduction of a wall we hit, with the failure captured, is more useful than a claim.
Each sample was produced on a specific host version with specific adapter and core versions. It is not a blanket "we support X" statement. When you reuse these artifacts, keep the version and the verification level attached — that pairing is what makes a sample honest.
If a sample shows a capability that was partly reached with in-host scripting rather than through the MCP tool surface, the entry says so. "It rendered" and "it is orchestratable over MCP" are different claims, and only the first one is proven until the second one is.
media/ approved artifacts, grouped by proposition
Large media should go through Git LFS or an external link. Do not commit large binaries directly — this repository is meant to stay cheap to clone.
Adapter repositories carry a single hero still, one line of explanation, and a link back here. The heavy media lives in this repository, so adapter repos keep their clone cost and their release cadence to themselves.
Open an issue with the proposition you tried, the host and version, and the adapter/core versions. Include what you got back from the tool calls — entries are accepted or rejected on real return values, not on a reported success flag.
MIT — see LICENSE.