Skip to main content
Glama
lpenguin
by lpenguin

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
WEBGPU_BRIDGE_HOSTNoBind address for the local bridge server.127.0.0.1
WEBGPU_BRIDGE_PORTNoPort for the local HTTP + WebSocket bridge.9690
WEBGPU_BRIDGE_TOKENNoOptional auth token required for instrumented pages to connect to the bridge.
WEBGPU_BRIDGE_CHROMENoCustom binary path for Google Chrome, Chromium, or Microsoft Edge. Auto-detects if omitted.
WEBGPU_INSPECTOR_SCRIPTNoPath or URL to custom webgpu_inspector.js injection script. Defaults to bundled file.
WEBGPU_BRIDGE_CAPTURES_DIRNoDirectory where uploaded .wgpuc frame captures are stored. Defaults to <cwd>/captures.<cwd>/captures

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
launch_browserA

Launch a new Chrome/Edge instance controlled by this plugin. Every page it opens is automatically instrumented with the WebGPU Inspector — no extension and no page changes needed. Optionally navigate a first tab to a URL.

attach_browserA

Attach to an already-running Chrome/Edge that was started with --remote-debugging-port. New tabs and navigations are instrumented automatically.

open_pageA

Open a new instrumented tab in the controlled browser and navigate it to a URL. Waits for the page to connect to the bridge and returns it ready to capture.

browser_statusA

Report whether a controlled browser is connected, how it was connected, which targets are instrumented, and which pages have connected to the bridge.

list_pagesA

List browser pages currently connected to the live bridge. A page connects after it is instrumented (via launch_browser/open_page) or after it calls webgpuInspector.initializeServer() itself.

screenshot_pageA

Capture a PNG screenshot of an instrumented page and return it as an image. This reads the COMPOSITED page — the WebGPU canvas exactly as it was presented — so it is the reliable way to SEE what an engine rendered, independent of how it pools/aliases its render targets (reading a pooled target back after the frame is unreliable; the presented surface is not). Requires a page opened via launch_browser/open_page. Use this to visually verify a rendering change, not to inspect intermediate G-buffer contents (use read_texture / capture_frames for those).

capture_framesA

Ask a connected page to capture one or more WebGPU frames, then return a summary of the resulting capture (command/draw/pass counts, object counts, validation errors, flagged issues). Use list_pages first if unsure. For a PERFORMANCE analysis, set profilePasses:true (and payloads:"none" for a light perf-only capture) to measure per-pass GPU time, then call analyze_performance — treat a performance request as implying profilePasses:true.

list_capturesA

List captures currently available to analyze (both live captures and capture files that were explicitly loaded).

load_capture_fileA

Load a WebGPU Inspector capture file from disk (a .wgpuc binary saved by saveCaptureData() or the DevTools 'Save Capture' action, or a legacy .json capture) so it can be analyzed.

get_capture_summaryA

Summarize a capture: object counts by type, command counts by method, derived render statistics, shader entry points, validation error count, and heuristic performance/correctness issues. When the capture was taken with profilePasses:true it also includes gpuTiming (per-frame GPU time, slowest pass); when taken from a live page it includes frameBudget with a CPU/GPU/vsync bound verdict. For a focused performance report, use analyze_performance instead.

analyze_performanceA

Diagnose a capture's performance and return concrete improvement suggestions. Reports the frame budget and a CPU- / GPU- / vsync-bound verdict (needs a live capture for CPU/refresh context and profilePasses:true for GPU time), render passes ranked by GPU time (or fill workload when untimed) each annotated with render-target size/format/MSAA, blend usage, fragment-shader complexity, and a likely bottleneck (fillrate/ROP vs fragment-ALU), plus heuristic issues and ranked suggestions. Best paired with a capture taken via capture_frames({ profilePasses: true, payloads: "none" }).

get_commandsA

Return a paginated, base64-stripped slice of a capture's command list. Each entry has its index, method, pass number, object, and arguments.

get_objectA

Return one GPU object record from a capture (descriptor, label, stacktrace), with base64 payloads omitted.

get_shaderA

Return the WGSL source code of a ShaderModule object in a capture.

get_validation_errorsB

Return the WebGPU validation errors recorded during a capture.

get_draw_stateA

Resolve the full GPU state for a draw/dispatch command: the bound pipeline (and its vertex layout), bind groups per slot (with resource ids), vertex buffers per slot (each with the command index that captured its bytes), the index buffer, and draw params. Use this to diagnose what a specific draw actually read.

decode_vertex_bufferA

Decode the first N vertices of a captured vertex buffer into per-attribute numbers, so you can read e.g. 'attribute @location(2) (uv) = (0,0)' directly. Pass the bufferDataCommandIndex from get_draw_state (a setVertexBuffer command); the vertex layout is taken from the draw's pipeline automatically (or pass layout/pipelineId).

diff_drawsA

Structurally diff the resolved state (pipeline, bind groups, vertex/index bindings, draw params) of two draw commands — useful when a working draw and a broken draw share a pipeline and the difference must be in bound resources.

read_bufferA

Read the current contents of a live GPU buffer on a connected page, without taking a full capture. The inspector copies the buffer to a readback buffer, maps it, and returns the bytes decoded as the requested type. The source buffer must have been created with COPY_SRC usage (buffers created while a capture is armed are given COPY_SRC).

read_textureA

Read a region of a live GPU texture / render target (G-buffer attachment, depth, canvas) on a connected page, without taking a full capture. Copies the texture to a readback buffer, decodes per its format, and returns per-channel min/max/mean, the fraction of unrasterised 'hole' texels (RGB all ~0 = the clear value showing through), and a small ASCII luminance view of the spatial pattern — never raw pixels. Pass a Texture id OR a TextureView id (a render pass attachment is a TextureView — it is resolved to its source texture automatically, so no get_object round-trip is needed). The texture must have COPY_SRC, which the inspector adds to every texture while a capture is armed. Note: reading an engine's POOLED render target after the frame can be unreliable (the pool may have recycled it); to see the final image use screenshot_page instead.

get_frame_statsA

Sample a live page's frame-health metrics over a short window (without taking a capture) and return aggregates: frame rate (fps), average and worst frame time, dropped frames, CPU submit time (main-thread cost per frame), the estimated display refresh interval, and a CPU-vs-GPU/vsync bound verdict. Use this to tell whether a page is dropping frames and whether it's CPU/main-thread bound; GPU time is not measured live, so a non-CPU verdict reads "GPU/vsync" — take a capture with profilePasses:true to measure GPU time and confirm. Requires the page's rendering loop to use requestAnimationFrame.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 21 tools

Disambiguation5/5

Each tool targets a distinct resource/action: capture lifecycle (list/load/summarize/analyze), object/shader/validation retrieval, low-level draw/buffer inspection, and live browser control with frame capture and texture reading. Even the two performance tools (get_capture_summary and analyze_performance) are explicitly differentiated, with the latter cross-referenced as the focused alternative. No two tools appear to do the same thing.

Naming Consistency4/5

The vast majority follow a verb_noun pattern (list_captures, load_capture_file, analyze_performance, read_buffer, capture_frames, etc.). The only deviation is 'browser_status', which uses noun_verb and breaks the otherwise consistent style. This is a minor outlier that does not impede understanding.

Tool Count4/5

21 tools is on the heavier side (borderline of the 16-25 'heavy' range), but the server covers two distinct domains: capture analysis and live browser instrumentation/debugging. Each tool fills a unique and necessary role within those domains, so the count is justified by the scope rather than being bloated or thin.

Completeness5/5

The surface covers the full workflow: capture acquisition (live or file), high-level summary and performance diagnosis, detailed object/state/vertex/buffer inspection, diffing draws, command listing, plus live browser control (launch/attach/open, page and target discovery, screenshot, frame capture, texture reads, and frame stats). There are no obvious gaps that would force an agent to work around missing functionality.

Maintenance

ActivityMaintained
ResponsivenessNo issues