Permite que los clientes de IA que admiten el Model Context Protocol (MCP) analicen directamente archivos de captura de RenderDoc: explorar eventos Draw/Dispatch, inspeccionar el pipeline y los Shaders, y leer datos de vértices y buffers de constantes paginados.
El repositorio incluye un servicio MCP stdio ejecutable, límites de seguridad de sesión y ruta, un backend Mock para pruebas de desarrollo y un backend de puente Replay real que se conecta a qrenderdoc 1.44.
[!IMPORTANT] Actualmente se recomienda usar el backend
qrenderdocpara conectarse a capturas reales; los backendsrenderdoc/nativesiguen siendo implementaciones reservadas.
El puente real consta de dos procesos: un Gateway MCP moderno en Python 3.11 y una extensión de UI que se ejecuta en el Python 3.6 integrado de qrenderdoc. Ambos se comunican mediante un protocolo JSON de cola de archivos local con token aleatorio; esto evita depender del módulo _socket que falta en el Python reducido de RenderDoc.
MCP Client <-- stdio --> Python 3.11 Gateway
|
authenticated JSON spool
|
qrenderdoc extension
|
RenderDoc ReplayControllerServicio MCP stdio y respuestas de herramientas estructuradas.
Lista blanca de rutas .rdc, restricciones de tipo de archivo, tamaño y número de sesiones.
Inicia .exe dentro de una lista blanca independiente mediante inyección de RenderDoc; los argumentos se pasan como array, sin ejecutar shell.
capture_id estable, event_id explícito, sin depender del evento seleccionado actual oculto.
Acceso serial al backend por cada captura, dejando margen para el modelo de hilos de RenderDoc ReplayController.
Filtrado de acciones y paginación con cursor.
Llamada compuesta inspect_event para evitar muchos viajes MCP de grano fino para una sola inspección.
Lee topología, viewport/scissor, Shader, enlaces de recursos, objetivos de renderizado y mensajes de validación del evento actual.
Estructura de error unificada y recurso de resumen de captura pasivo.
Primeras herramientas:
health
launch_program
open_capture
close_capture
get_capture_summary
list_actions
get_event
inspect_event
get_pipeline_state
get_shader
get_vertex_data
list_constant_buffers
get_constant_buffer
get_pipeline_state sin section devuelve una instantánea genérica entre APIs y api_specific_sections; al llamar de nuevo con cualquiera de esos nombres como section, se pueden leer los grupos de estado de nivel superior completos de D3D11, D3D12, Vulkan u OpenGL.
get_shader lee reflection, disassembly, source o raw según la etapa. Los tres últimos tipos de contenido grande se paginan con cursor / next_cursor; source_file_index permite recorrer cada archivo de código fuente incrustado.
get_vertex_data expande instancias y vértices de draw en registros estables, devolviendo valores decodificados de todos los atributos, raw_hex exacto, offset real del buffer y metadatos de formato; uv_attributes marca explícitamente UV / TEXCOORD. Siguiendo next_cursor se cubren todas las instancias y vértices.
list_constant_buffers enumera cada etapa de shader, bloque de reflexión y elemento de array; luego se usa get_constant_buffer para leer todas las variables decodificadas de ese grupo. Los bytes brutos subyacentes se paginan con raw_offset / next_offset, por lo que no se pierden datos incluso si se supera el límite de lectura única.
Related MCP server: RenderDoc MCP Server
Python 3.11+
Línea estable del SDK de Python MCP >=1.27,<2
RenderDoc/qrenderdoc 1.44 (backend de puente real)
El SDK v2 aún está en fase de prelanzamiento, por lo que este proyecto se fija temporalmente en v1.x para evitar que el código del framework cambie con interfaces de prelanzamiento.
En PowerShell:
python -m venv .venv
.venv\Scripts\python -m pip install -e ".[dev]"
$env:RENDERDOC_MCP_BACKEND = "mock"
$env:RENDERDOC_MCP_ALLOWED_ROOTS = (Get-Location).Path
.venv\Scripts\python -m renderdoc_mcpstdio es el canal de protocolo; no escribas registros normales en stdout.
Usando MCP Inspector:
.venv\Scripts\mcp dev src\renderdoc_mcp\server.pyEl backend Mock aún requiere una ruta .rdc real y en la lista blanca, pero no analiza el contenido del archivo.
Suponiendo que RenderDoc está instalado en C:\Tools\RenderDoc, ejecuta en el directorio del proyecto:
powershell -ExecutionPolicy Bypass -File .\scripts\install_qrenderdoc_bridge.ps1 `
-RenderDocRoot C:\Tools\RenderDocEl script:
Instala la extensión en %APPDATA%\qrenderdoc\extensions\renderdoc_mcp_bridge;
Genera un token aleatorio y lo escribe en bridge_config.json del lado de la extensión;
Genera el .renderdoc-mcp-bridge.json usado por el Gateway en la raíz del proyecto.
Luego abre C:\Tools\RenderDoc\qrenderdoc.exe, ve a Tools → Manage Extensions, selecciona RenderDoc MCP Bridge, haz clic en Load primero y, si tiene éxito, marca Always Load. Al usar el backend real, qrenderdoc debe permanecer en ejecución; el directorio de cola por defecto es .renderdoc-mcp-spool, ignorado por Git dentro del proyecto.
Durante el desarrollo, también puedes hacer que qrenderdoc ejecute automáticamente un script de carga después de abrir la UI:
C:\Tools\RenderDoc\qrenderdoc.exe --ui-python .\scripts\load_qrenderdoc_bridge.pyEste comando solo se encarga de la carga actual; para uso diario se recomienda marcar Always Load en el administrador de extensiones.
Reemplaza las rutas con las ubicaciones reales:
{
"mcpServers": {
"renderdoc": {
"command": "C:\\path\\to\\RenderDoc_MCP\\.venv\\Scripts\\python.exe",
"args": ["-m", "renderdoc_mcp"],
"env": {
"RENDERDOC_MCP_BACKEND": "qrenderdoc",
"RENDERDOC_MCP_ALLOWED_ROOTS": "C:\\captures",
"RENDERDOC_MCP_ALLOWED_EXECUTABLE_ROOTS": "C:\\projects\\my-renderer",
"RENDERDOC_MCP_ARTIFACT_ROOT": "C:\\path\\to\\RenderDoc_MCP\\artifacts",
"RENDERDOC_MCP_RENDERDOC_ROOT": "C:\\Tools\\RenderDoc"
},
"cwd": "C:\\path\\to\\RenderDoc_MCP"
}
}
}En la página de configuración gráfica de Codex, los argumentos deben dividirse en dos líneas: -m y renderdoc_mcp. Deja en blanco la transferencia de variables de entorno; en Working directory pon la raíz del proyecto. Como el directorio de trabajo ya contiene .renderdoc-mcp-bridge.json, no es necesario pegar manualmente el token en la configuración de MCP.
Variable de entorno | Valor predeterminado | Descripción |
|
|
|
| directorio actual | Directorios donde se pueden abrir capturas; varios directorios separados por el separador de ruta del sistema |
| vacío (inicio prohibido) |
|
|
| Directorio para futuros artefactos como PNG, Shader, JSON, etc. |
|
| Número máximo de sesiones de captura concurrentes; el backend qrenderdoc se restringe a 1 |
|
| Límite de tamaño para una sola captura |
|
| Límite máximo de página para acciones |
|
| Límite máximo de lectura por página para vértices, buffers de constantes y contenido de Shader; se puede continuar con cursor |
| valor del archivo de configuración | Directorio de instalación de RenderDoc, por ejemplo |
|
| Archivo de configuración del puente Gateway |
| valor del archivo de configuración | Directorio de cola de solicitudes/respuestas del puente local |
| valor del archivo de configuración | Anulación opcional por variable de entorno; normalmente no requiere configuración manual |
|
| Tiempo de espera para una sola solicitud de puente |
Primero agrega la raíz del proyecto de tu programa a RENDERDOC_MCP_ALLOWED_EXECUTABLE_ROOTS, reinicia el servicio MCP y luego llama:
{
"executable": "C:\\projects\\my-renderer\\bin\\renderer.exe",
"arguments": ["--scene", "C:\\projects\\my-renderer\\scenes\\demo.json"],
"working_directory": "C:\\projects\\my-renderer",
"hook_into_children": false,
"api_validation": false
}El resultado exitoso incluye el ident de control de destino de RenderDoc y la plantilla de archivo de captura. El programa ya está inyectado por RenderDoc; puedes presionar la tecla de captura predeterminada F12 en la ventana del programa. Esta herramienta no acepta comandos de shell ni modificaciones de variables de entorno; abre hook_into_children solo si necesitas que los subprocesos también se inyecten, y api_validation solo si necesitas la capa de validación de API.
Después de instalar las dependencias de desarrollo:
.venv\Scripts\python -m pytest
.venv\Scripts\ruff check .También puedes ejecutar las pruebas del servicio principal sin instalar dependencias de prueba de terceros:
$env:PYTHONPATH = "src"
python -m unittest discover -s tests -vSolo se pueden abrir archivos .rdc dentro de RENDERDOC_MCP_ALLOWED_ROOTS.
launch_program está deshabilitado por defecto; solo permite iniciar .exe dentro de RENDERDOC_MCP_ALLOWED_EXECUTABLE_ROOTS.
Los argumentos de inicio se pasan como array, sin pasar por shell; el Gateway no permite modificar las variables de entorno del programa objetivo a través de herramientas.
Los mensajes locales entre el Gateway y la extensión de qrenderdoc se autentican con un token aleatorio generado en la instalación.
Los datos de Action, Shader, vértices y Buffer están sujetos a paginación o límites de lectura única.
El enlace principal del puente, el estado del pipeline, el Shader, la entrada de vértices y la lectura de buffers de constantes ya están implementados. A continuación, es adecuado continuar agregando exportación de texturas, readback de buffers genéricos, Pixel History y gestión de artefactos por tareas.
Para más detalles, consulta Descripción de la arquitectura.
Close a capture session and release its replay resources.
| Name | Required | Description | Default |
|---|---|---|---|
| capture_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose one meaningful trait beyond the schema: that replay resources are released. It omits other relevant behavior for a lifecycle/teardown call, such as irreversibility, idempotency, error conditions, and whether the capture data becomes unavailable afterward.
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?
A single front-loaded sentence with no filler; the action and its side effect are stated immediately. It is efficient, though terse enough that it verges on under-specification rather than maximal conciseness.
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?
An output schema exists so return values need not be described, and the tool is low-complexity with one parameter. Still, with zero annotations the description should cover error/duplicate-close behavior and permission needs; it only covers the resource-release side effect, leaving the lifecycle contract partly undefined.
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?
Schema description coverage is 0% and the description never mentions capture_id. The single parameter's self-explanatory name is the only signal, and the description adds no format, source, or validity information to compensate for the coverage gap.
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?
States a specific verb ('Close') and resource ('capture session'), clearly the inverse of the sibling open_capture. The added clause 'release its replay resources' sharpens the effect. It does not explicitly name open_capture or other siblings, so it stops short of full differentiation.
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?
Usage is implied by the name and by the existence of open_capture, so an agent can infer this is the teardown counterpart. However, there is no explicit when-to-use statement, no prerequisite (e.g. a capture must be open), and no guidance on what happens if called twice or on an invalid id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return metadata and warnings for an open capture session.
| Name | Required | Description | Default |
|---|---|---|---|
| capture_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool returns metadata and warnings, but says nothing about whether it is purely read-only, any permission requirements, or behavior when the capture is not open. For a tool with zero annotation coverage this is thin.
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?
A single well-formed sentence with the core purpose front-loaded and no wasted words. Appropriately sized for a simple getter.
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?
With an output schema present, the return values (metadata and warnings) need not be detailed in the description. However, given no annotations and 0% parameter coverage, the description leaves gaps around the required capture_id and read-only behavior that a minimal getter could plausibly fill.
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?
Schema description coverage is 0% and the single parameter (capture_id) is undocumented. The description alludes to a 'capture session' but adds no meaning about what capture_id identifies, its format, or its relationship to an open session, failing to compensate for the coverage gap.
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?
States a specific verb (Return) and resource (metadata and warnings for an open capture session), which clearly distinguishes it from siblings like open_capture, close_capture, and get_event. The purpose is unambiguous, though it does not explicitly name a contrasting sibling.
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?
The phrase 'for an open capture session' implies a prerequisite (a session must exist, presumably via open_capture), giving implied usage context. However, there is no explicit when-to-use guidance or named alternative, so the guidance remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read decoded variables and a bounded raw-byte page for one constant-buffer group.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | ||
| event_id | Yes | ||
| capture_id | Yes | ||
| raw_length | No | ||
| raw_offset | No | ||
| array_index | No | ||
| block_index | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It implies a read-only operation ('Read') and a bounded response ('bounded raw-byte page'), but it omits permissions, side effects, error behavior, and any other operational context needed to invoke it safely.
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 single sentence is front-loaded with the verb and resource and contains no filler. It is appropriately concise, though its extreme brevity contributes to gaps elsewhere.
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?
For a tool with 7 parameters, 0% schema description coverage, no annotations, and only an output schema to cover return values, the description is far from complete. It gives no usage context and almost no parameter or behavioral detail, leaving major gaps for an agent to infer.
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?
Schema description coverage is 0% for 7 parameters, so the description must compensate. It only hints at block_index ('one constant-buffer group') and raw_length/raw_offset ('bounded raw-byte page'); the roles of capture_id, event_id, stage, and array_index are left unexplained.
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 states a specific verb ('Read') and resource ('one constant-buffer group'), and it names the outputs ('decoded variables and a bounded raw-byte page'). This implicitly distinguishes it from list_constant_buffers, but it does not explicitly name or contrast with any sibling tool, which keeps it from a 5.
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?
The description gives no guidance on when to use this tool versus alternatives like list_constant_buffers or inspect_event, nor does it state prerequisites such as needing an open capture or a valid block index. It only describes what the tool does, not when to reach for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get draw, dispatch, copy, marker, or present details for one event ID.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | ||
| capture_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read, and the enumerated detail types hint at scope, but there is nothing about permissions, whether capture_id must be an open capture, or error behavior when an event ID is absent.
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?
A single front-loaded sentence that names the verb, resource, and returned detail categories with zero filler. Nothing needs trimming and nothing is buried.
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?
An output schema exists, so return values need not be described. Still, with two required, undocumented parameters and no annotation coverage, the description leaves the agent guessing about capture_id and about how this tool relates to inspect_event.
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?
Schema description coverage is 0% for two required parameters, so the description must compensate and does not. It gestures at 'one event ID' but never explains the required capture_id or the relationship between capture_id and event_id.
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?
States a specific verb ('Get') plus resource ('event') and enumerates the detail kinds returned (draw, dispatch, copy, marker, present), so the agent knows what this retrieves. It does not, however, differentiate itself from the sibling 'inspect_event', leaving ambiguity about which to pick.
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?
There is no guidance on when to use this tool versus alternatives such as inspect_event or get_capture_summary. The only implicit cue is 'one event ID', which does not constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read common pipeline state or one API-specific top-level state section.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | ||
| event_id | Yes | ||
| capture_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden; it only implies a read via the verb 'Read.' It says nothing about permissions, whether the state is live or frozen at the event, or any error/edge behavior, leaving significant gaps.
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?
A single front-loaded sentence with no filler. The only cost is that the alternative clause is dense jargon rather than plain language, but nothing is wasted.
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?
An output schema exists, so return values need not be described, but with zero parameter coverage, no annotations, and no explanation of the section concept, the description is too thin for a 3-parameter tool whose optional 'section' argument drives meaningfully different results.
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?
Schema description coverage is 0%, so the description must compensate, yet event_id and capture_id are never mentioned. It only hints at the 'section' parameter by referencing 'one API-specific top-level state section,' without listing valid section names or explaining the default null behavior.
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?
States a clear verb (Read) and resource (pipeline state), and distinguishes between 'common pipeline state' and 'one API-specific top-level state section.' However, the jargon 'common' vs 'API-specific top-level state section' is not explained, so the exact scope remains fuzzy for an agent unfamiliar with the API.
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?
No guidance on when to use this tool versus siblings like get_event, inspect_event, or get_capture_summary, and no indication of when the optional 'section' argument should be supplied versus omitted. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a bound shader's reflection, disassembly, source, or raw bytes in pages.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | ||
| cursor | No | ||
| length | No | ||
| content | No | reflection | |
| event_id | Yes | ||
| capture_id | Yes | ||
| source_file_index | No | ||
| disassembly_target | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that output is paged, but says nothing about read safety, required capture/event binding, error modes, or how cursor/length control traversal.
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?
A single front-loaded sentence with no filler. It is efficient, though arguably too terse for an 8-parameter tool, which slightly reduces its structural value.
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?
For an 8-parameter tool with 3 required params, no annotations, and 0% schema description coverage, the description does far too little. The existence of an output schema excuses explaining return values, but the input semantics and usage context remain substantially under-specified.
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?
Schema description coverage is 0% across 8 parameters. The description only indirectly touches 'content' (reflection/disassembly/source/raw bytes) and 'in pages' (cursor/length); it says nothing about stage, event_id, capture_id, source_file_index, or disassembly_target, so it fails to compensate for the coverage gap.
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 states a specific verb (Read) and resource (a bound shader) and enumerates what can be retrieved: reflection, disassembly, source, or raw bytes. It is clearer than a tautology, but it does not contrast itself with siblings like get_constant_buffer or get_vertex_data, so an agent gets the 'what' but not the sibling boundary.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. 'in pages' hints at a paginated workflow but gives no condition for choosing this tool over the adjacent get_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Page through every vertex/instance input and decoded attribute, including UVs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| event_id | Yes | ||
| capture_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results are paginated (a real behavioral trait) and that it returns 'decoded' attributes, but says nothing about permissions, whether the capture must be open, result volume, or ordering semantics.
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?
A single front-loaded sentence with no filler or redundancy; the pagination behavior is stated first. It is efficient, though arguably too terse for the amount of unexplained surface area.
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?
An output schema exists, so return values need not be described, but with zero annotation coverage, zero parameter descriptions, and no usage conditions, an agent lacks enough context to invoke this confidently. For a tool requiring capture_id and event_id, more framing is needed.
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?
Schema description coverage is 0% across 4 parameters, so the description must compensate and does not: event_id, capture_id, limit, and cursor are never explained, nor is the relationship between event_id and the vertex data requested. The mention of UVs describes the payload, not any parameter.
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 states a specific verb ('Page through') and resource ('every vertex/instance input and decoded attribute, including UVs'), which clearly separates it from siblings like get_constant_buffer or get_shader. It is clear but does not explicitly name or contrast with any alternative tool.
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?
There is no guidance on when to use this tool versus siblings such as inspect_event or list_constant_buffers, nor any stated prerequisite (e.g., that a capture must be open). The required capture_id/event_id are only visible in the schema, not framed as usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check gateway limits and whether the configured replay backend is available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'Check' implies a read-only, non-destructive probe and it names what is inspected, but it says nothing about side effects, latency, failure modes, or what happens when the backend is unavailable.
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?
A single front-loaded sentence with no padding; every clause ('gateway limits', 'configured replay backend') earns its place and the object of the check comes first.
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?
An output schema exists, so return values need not be explained, and a zero-parameter diagnostic needs little more than a statement of what it verifies. The only gap is the lack of any hint about when to run it relative to the capture/launch workflow.
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 takes zero parameters, so there are no parameter semantics to document; the baseline for a parameterless tool applies. The description correctly adds no misleading parameter context.
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 gives a specific verb ('Check') and two concrete resources ('gateway limits', 'replay backend availability'), which lets an agent distinguish this diagnostic from the graphics-capture siblings. It is clear about what it does, though it does not explicitly name itself as the diagnostic/pre-flight counterpart to tools like launch_program or open_capture.
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?
There is no guidance on when to call this versus any sibling, nor any stated preconditions or exclusions. A health/diagnostic check's timing (e.g., before launch_program or after a backend change) is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect selected pipeline sections for an event in one serialized replay call.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | ||
| event_id | Yes | ||
| capture_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that a serialized replay is triggered and that the work is batched, which hints at cost, but says nothing about whether replay mutates state, what permissions are required, or how failures surface.
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?
A single tight sentence with the key scoping information ('for an event', 'one serialized replay call') front-loaded. Nothing is wasted, though it is arguably too terse to be fully useful.
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?
An output schema exists, so return values need not be explained. However, for a 3-parameter tool with zero schema descriptions and no annotations, the description should at minimum enumerate the selectable pipeline sections and clarify its relationship to sibling tools.
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?
Schema description coverage is 0%, so the description must compensate for three undocumented parameters. capture_id and event_id are self-evident by name, and 'selected pipeline sections' loosely corresponds to the include array, but the allowed section values and the effect of omitting include (default null) are never explained.
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?
It gives a verb (inspect) and a resource (pipeline sections for an event), so the general intent is inferable. But 'selected pipeline sections' is vague about what sections exist or what 'inspect' returns, and it does nothing to distinguish itself from siblings like get_event or get_pipeline_state.
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?
There is no explicit when-to-use guidance and no alternative named. The phrase 'in one serialized replay call' hints that this batches multiple fetches into a single replay, but the agent is left to infer when that matters versus calling get_event plus get_pipeline_state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch and inject an allow-listed .exe through qrenderdoc/RenderDoc.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | ||
| executable | Yes | ||
| api_validation | No | ||
| working_directory | No | ||
| hook_into_children | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden yet only discloses that executables must be allow-listed and that injection occurs. It omits whether the call blocks until the target exits, what happens on a non-allow-listed binary, permission requirements, or how the launched process relates to the capture session.
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?
A single front-loaded sentence with no wasted words, and the key constraint (allow-listed) is placed early. It is efficient, though its brevity borders on under-specification for a five-parameter process-launch tool.
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?
An output schema exists so return values need not be explained, but for a complex, unannotated five-parameter launcher the definition should still cover parameter meaning and launch/mutation behavior. As written it leaves the agent with critical gaps before invoking it.
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?
Schema description coverage is 0% across five parameters, and the description names none of them. The meanings of arguments, api_validation, working_directory, and hook_into_children are entirely absent from both structured fields and prose, so it fails to compensate for the coverage gap.
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?
States a specific verb pair (launch/inject) and resource (an allow-listed .exe through qrenderdoc/RenderDoc), which is unambiguous about what the tool does. It does not explicitly differentiate itself from the capture-inspection siblings, but its purpose is far enough from open_capture/list_actions that an agent can identify it.
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?
The 'allow-listed' qualifier gives an implicit prerequisite, but there is no statement of when to use this versus open_capture or close_capture, no note on whether it should precede capture analysis, and no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List capture actions with filtering and bounded cursor pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| query | No | ||
| cursor | No | ||
| flatten | No | ||
| capture_id | Yes | ||
| parent_event_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. "Bounded cursor pagination" hints at paging behavior, but nothing is said about ordering, auth/permission needs, default limits, or what flatten actually does to results.
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?
A single compact sentence with no wasted words, and the core purpose is front-loaded. It is efficient, though so terse that brevity shades into under-specification.
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?
An output schema exists, so return values need not be explained, but a 7-parameter tool with zero schema coverage and no annotations needs far more description than one sentence. An agent cannot know what kind, flatten, or parent_event_id mean before calling.
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?
Schema description coverage is 0% across 7 parameters, and the description only loosely gestures at filtering and cursor pagination. Key parameters like kind, flatten, parent_event_id, and capture_id are left entirely unexplained in both schema and description.
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?
States a specific verb and resource ("List capture actions") plus the scoping mode (filtering, cursor pagination). It does not distinguish itself from siblings such as get_event, inspect_event, or list_constant_buffers, so an agent can't fully route between lookup tools from this text alone.
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?
No when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling tools. Usage is only implied by the words "list capture actions."
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every shader-stage/block/array constant-buffer group with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| event_id | Yes | ||
| capture_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses pagination, which is genuinely useful, but says nothing about read-only safety, required capture/event context, ordering, or failure behavior for a 4-parameter tool.
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?
A single front-loaded sentence with no filler; the scoping detail (shader-stage/block/array) is dense but each word earns its place. It could be marginally tighter but is well structured.
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?
An output schema exists so return values need not be explained, but the definition still omits the meaning of the required capture_id/event_id pair and any usage context for a list operation. For a tool with 0% parameter documentation, more is needed.
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?
Schema description coverage is 0%, so the description must compensate. It only gestures at pagination (implying limit/cursor) and never explains the two required parameters, capture_id and event_id, and what they must reference.
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?
Specific verb (list) plus a precise resource scope (shader-stage/block/array constant-buffer groups), which clearly separates it from the singular sibling get_constant_buffer. It stops short of explicitly naming that sibling or contrasting scope, so it is clear but not fully differentiated.
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?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as get_constant_buffer for a single buffer. The agent must infer that this is the enumeration counterpart to the singular getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open one allow-listed .rdc file and return a stable capture_id.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one key behavioral constraint — only allow-listed .rdc files can be opened — plus the promise of a stable id. It omits error behavior for disallowed paths and lifecycle/resource implications (that a capture stays open until close_capture).
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?
One tight sentence, front-loaded with the operation and its scope, with zero filler.
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?
For a single-parameter opener with an output schema (so the capture_id return need not be explained), the description covers what it does and its main constraint. Adding the close_capture lifecycle or error conditions would make it fully complete.
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?
Schema coverage is 0%, so the description must compensate; it adds that 'path' points to an allow-listed .rdc file, which is real meaning beyond 'string/Path'. It still gives no format, relative-vs-absolute, or example detail.
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?
Specific verb (open) plus a precise resource ('one allow-listed .rdc file'), and it even names the artifact it produces (capture_id). It does not explicitly contrast with close_capture or the inspection siblings, so it falls short of a 5.
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?
There is no statement of when to use this versus alternatives, nor any prerequisite/ordering guidance (e.g., that other capture tools need the returned capture_id, or that close_capture must follow). Usage is only weakly implied by the verb 'open'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0close_captureget_capture_summaryget_constant_bufferget_eventget_pipeline_stateget_shaderget_vertex_datahealthinspect_eventlaunch_programlist_actionslist_constant_buffersopen_captureScored across 13 tools
Most tools have clearly distinct purposes across lifecycle, metadata, and inspection. However, get_event, inspect_event, and get_pipeline_state all operate on event IDs and pipeline data, creating some boundary overlap that could cause misselection in an agent.
Nearly all tools follow a clean snake_case verb_noun pattern (open_capture, get_event, list_actions, get_constant_buffer). The lone 'health' deviates as a bare noun, but it is a widely recognized convention so the impact is minor.
13 tools is well-scoped for a graphics debugging/replay server, with each tool earning its place across session lifecycle, event inspection, and pipeline/shader data retrieval. No redundancy or bloat.
Covers the core lifecycle (launch, open, close) plus rich inspection of actions, events, pipeline state, shaders, vertex data, and constant buffers. Minor gaps exist for resource/texture inspection or capture export, but core workflows are well covered.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Agent Replay Debugger MCP — record every agent step + deterministic replay. Step-debugger for
Read-only MCP server: let AI agents read your ORANO saved-video library, tasks, and memory.
SnapRender gives AI agents eyes on the web through a hosted MCP server. Send a public URL and get the page back as an image, a PDF or clean markdown, with no browser to run or maintain. Capture the viewport or the full page as PNG, JPEG, WebP or PDF, at desktop size or with a phone, tablet or laptop preset, in light or dark mode. Ads and cookie banners are removed by default, and you can hide elements or click one before the capture. extract_content reads the same page as markdown, text, article, links or metadata, so an agent can see a page and read it in one session. Made for monitoring and client work: batch up to 50 URLs in one job, check the cache for free before spending a capture, share signed links that render without an API key, and get webhooks when a batch finishes or a scheduled capture spots a change. Track competitors' pricing and landing pages, or send clients current screenshots of their sites. Connect with OAuth (Google, GitHub or email) or an API key. Works with Claude, ChatGPT, Cursor, VS Code and any MCP client. Free plan: 200 screenshots a month, no credit card. Paid plans from $9 a month for 2,000 up to $199 a month for 200,000. Home: https://snap-render.com Docs: https://snap-render.com/ai-agents
