metal-gpu-trace

Overview Schema Source Related Servers Discussions Admin

perf_runs

Read-only

Lists saved GPU performance recordings newest first, showing frames, FPS, GPU ms per frame, memory peaks, and translation layer (Wine or native) to compare and page through traces.

Instructions

Lists the saved recordings, newest first, with frames, FPS, GPU ms per frame, memory peaks and the translation layer each ran on (fingerprint and Wine, or native).

Input Schema

Name	Required	Description	Default
`limit`	No	rows per page, default 50, at most 500
`offset`	No	first row, default 0

Output Schema

Name	Required	Description	Default
`rows`	Yes
`total`	Yes
`offset`	Yes
`next_offset`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.10.1Nov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "next_offset": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "offset": {
+      "type": "integer"
+    },
+    "rows": {
+      "type": "array"
+    },
+    "total": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "total",
+    "offset",
+    "rows",
+    "next_offset"
+  ],
+  "type": "object"
+}

First observedv0.2.0Oct 16, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered for free. The description contributes two genuinely new facts: result ordering ('newest first') and which metrics are surfaced per row; however, enumerated row fields are largely redundant with the existing output schema, and pagination/truncation behavior is never mentioned.

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?

One sentence, front-loaded with the verb and resource plus the ordering guarantee, then the payload. Nothing is padding and nothing essential is buried.

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?

A read-only, two-param list tool with a full output schema and complete annotation coverage needs little more than this, and the description covers scope, ordering and payload. The only real gap is whether more pages exist beyond the returned window and how callers should page through large result sets.

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 100%, so both `limit` (default 50, max 500) and `offset` (default 0) are already fully documented with defaults and bounds. The description adds nothing about paging strategy or ordering interaction with offset, so the baseline 3 applies.

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

Purpose4/5

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

The description gives a specific verb+resource ('Lists the saved recordings') and enumerates what each row contains (frames, FPS, GPU ms/frame, memory peaks, translation layer), so there's no ambiguity about what the tool returns as opposed to perf_record or perf_compare. It stops short of naming a sibling it is not, which keeps it at 4 rather than 5.

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

Usage Guidelines3/5

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

Usage is only implied by 'Lists the saved recordings' – an agent can infer this is the read-only inventory tool, but the description never says when to reach for it over perf_baseline, capture_records or perf_compare, nor any exclusions. No explicit when/when-not guidance is present.

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