RenderDoc のキャプチャファイルを、Model Context Protocol（MCP） に対応する AI クライアントが直接分析できるようにします：Draw/Dispatch イベントの閲覧、パイプラインと Shader の検査、頂点・定数バッファデータのページング読み取り。
リポジトリには、実行可能な MCP stdio サービス、セッションとパスの安全境界、開発テスト用の Mock バックエンド、および qrenderdoc 1.44 に接続する実際の Replay ブリッジバックエンドが含まれています。
[!IMPORTANT] 現在は、実際のキャプチャへの接続に
qrenderdocバックエンドを推奨します。renderdoc/nativeバックエンドは予約実装のままです。
実際のブリッジは2つのプロセスで構成されます：モダンな Python 3.11 MCP Gateway と、qrenderdoc に組み込まれた Python 3.6 で動作する UI 拡張機能です。両者はランダムトークン付きのローカルファイルキューの JSON プロトコルで通信します。これにより、RenderDoc の縮小版 Python に存在しない _socket モジュールに依存することなく動作します。
MCP Client <-- stdio --> Python 3.11 Gateway
|
authenticated JSON spool
|
qrenderdoc extension
|
RenderDoc ReplayControllerMCP stdio サービスと構造化されたツール応答。
.rdc パスのホワイトリスト、ファイルタイプ、サイズ、セッション数の制限。
専用ホワイトリスト内の .exe を RenderDoc インジェクションで起動。引数は配列で渡され、シェルは実行されません。
安定した capture_id と明示的な event_id を使用し、暗黙的な現在選択イベントに依存しません。
各キャプチャへのアクセスをバックエンドで直列化し、RenderDoc ReplayController のスレッドモデルに境界を残します。
Action のフィルタリングとカーソルページング。
inspect_event を複合的に呼び出すことで、1回の検査のための細かい MCP ラウンドトリップを減らします。
現在のイベントのトポロジー、viewport/scissor、Shader、リソースバインド、レンダーターゲット、検証メッセージを読み取ります。
統一されたエラー構造と、パッシブな capture summary Resource。
最初のツール：
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 は section を指定しない場合、API 共通のスナップショットと api_specific_sections を返します。その中のいずれかの名前を section として再度呼び出すと、D3D11、D3D12、Vulkan、OpenGL の完全なトップレベル状態グループを得られます。
get_shader は stage ごとに reflection、disassembly、source、raw を読み取ります。後者の3種類の大容量コンテンツは cursor / next_cursor でページングされます。source_file_index で組み込まれている各ソースファイルを辿れます。
get_vertex_data はインスタンスとドロー頂点を安定したレコードに展開し、すべての attribute のデコード値、正確な raw_hex、実際の buffer offset、形式メタデータを返します。uv_attributes は UV / TEXCOORD を明示的に示します。next_cursor を追い続ければ、すべてのインスタンスと頂点を網羅できます。
list_constant_buffers は各 shader stage、reflection block、array element を列挙します。その後 get_constant_buffer でそのブロックのデコード済み変数をすべて読み出します。さらに内側の生バイト列は raw_offset / next_offset でページングされるため、単回の読み出し上限を超えてもデータが失われることはありません。
Related MCP server: RenderDoc MCP Server
Python 3.11+
MCP Python SDK 安定版ライン >=1.27,<2
RenderDoc/qrenderdoc 1.44（実ブリッジバックエンド）
SDK v2 はまだプレリリース段階のため、このプロジェクトでは v1.x に固定しています。フレームワークコードがプレリリースのインターフェイス変更で揺れないようにします。
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 はプロトコルのチャネルです。通常のログを stdout に書かわないでください。
MCP Inspector を使う場合：
.venv\Scripts\mcp dev src\renderdoc_mcp\server.pyMock バックエンドでは、ホワイトリスト内に実在する .rdc パスを渡す必要がありますが、ファイル内容の解析は行われません。
RenderDoc が C:\Tools\RenderDoc にインストールされていると仮定して、プロジェクトディレクトリで実行します：
powershell -ExecutionPolicy Bypass -File .\scripts\install_qrenderdoc_bridge.ps1 `
-RenderDocRoot C:\Tools\RenderDocスクリプトは次を行います：
拡張機能を %APPDATA%\qrenderdoc\extensions\renderdoc_mcp_bridge にインストール。
ランダムトークンを生成し、拡張側の bridge_config.json に書き込み。
Gateway が使う .renderdoc-mcp-bridge.json をプロジェクトのルートに生成。
その後、C:\Tools\RenderDoc\qrenderdoc.exe を開き、Tools → Manage Extensions へ進み、RenderDoc MCP Bridge を選んで、まず Load をクリックします。成功したら Always Load にチェックを入れます。実際のバックエンドを使う間は qrenderdoc を起動し続ける必要があります。キュー用ディレクトリはデフォルトで、プロジェクト内の Git に無視される .renderdoc-mcp-spool です。
開発時には、UI を開いた qrenderdoc で自動ロード用スクリプトを一度実行することもできます：
C:\Tools\RenderDoc\qrenderdoc.exe --ui-python .\scripts\load_qrenderdoc_bridge.pyこのコマンドはその一度のロードだけを担います。日常的には拡張機能マネージャで Always Load をチェックすることをお勧めします。
パスを実際の位置に置き換えてください：
{
"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"
}
}
}Codex のグラフィカル設定ページでは、引数を -m と renderdoc_mcp の2行に分割します。環境変数の透過は空のままにしてください。Working directory にはプロジェクトルートを入力します。作業ディレクトリに既に .renderdoc-mcp-bridge.json があるので、トークンを手動で MCP 設定に張り付ける必要はありません。
環境変数 | デフォルト値 | 説明 |
|
|
|
| 現在のディレクトリ | capture を開けるディレクトリ。複数のディレクトリはシステムのパス区切り文字で区切ります |
| 空（起動禁止） |
|
|
| 今後生成する PNG、。Shader、JSON などの artifact の出力ディレクトリ |
|
| 同時に開けるキャプチャセッション数の上限。 |
|
| 単一キャプチャサイズ上限 |
|
| Action 1ページのハードリミット |
|
| 頂点、定数バッファ、Shader の内容を1ページで読み取るさいのハード上限。カーソルで続きを読めます |
| 設定ファイルの値 | RenderDoc インストール先ディレクトリ。例： |
|
| Gateway ブリッジ設定ファイル |
| 設定ファイルの値 | ローカルブリッジのリクエスト／レスポンスキュー用ディレクトリ |
| 設定ファイルの値 | 任意の環境変数による上書き。通常は手動設定不要 |
|
| ブリッジ要求1回のタイムアウト |
まず、自分のプログラムのプロジェクトルートを RENDERDOC_MCP_ALLOWED_EXECUTABLE_ROOTS に追加し、MCP サービスを再起動して、次のように呼び出します：
{
"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
}成功結果には、RenderDoc の target-control ident とキャプチャファイルテンプレートが含まれます。プログラムは RenderDoc によりインジェクト済みなので、プログラムのウィンドウで既定のキャプチャキー F12 を押すだけで取得できます。このツールはシェルコマンドや環境変数の変更を受け付けません。子プロセス側にもインジェクションが必要な場合にのみ hook_into_children をオンにし、API バリデーションが必要な場合にのみ api_validation をオンにします。
開発用依存関係をインストールした後：
.venv\Scripts\python -m pytest
.venv\Scripts\ruff check .サードパーティのテスト依存を入れなくても、コアサービスのテストは実行できます：
$env:PYTHONPATH = "src"
python -m unittest discover -s tests -vRENDERDOC_MCP_ALLOWED_ROOTS 配下の .rdc ファイルのみ開けます。
launch_program はデフォルトでは無効で、RENDERDOC_MCP_ALLOWED_EXECUTABLE_ROOTS 配下の .exe のみ起動を許可します。
起動引数は配列で渡されシェルを経由しません。Gateway はツールによるターゲット環境変数の変更も許可しません。
Gateway と qrenderdoc 拡張機能の間のローカルメモリは、インストール時に生成されたランダムトークンで認証されます。
Action、Shader、頂点、Buffer データは、ページングまたは単回読み出しの上限のいずれかのある値で保護されます。
ブリッジの主経路、Pipeline state、Shader、頂点入力、定数バッファの読み取りは実装済みです。今後は、タスク単位で Texture ツール、汎用 Buffer readback、Pixel History、artifact 管理を追加して放課です。
詳細境界は アーキテクチャ説明 を参照してください。
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
