Intel GPA Framework analysis server - analyze GPU captures (.gpa_frame files or stream directories), extract textures/shaders/geometry, collect performance metrics via MCP protocol.
GPA MCP server has 18 tools with consistent naming (gpa_* prefix, verb-noun pattern) and descriptions present for all tools. However, input schemas lack critical details: most parameters are minimally described (1-2 sentences), output schemas are not documented, and error handling is generic. Tool descriptions average ~100 chars (below the 194-char baseline for A+ tools). Parameters like 'output_format' and 'stage' use free-form strings instead of enums, inviting hallucinated values. No pagination guidance for list_ranges despite potentially large result sets. Error responses are generic ('Range index out of bounds') without recovery hints. Batch tools (gpa_batch_export_textures, gpa_batch_export_shaders) lack per-item success/failure reporting.
Batch export all shaders for a draw call range in a specified format.
Batch export all textures bound to a draw call range.
Collect GPU performance metrics for a specific draw call range (triggers GPA playback).
Export a GPU time ranking report for all draw calls in the frame.
Export shader source code, bytecode, or disassembly to a local file.
Export a texture from a specific slot to a local file.
One-click export of all resources for a draw call range (textures + shaders + geometry).
Output schemas not documented. Tools return JSON via ok_response() helper, but LLMs cannot see the structure of returned fields (e.g., what fields does gpa_get_pipeline_state.pipeline contain?). This forces LLMs to guess downstream field names and risks broken tool chains.
Free-form string parameters instead of enums. 'output_format' (png|dds|raw), 'stage' (vertex|pixel|compute|geometry|hull|domain), 'output_type' (source|bytecode|disasm), and 'resource_type' (all|texture|buffer|rendertarget|depthstencil) accept strings without enum constraints. LLMs will hallucinate invalid values like 'jpg' or 'fragment'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Get all API calls and parameters within a specific draw call range.
Get the full rendering pipeline state for a draw call range. Returns vertex/pixel shader hashes, render targets, blend/rasterizer/depth state, primitive topology, viewport, and input layout.
Get shader metadata: hash, shader model, entry point, whether source is available.
List all GPU resources bound to a draw call range (textures, buffers, render targets, etc).
List all previous exports and their metadata (size, timestamp, contents).
List all available GPU performance metrics for the current hardware and stream.
List draw call ranges in the stream with pagination and name filtering.
Open a GPA stream folder or .gpa_frame file. Required before any other operation.
Run a GPA CLI command (gpa_player, gpa_inject, etc) with arguments and capture output.
Search the entire stream for API calls matching a keyword.
Get stream metadata: file list, total size, API type, GPU info, etc.
Batch tools lack per-item success/failure reporting. gpa_batch_export_textures and gpa_batch_export_shaders export multiple items but return only a single success/error. If one texture fails, the LLM cannot tell which ones succeeded and which failed, forcing a full retry.
Generic error messages without recovery guidance. Errors like 'Range index out of bounds' or 'Exception: <str(e)>' do not tell the LLM what to do next. Should include hints like 'Try gpa_list_ranges() to see valid indices' or 'Check stream_path exists and is readable'.
gpa_run_cli_command is a dangerous catch-all. Accepts arbitrary command names and args, enabling injection attacks if stream_path or args are not sanitized. No whitelist enforcement visible in the provided code snippet. Should validate command names against a hardcoded whitelist and sanitize all arguments.