metal-gpu-trace

Overview Schema Source Related Servers Discussions Admin

gpu_family

Read-only

Retrieve Apple's published facts for a GPU family or chip, including its chips, additions, limits, shared limits, and footnotes, with source URLs for verification.

Instructions

Apple's published facts for one GPU family, by family ("Apple7") or chip ("M1 Pro"): its chips, what it adds, its limits, plus the limits shared by all families and the footnotes. Source URLs are in the result.

Input Schema

Name	Required	Description	Default
`name`	Yes	a family (Apple7 to Apple10) or a chip (M1 Pro, M2, M4 Max, A17 Pro)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.10.1Nov 2, 2026
- changedOutput schema / (root)
```
Previous value: -nullNew value: +{
+  "type": "object"
+}
```
First observedv0.2.0Oct 16, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds provenance by noting source URLs are in the result and clarifies that shared limits and footnotes are included, but it does not mention error behavior or caching.

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?

Two sentences, front-loaded with the resource and scope. The colon list is dense but each item clarifies the returned facts.

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

Completeness5/5

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

Low-complexity read-only lookup with a fully described parameter, annotations, and output schema. The description covers scope, result contents, and provenance, leaving no material gap for correct invocation.

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 coverage is 100% and the single parameter already documents family/chip examples. The description repeats the same valid input forms but adds no formatting or edge-case guidance beyond the schema.

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?

States it returns Apple's published facts for one GPU family and enumerates result contents: chips, additions, limits, shared limits, and footnotes. It does not explicitly differentiate from sibling perf/trace tools, though those are unrelated categories.

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?

Implies use for looking up GPU family/chip facts and gives example names such as Apple7 and M1 Pro. It never states when to use this instead of related performance tools or what happens for unsupported names.

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