renderdoc-mcp: driving RenderDoc captures from an MCP client

What renderdoc-mcp does that the RenderDoc UI does not

RenderDoc is a frame debugger with a graphical interface. You open a .rdc capture, click through the event browser, select a draw call, read the pipeline state panel, and repeat. That workflow does not script well, and it does not hand results to a language model. renderdoc-mcp exists to close that gap: it is an MCP server and CLI that wraps the RenderDoc replay API into 59 structured tools, so an assistant can open a capture, list events, inspect shader source, pick a pixel or export a texture through tool calls rather than UI actions.

The audience is narrow and specific. It is graphics programmers and engine teams who already capture frames with RenderDoc and want an assistant to do the traversal work: finding which draw wrote a pixel, dumping a constant buffer, comparing two captures of the same scene. The README describes the intent as letting AI assistants "open .rdc captures, inspect GPU frames, debug shaders/pixels, compare captures, and export evidence", all without manual UI. The topics list on the repository (claude, codex, graphics-debugging, mcp, opengl, renderdoc, vulkan) matches that framing. If you never produce .rdc files, this project has nothing to offer you.

How the MCP server and CLI sit on top of the RenderDoc replay API

The architecture is a wrapper, not a reimplementation. The release zip bundles `bin/renderdoc.dll` and `renderdoc.json`, which the README labels as the bundled RenderDoc runtime. The server process loads that runtime and calls the replay API underneath. That is why a capture has to be replayed rather than merely parsed: the same replay machinery the RenderDoc UI uses is doing the work, and the MCP layer is translating tool calls into replay operations and returning structured results.

The tool surface is grouped by area in the README table. Session and capture covers opening captures, live-capture frames and metadata. Frame navigation lists events and draws and jumps to any event. Pipeline and shaders exposes pipeline state, bindings, shader source and constant buffers. Resources and passes covers frame structure, pass dependencies and resource usage. Pixel and shader debug covers pixel history, pick pixel, and debug pixel, vertex or thread. Export covers render targets, textures, buffers, meshes and snapshots. Diff and assertions compares captures and asserts pixels, state or images for CI.

Two design consequences follow. First, the server is a stateful session over a capture: jumping to an event and then reading pipeline state only makes sense because the replay context persists between calls. Second, the diff and assertion group is the part that is not just a UI replacement. Asserting pixels or images is a CI-shaped operation, and it is the one area where the tool is doing something the interactive debugger was never built for. The README does not document how tolerances are specified for those assertions, which is the detail you would want before wiring them into a build.

Installing renderdoc-mcp and running the CLI on a capture

The README points at GitHub Releases for the package and does not describe a package-manager install. The zip contains `bin/renderdoc-mcp.exe` (the stdio MCP server), `bin/renderdoc-cli.exe` (for shell and CI), the bundled RenderDoc runtime, a Codex workflow skill under `skills/renderdoc-mcp/`, and `install-codex.ps1`. The last release listed is v0.3.1 from 2026-04-10.

For Codex Desktop, the README says the installer auto-configures `~/.codex/config.toml`. The manual equivalent is a TOML block naming the server and pointing at the executable:

[mcp_servers.renderdoc-mcp]
command = 'renderdoc-mcp.exe'
args = []

Claude Code uses the same idea in JSON form, with an `mcpServers` object:

{
  "mcpServers": {
    "renderdoc-mcp": {
      "command": "renderdoc-mcp.exe",
      "args": []
    }
  }
}

Both snippets come straight from the README. Note that they reference the executable by bare name, so the directory containing `renderdoc-mcp.exe` has to be on PATH, or you edit the command to an absolute path. The README does not spell out that requirement; it is an inference from the snippet, and it is the first thing that will bite you.

If you would rather build it, the README gives a CMake invocation with a required variable pointing at a RenderDoc source checkout:

cmake -B build -DRENDERDOC_DIR=<path-to-renderdoc-source>
cmake --build build --config Release

`RENDERDOC_DIR` is required; `RENDERDOC_BUILD_DIR` is optional and only needed when the RenderDoc build output is in a non-standard location. The repository also carries `renderdoc-version.txt`, which is the file to check when you want to know which RenderDoc revision this build expects. After configuring a client, the first real use is to point the CLI or the assistant at an existing .rdc file and ask for the event list, then compare that list against the same capture in the RenderDoc UI. The README does not provide a worked CLI example, so the exact subcommand syntax is something you read off the CLI itself rather than from the documentation.

Windows-only packaging and the gaps the README leaves open

The clearest limitation is distribution. Every artifact named in the README is a Windows binary: `renderdoc-mcp.exe`, `renderdoc-cli.exe`, `renderdoc.dll` and `install-codex.ps1`. There is no mention of a Linux or macOS package, and the download section describes only the zip. Building from source with CMake may work elsewhere, but the README documents the build in terms of a RenderDoc source tree and a Release config, and it does not claim cross-platform support. Treat the packaged path as Windows.

The second limitation is documentation depth. The README is a feature table plus install snippets. It does not document the CLI's subcommands, the schema of the 59 tools, how diff tolerances are expressed, or what happens when a capture was recorded with a RenderDoc version that does not match the bundled runtime. Reproducing a frame usually requires the same GPU and driver as the original capture, and nothing in the README addresses that constraint. If your captures come from a different machine, expect to find out empirically whether replay succeeds.

The third is that this is the wrong tool for some jobs. If you want a human to visually scrub a frame and eyeball a render target, the RenderDoc UI is faster than writing prompts. If your pipeline is not RenderDoc-based, for example if you rely on vendor capture tools, the wrapper has no input to work with. And if you need a frozen tool contract, the version history is a warning: v0.2.2, v0.3.0 and v0.3.1 all landed in April 2026, ten days apart. A tool surface that moves that quickly will rename or reshape tools, so pin a release rather than tracking main.

renderdoc-mcp versus the RenderDoc Python API

The obvious alternative is RenderDoc's own Python API, which the related searches show people already look for as "Renderdoc pyd". It is the same replay engine underneath, and it is the thing renderdoc-mcp wraps. The difference is in what you write. With the Python API you write a script against RenderDoc's module, manage the replay context yourself, and produce whatever output you want; you get full control and no MCP client in the loop. With renderdoc-mcp you get 59 pre-shaped tools and a stdio server, and the caller is an assistant rather than a script you wrote.

That trade is real in both directions. The MCP route means less code to reach a first answer and a natural fit for conversational debugging, where you ask why a pixel is wrong and the assistant walks pixel history for you. The Python route means no dependency on a client that speaks MCP, no tool schema to keep in sync with a fast-moving release cadence, and no Windows-only binary in the middle. It also means you can run it inside an existing CI harness without adding an assistant.

A second alternative is the RenderDoc CLI itself, which is what you reach for when you want a capture taken or a replay driven from a build script. renderdoc-cli.exe in this project's zip plays a similar role, but it is the MCP project's CLI, not RenderDoc's. If your need is purely batch export or capture triggering with no assistant involved, the RenderDoc tooling is the shorter path; renderdoc-mcp earns its place when a model is doing the traversal.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-06-09. That is roughly three months before today, so the project is not stale by the six-month measure, but the README does not describe a release cadence and the newest release listed is v0.3.1 from 2026-04-10. The three releases in the list (v0.2.2 on 2026-04-01, v0.3.0 on 2026-04-02, v0.3.1 on 2026-04-10) cluster in a single ten-day window. Read that as an early-stage project, not a settled one.

Upgrade cost has two parts. The MCP server ships a bundled RenderDoc runtime and a `renderdoc-version.txt` file, so upgrading the wrapper can change the RenderDoc revision underneath you. If your captures were taken with a different revision, replay behaviour can shift. Check that file before and after an upgrade. The second part is the tool surface: with 59 tools, any release that reshapes them touches whatever client-side prompts or CI scripts you wrote against the old names. The release-notes directory in the repository is where that detail would live; the README itself does not carry a changelog.

On licensing, the project is MIT, which is permissive and places few obligations on how you redistribute or embed it. RenderDoc is separate: the README links to RenderDoc's own licence and states it is under its own terms, so the bundled `renderdoc.dll` in the zip is governed by that, not by this project's MIT file. If you redistribute the zip inside a product, read both licences. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt renderdoc-mcp if you already keep .rdc captures and want an MCP client to walk events, read shader source or export a render target without clicking through the RenderDoc UI, and if a Windows machine is acceptable, since the release zip is the only packaged distribution the README describes. Do not adopt it if you need Linux or macOS binaries, if you want a stable tool surface across upgrades, or if you expect the README to answer questions about live capture on Android, Unity integration or diff tolerances; it documents none of those. Verify first that the version string in renderdoc-version.txt matches the RenderDoc build you already use, then run the CLI against one real capture and confirm the event list matches what the RenderDoc UI shows for the same file.

Frequently asked questions

Official sources

1. Issues
2. JiaboLi-GitHub/renderdoc-mcp on GitHub
3. License: MIT
4. README
5. Releases