Skip to main content
Glama
scarletfantasy

pix-mcp

pix_get_metric_values

Read-onlyIdempotent

Retrieve time-sampled metric values from a PIX capture, such as counters, CPU usage, device utilization, or memory, with summary statistics (min, max, mean).

Instructions

One metric sampled over time: a series rather than a list of events.

The lanes, and what each needs:

  • "pix_counter" (the default) - a counter reported while the capture ran, either by the title through PIXReportCounter or by the driver, such as the per-adapter video memory budget and usage. Takes metric_id from pix_list_timing_counters.

  • "cpu_usage" - one core's utilisation as a percentage, sampled every 100 ms. Takes core, plus either process_id or all_processes=true. Asking for the same core both ways is how to see whether a busy core was busy with the title or with something else.

  • "api_object_memory" - video memory held by one process's D3D12 objects, in bytes. Takes process_id.

  • "device_utilization" and "device_bandwidth" - per Win32 device. Take device_id from pix_list_storage_devices, and need a capture recorded with the ETW file provider.

in_page reports min, max, mean, first and last over the rows returned, which for a series is usually the whole question.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coreNo
limitNo
metricNo
end_timeNo
device_idNo
metric_idNo
capture_idYes
process_idNo
start_timeNo
all_processesNo
cursor_positionNo
timeout_secondsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare read-only and idempotent behavior, and the description adds useful behavioral context: the 100 ms sampling interval for cpu_usage, the capture-relative nature of counters, the ETW requirement, and the in-page aggregate statistics. It does not explain pagination or timeout behavior, but these are minor in light of the annotation coverage.

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

Conciseness4/5

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

The description is front-loaded with a clear one-sentence thesis, followed by a scannable bullet list organized by metric lane. Every bullet conveys necessary parameter or prerequisite information, with minimal fluff, though the final 'in_page' sentence is slightly ambiguous.

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

Completeness3/5

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

For the five main metric lanes, the description is complete and actionable, including defaults, required parameters, and data sources. However, the generic control parameters for time range, pagination, and timeout are never explained, which leaves notable gaps for a complex tool even though an output schema exists.

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?

Schema description coverage is 0%, so the description must carry the parameter explanation burden. It does well for metric, metric_id, core, process_id, all_processes, and device_id, but leaves limit, cursor_position, start_time, end_time, and timeout_seconds semantically unexplained, which is a significant gap for a 12-parameter tool.

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 description states an explicit resource and verb: one metric sampled over time, as a series rather than a list of events. It further distinguishes five metric lanes and names the sibling tools that provide required IDs, so an agent can separate this from event-listing and counter-listing tools.

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?

Each lane comes with concrete usage requirements, such as taking metric_id from pix_list_timing_counters, device_id from pix_list_storage_devices, and the ETW file provider prerequisite. It explains the process_id vs all_processes comparison for cpu_usage, giving the agent actionable guidance, though it does not systematically compare against all sibling metric/timing tools.

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