Skip to main content
Glama
phunkaeg

apitrace-mcp

by phunkaeg

find_matrices

Read-onlyIdempotent

Locate and classify 4x4 matrices in GPU traces, distinguishing projection, view, and rigid transforms to pinpoint FOV, camera, and HUD matrices.

Instructions

Find and classify every 4x4 matrix the game sends to the driver.

This is the core VR/camera-hacking tool. It covers:

  • fixed-function transforms -- SetTransform(D3DTS_VIEW/PROJECTION/WORLD), glLoadMatrixf/glMultMatrixf, glFrustum/glOrtho;

  • shader constants -- SetVertexShaderConstantF and friends, tracked through a shadow register file so matrices uploaded piecemeal still resolve, and reported as the register range that holds them (e.g. vs_c[8..11]);

  • uniform/constant buffer uploads -- glBufferData, UpdateSubresource and the memcpy calls apitrace records for writes to mapped memory, reported as a byte offset into the buffer (set scan_buffers=false to skip);

  • both storage orders, since D3D9 shader constants usually hold the transpose.

Results are grouped by slot. Read them as: kind=projection -> the game's FOV, near and far planes kind=rigid + changes_per_frame -> camera candidate; confirm with track_camera kind=viewproj in vs_c[...] -> the register range a VR patch rewrites kind=viewproj at a buffer offset -> the bytes a VR patch rewrites kind=ortho -> HUD/UI or shadow pass

Scope with calls (a single frame is usually enough and far faster).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
callsNo
kindsNoprojection,viewproj,rigid,ortho
limitNo
traceYes
scan_buffersNo
min_confidenceNo
scan_constantsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds rich behavioral context beyond the readOnly/idempotent annotations: shadow register file tracking, piecemeal upload resolution, register-range reporting, buffer byte offsets, transpose storage orders, and grouping by slot. There is no contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough but well-structured: a crisp lead sentence, bulleted technical coverage, a result-reading legend, and scoping guidance. Every section adds value, and there is no filler or repetition of schema defaults.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with seven parameters and no schema descriptions, the description is largely complete: it explains what is detected, how results are reported, and how to interpret each kind. It falls just short only because required-parameter semantics (`trace`) and a few tuning parameters are left to inference, though the output schema covers return shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the prose must carry parameter meaning. It does explain `calls`, `scan_buffers`, and the `kind` result categories, but it never names the required `trace` parameter, nor does it explain `limit`, `min_confidence`, or `scan_constants` as explicit knobs. Partial compensation, but a real gap remains.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Find and classify every 4x4 matrix the game sends to the driver.' It then enumerates exact coverage areas (fixed-function transforms, shader constants, buffer uploads) and result kinds, which also separates it clearly from sibling tools like track_camera and decode_matrix.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear scoping advice ('Scope with calls; a single frame is usually enough and far faster') and explicitly points to track_camera as the confirmation alternative for camera candidates. It does not systematically explain when not to use this tool versus the many sibling trace-inspection tools, but the intended use case is strongly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/phunkaeg/apitrace-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server