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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context with 'bounded' and 'static', indicating no GPU execution or side effects, and notes that the output includes 'explicit limitations,' which tells the agent the tool is conservative about its own completeness.

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

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

The description is a single dense sentence with a colon-separated list. It is concise and front-loaded with the main purpose, but the long list of output categories makes it slightly harder to parse. Still, every phrase contributes meaning and there is no filler.

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

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

There is no output schema, so the description's enumeration of analysis categories is helpful for setting expectations. However, it does not specify the return format or what 'explicit limitations' means concretely. Given the tool's moderate complexity and helpful annotations, the description is reasonably complete but leaves some ambiguity.

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

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

The schema describes capture_path but not top_count; top_count only has min/max/default constraints. The description's mention of 'top calls' indirectly hints at the top_count parameter, but it does not explicitly explain how the parameter shapes the output. With 50% schema coverage, the description only partially compensates for the missing parameter documentation.

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

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

The description uses a specific verb ('Build') and resource ('bounded static analysis from Nsight metadata, API event names, and object identities') and enumerates concrete output categories like 'stream shape, top calls, thread distribution, resource population, compatibility/security findings.' This clearly distinguishes the tool from sibling tools such as 'inspect_capture' or 'list_capture_resources', which focus on raw inspection or listing.

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

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

The phrase 'bounded static analysis' implies a lightweight, non-dynamic analysis, and the tool's scope is clear. However, there is no explicit statement about when to use this tool versus alternatives like 'profile_capture' or 'analyze_gpu_trace_pc_sampling', and no exclusions are mentioned.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds valuable context beyond those: that no shader PDBs are required and source-line correlation is not claimed, which sets expectations for accuracy and input requirements. No contradictions 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.

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

Two sentences, front-loaded with the primary action, followed by scoping and limitations. Every sentence adds value, and there is no redundancy with the schema or annotations.

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

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

Despite lacking an output schema, the description conveys expected results (sample/stall reasons, code-block attribution, hotspots). It covers purpose, temporal scoping, and a key prerequisite. It could be more complete by detailing parameter interactions (e.g., marker_id vs time range), but for a polished tool description, it is largely sufficient.

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

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

Schema coverage is 56%, leaving 4 parameters without descriptions. The description compensates for time-window parameters (start_ms, end_ms, marker_id) by explaining frame-relative and marker scoping, and it hints at output parameters (top_shaders, top_pcs). However, it does not explain stage or shader_hash semantics, which the schema only minimally covers.

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

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

The description uses a specific verb ('Decode raw PC-sampling records into sample/stall reasons, exact shader/code-block attribution, and top shader and instruction-PC hotspots') and clearly identifies the resource. It distinguishes from siblings like summarize_gpu_trace_range by narrowing to PC-sampling analysis.

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

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

It explicitly states scoping options (entire trace, frame-relative window, marker id) and adds a limitation ('does not require shader PDBs; source-line and SASS text correlation are not claimed'). It doesn't name alternative tools, but the context is clear enough to infer when this tool applies.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds useful context beyond annotations: it specifies the data is 'sanitized Nsight export data' and 'held by this MCP process', clarifying scope and memory-focused behavior. No contradiction with annotations found.

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

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

The description is a single, well-structured sentence that front-loads the action ('Clear') and resource, with no redundant or extraneous information. Every word earns its place.

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

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

Given the tool's simplicity (no parameters, no output schema, straightforward operation), the description covers all essential information: what is cleared, the type of data, and the scope (this MCP process). It is fully sufficient for an agent to understand the tool's effect.

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

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

The tool has zero parameters, so the description does not need to explain any parameter semantics. Per the rubric, the baseline for no parameters is 4, and the description is appropriately silent on parameters.

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

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

The description clearly states a specific verb ('Clear') and resource ('in-memory sanitized Nsight export data'), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools by being the only cache-clearing operation among analysis-focused tools.

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

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

The description implies usage (when you want to clear the in-memory cache) but does not explicitly state when to use this tool vs alternatives. There are no sibling tools that perform a similar clearing function, so explicit differentiation is unnecessary, but the description lacks any 'use this when...' guidance.

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

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

The description discloses that collection 'executes instrumented GPU work' and 'can take several minutes', which is valuable context beyond the annotations' generic all-false flags. It also mentions auto-exporting tables in a report session, implying persistence. It doesn't detail cleanup or failure behavior, but the schema parameter descriptions cover some of that, and the time/execution caveat is an honest behavioral disclosure.

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

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

The description is three concise sentences: the first states the main action and return value, the second explains downstream usage, and the third warns about runtime. Every sentence earns its place, with no filler or redundancy. The structure is front-loaded with the most important information.

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

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

For a tool with 8 parameters, 2 enums, no output schema, and a complex collection workflow, the description covers the essential workflow (collect → report_id → query with other tools) and the key runtime caveat. It doesn't explain error conditions or prerequisites, but those are partially covered by schema parameter descriptions. Overall, the context is sufficient for an agent to understand when and how to invoke the tool.

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

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

Schema description coverage is 88%, so the parameters are well-documented in the schema. The description itself adds no parameter-level detail, focusing instead on the tool's purpose and workflow. Since the schema already explains each parameter, the baseline of 3 applies and no extra semantic value is provided by the description.

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

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

The description clearly states the tool 'Run a feature-rich Nsight GPU Trace replay' and 'return a report_id', distinguishing it from sibling query tools like list_gpu_trace_reports and get_gpu_trace_report_overview. The verb 'collect' is reinforced by 'retain its report and auto-export tables', leaving no ambiguity about its role as the collection step.

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

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

The description explicitly directs users to 'Query that id with the metric, range, trace-information, and shader-occupancy tools', establishing this as the collection step before analysis. It also cautions that it 'can take several minutes', implying it is not for quick operations. However, it does not name alternative collection tools or mention when not to use it, leaving some room for improvement.

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

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

The description adds valuable behavioral context beyond the annotations: it explains the temporary file behavior when output_path is absent, the saving behavior when output_path is provided, and the overwrite requirement. This complements the destructiveHint annotation by detailing the specific destructive/overwrite condition.

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

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

The description is concise and well-structured, with the purpose stated first and behavioral details following in a logical order. Every sentence adds relevant information with no redundancy or fluff.

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

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

The description covers the core use case and the key behavioral nuances (temporary files, saving, overwrite). It does not explain the include_image parameter, but overall it provides enough context for the agent to select and use the tool effectively, especially given the simple schema and absence of an output schema.

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

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

With only 25% schema description coverage, the description partially compensates by explaining the effects of output_path and overwrite. However, it does not mention include_image, leaving one of the four parameters undocumented in both schema and description. The coverage is not fully complete.

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

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

The description clearly states the tool extracts the final-present screenshot from a capture, using specific verb 'extract' and resource 'capture'. This distinguishes it from sibling tools like inspect_capture or analyze_capture, which focus on analysis rather than image extraction.

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

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

The description implies when to use this tool (when you need the screenshot from a capture) but does not explicitly mention alternatives or provide exclusions. There is no direct comparison to sibling tools or guidance on when not to use it, making the usage context reasonably clear but not fully explicit.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds a behavioral detail beyond annotations: credential-shaped values are redacted. It also mentions optional modes and pagination, which are useful behavioral context.

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

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

Two concise, well-structured sentences. The first sentence states the purpose and key features; the second adds a security-relevant behavior. No redundancy or fluff.

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

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

The description covers the main functionality but lacks detail on output format, pagination mechanics, or how to distinguish this from sibling tools like list_capture_events. With no output schema and many related tools, more explicit guidance would be beneficial.

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

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

Schema description coverage is only 20% (only capture_path has a description). The description compensates by indirectly explaining errors_only (error-only mode), search (text search), and limit/offset (pagination). However, it does not explicitly detail parameter interactions or default behavior.

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

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

The description clearly states the tool reads captured Nsight/application log messages, with specific verb and resource. It distinguishes from sibling tools like inspect_capture or analyze_capture, which target different resources.

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

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

The description implies usage for reading logs with options (error-only, search, pagination), but does not explicitly state when to use this tool versus alternatives or provide exclusions. Sibling tools like list_capture_events or get_capture_logs could overlap, and no clear criteria are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds useful behavioral context by noting that credential-shaped values are redacted, which is not expressed in annotations. It also clarifies the contents (collection and replay configuration), providing value beyond structured fields.

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

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

Two sentences with no redundancy. The first sentence is front-loaded with the primary function, and the second adds a critical security-related detail. Every word earns its place.

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

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

The tool has no output schema and moderate complexity with four parameters. The description covers the core function and redaction but omits return format, pagination behavior, and how filtering works. Given the absence of an output schema, a bit more detail about the response structure would improve completeness.

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

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

Schema description coverage is only 25% (only report_id has a description), and the tool description does not explain limit, offset, or filter_regex. While parameter names are somewhat self-explanatory, filter_regex's target is ambiguous and could refer to filtering the name/value table, which the description does not clarify. The description fails to compensate for the low schema coverage.

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

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

The description clearly states the tool reads the exported Trace Information name/value table, including collection and replay configuration. This is a specific verb-resource combination that distinguishes it from sibling tools like get_gpu_trace_report_overview or get_gpu_trace_summary, which focus on overviews or summaries rather than the raw table. However, it doesn't explicitly name alternatives or contrast its scope.

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

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

The description implies usage for reading exported trace metadata, but it does not provide explicit guidance on when to use this tool versus siblings, nor does it mention exclusions or alternative tools. The context of 'exported' and 'name/value table' gives some situational framing, but the guidance remains implicit rather than direct.

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

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

Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by noting the report is 'retained' and by detailing the version-matched embedded protobuf schema inventory, which goes beyond a bare 'inspect' call. It does not contradict annotations.

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

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

The description is a single, front-loaded sentence that starts with the action 'Inspect' and then lists the return items without any filler. Every clause provides useful detail, making it concise yet comprehensive. It is appropriately sized for the tool's complexity.

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

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

Given that there is no output schema, the description must explain what the tool returns, and it does so thoroughly: frame timing, queues, counts, timestamp coverage, shader-profiler inventory, and schema inventory. With read-only annotations and a single documented parameter, this is complete enough for an agent to select and invoke the tool correctly.

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

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

There is only one parameter, report_id, and the schema describes it as 'GPU Trace report session id returned by collect_gpu_trace_report or open_gpu_trace_export.' Since schema description coverage is 100%, the baseline is 3. The tool description itself adds no parameter-specific meaning beyond what the schema already provides.

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

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

The description uses the specific verb 'Inspect' with a clear resource: 'the retained .ngfx-gputrace WRPV container.' It then enumerates the exact data returned (frame timing, queues, counts, timestamp coverage, shader-profiler inventory, protobuf schema inventory), making it unambiguous and easy to distinguish from sibling tools like get_gpu_trace_summary or inspect_capture.

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

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

The description clearly implies when to use this tool: when you need an overview of a retained GPU trace report's internals. It doesn't explicitly mention alternatives or exclusions, but the specific phrasing 'retained .ngfx-gputrace WRPV container' and the detailed return list make the usage context obvious. This is a clear context without explicit alternative guidance, so it fits a 4.

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

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

Annotations provide no safety hints (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It discloses that the tool executes instrumented GPU work and may take minutes, which is meaningful beyond the annotations. It does not mention artifact cleanup, but that is covered in the schema parameter description, so this is adequate.

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

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

The description is exactly two sentences: the first states the purpose and specific outputs, the second adds the execution time caveat. No redundant explanations, well front-loaded, and every sentence contributes value.

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

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

With no output schema, the description lists the returned data fields clearly, giving the agent a good sense of output. It also conveys the runtime cost. It could mention prerequisites like capture existence or architecture override, but the schema and sibling tool context fill most gaps. Overall sufficient for a moderately complex tool.

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

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

Schema description coverage is 80%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already documents; it only states the tool operates on a capture and returns summary data. The schema handles parameter details effectively.

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

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

The description clearly states the tool runs Nsight GPU Trace and returns a specific set of summary metrics (Summary-tab range, Top-Level Throughput, Active Threads Per Warp, SM Warp Occupancy). The verb 'Run' and specific resource distinguish it from sibling tools like get_gpu_trace_report_overview or summarize_gpu_trace_range.

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

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

The description implies the tool is used when a summary of GPU trace metrics is needed and explicitly warns about execution time ('can take several minutes'). However, it does not explicitly state when to use this tool over alternatives like collect_gpu_trace_report or analyze_capture, nor does it provide exclusion criteria.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds useful behavioral context by disclosing that 'Embedded byte arrays are represented by byte length, not dumped.' This clarifies a potential data-format surprise, but no other behavioral traits (e.g., error behavior, performance) are disclosed.

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

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

The description is two sentences, each earning its place. The first sentence lists the return content comprehensively; the second clarifies a critical edge case about byte array representation. No redundant or vague wording.

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

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

There is no output schema, but the description thoroughly describes the returned object's contents and handles a common gotcha (byte arrays). It does not mention error scenarios or how to obtain event_id (though that is covered by schema). Overall, the description is complete for a getter tool of moderate complexity.

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

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

Schema description coverage is 100%, with both parameters already described in detail (event_id pattern and report_id format). The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description clearly states it 'Return[s] one decoded GPU Trace command-stream call' and enumerates the specific contents returned: full typed arguments, return value, object handles, timestamp boundaries, pipeline stages, and HES correlation ids. This is a specific verb+resource that distinguishes it from sibling tools like list_gpu_trace_timeline_events.

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

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

The description implies usage for fetching a single decoded timeline event but does not explicitly state when to use it vs. alternatives. It does not mention that event_id comes from list_gpu_trace_timeline_events; that relationship only appears in the schema. No when-not or alternative guidance is given.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral details: it explicitly states that environment values are never returned and that the operation does not replay the frame. These disclosures go beyond the annotations and clarify side-effect boundaries.

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

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

The description is a single, well-structured sentence that front-loads the main purpose and includes crucial caveats. Every phrase earns its place, with no redundant or extraneous information.

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

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

For a read-only inspection tool with 2 parameters, good annotations, and no output schema, the description covers the essential aspects: what is read, the non-replay guarantee, and the environment value restriction. It is complete enough for an agent to select and invoke the tool correctly without additional context.

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

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

The schema already documents both parameters thoroughly (capture_path and include_environment_names with descriptions). The description's note about environment values reflects the same constraint already present in the schema, adding no new parameter-level meaning. With 100% schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as reading capture metadata (identity, application/GPU/API/version, portability flags, replay incompatibilities) and explicitly distinguishes it from replaying or analyzing the frame. This is a specific verb+resource statement that contextualizes the tool's purpose among siblings like analyze_capture.

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

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

The phrase 'without replaying the frame' implies a usage context, suggesting it is appropriate for lightweight inspection before or instead of full replay/analysis. However, it does not explicitly name alternative tools or provide exclusion scenarios, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds useful behavioral context: it says results exclude call parameters and timings, which clarifies return content, and 'Page through' indicates pagination behavior. This goes beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary action, and every sentence adds value: the first states what it does, the second covers filters and return limitations. No wasted words.

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

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

With no output schema, the description adequately explains return values (names and indices, not parameters or timings) and the filtering/pagination features. It could add ordering or more detail on result structure, but for a list tool with these annotations, it is sufficiently complete.

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

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

Schema description coverage is only 13% (only capture_path has a description), so the description must compensate. It does by mapping filters to parameters: function-name regex, category, thread, and event-index range. It also implies limit/offset via 'Page through'. This provides meaningful semantics beyond the raw schema.

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

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

The description clearly states the tool pages through an exported API function stream, which is specific and distinguishes it from sibling tools like list_capture_resources or get_capture_logs. It also clarifies that results contain names and indices, not call parameters or timings, further differentiating its purpose.

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

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

The description provides clear context by explaining the filtering options (function-name regex, category, thread, event-index range) and the pagination nature. However, it does not explicitly mention when not to use this tool or point to alternative tools, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying that results are 'captured object identities' (not full captures) and that filtering can be done by substrings and access-flag presence. No contradictions 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.

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

The description is a single, front-loaded sentence that packs the action (page through), the resource (captured object identities), and all key filter axes. No filler, redundancy, or repetition of schema details.

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

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

With 9 parameters, no output schema, and no sibling differentiation, the description covers the main filtering capabilities but omits return format, pagination behavior (beyond implying paging), and possible error conditions. Annotations cover safety, but the tool's output structure is undocumented, which is a notable gap for users.

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

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

Schema coverage is only 11% (only capture_path is described). The description compensates by naming six filter dimensions (UID, API, type, object-name substring, creator-function substring, nonzero access flags) that map to uid, api, type_name, name_contains, creator_contains, and accessed_only. However, it leaves pagination parameters (limit, offset) and their semantics implicit, and does not clarify exact parameter meanings beyond the names.

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

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

The description uses a specific verb ('Page through') and resource ('captured object identities'), and enumerates filter dimensions (UID, API, type, etc.). This clearly distinguishes it from sibling listing tools like list_capture_events or list_gpu_trace_reports, which target different resource types.

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

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

The description implies usage for browsing/filtering capture resources but provides no explicit when-to-use guidance or alternatives. It does not mention when not to use this tool, nor does it reference sibling tools. The context is clear but exclusions are absent, so 'implied usage' is the best fit.

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

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

Annotations already declare read-only and idempotent behavior, so the bar is lower. The description adds value by specifying what data is returned (full marker path, hierarchy, timing bounds, paired event ids) and connects the marker ids to PC-sampling scoping, giving behavioral context beyond the structured annotations.

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

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

The description is two sentences, front-loaded with the primary action and content, followed by a practical use case. Every phrase earns its place; no filler or redundant information.

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

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

Given the complexity (7 parameters, no output schema, low schema coverage), the description is incomplete. It lists what the returned ranges contain but fails to explain how filtering parameters (e.g., path_regex, queue_index, exact_timing_only, minimum_duration_ms) affect results, nor does it describe ordering, pagination behavior, or edge cases.

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

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

With only 14% schema description coverage (only report_id is described), the description must compensate for the other six parameters. It does not explain path_regex, queue_index, exact_timing_only, minimum_duration_ms, limit, or offset. No parameter semantics are provided beyond the implicit notion of pagination from 'Page through'.

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

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

The description clearly states the tool's function with a specific verb ('Page through') and resource ('D3D12 BeginEvent/EndEvent ranges decoded from the binary report'). It lists the key content returned (marker path, hierarchy, timings, uncertainty bounds, paired event ids), which distinguishes it from siblings like list_gpu_trace_ranges and list_gpu_trace_timeline_events.

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

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

The description implies a usage context: you would use this to retrieve marker ranges for scoping PC-sampling analysis. However, it does not explicitly state when to prefer this over sibling tools like list_gpu_trace_ranges or list_gpu_trace_timeline_events, nor does it mention any exclusions or alternatives.

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

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

Beyond the annotations (readOnly, idempotent, not destructive), the description adds useful behavioral context: it mentions pagination ('page through') and that metrics 'preserve their raw Nsight names and numeric values' while adding 'inferred display groups and units'. This explains behavior not already captured by annotations.

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

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

The description is two sentences, front-loaded with the core action. Every sentence adds value: the first states the purpose, the second details the output characteristics. No filler or redundancy.

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

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

Given the tool has 8 parameters and no output schema, the description provides a decent high-level overview but does not mention return structure or pagination details. It is adequate for tool selection but not for full invocation understanding, especially since sibling tools are similar.

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

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

Schema description coverage is only 25% (only report_id and range_id have descriptions). The description mentions 'marker range' implicitly referencing range_id but does not explain kind, sort_by, limit, offset, group, or name_regex. With such low schema coverage, the description should compensate but does not.

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

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

The description explicitly states 'Page through every exported GPU Trace metric for the full frame or a marker range', which clearly identifies the action (page through list), the resource (GPU Trace metrics), and the scope (full frame or marker range). It also distinguishes this from sibling tools like list_gpu_trace_timeline_events by focusing on metrics.

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

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

The description provides clear context on when to use the tool: when you need all exported GPU Trace metrics for a full frame or a marker range. It does not explicitly exclude alternatives or name a more specific tool, but the context is sufficient for basic selection.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds pagination behavior and a note about the returned range_id being usable downstream, which is useful but does not reveal deeper behaviors like defaults or ordering.

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

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

Two dense sentences, front-loaded with the primary action and clearly stating the return value's utility. No wasted words or redundancy.

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

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

The tool has 6 parameters and no output schema, so the description carries the burden of explaining filtering semantics and return structure. It only mentions the returned fields superficially and never clarifies how filters work, leaving significant gaps for an agent to use it correctly.

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

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

Schema description coverage is only 17% (only report_id is explained). The description fails to explain limit, offset, path_regex, maximum_depth, or minimum_duration_ms, leaving agents to infer filters from names alone. No attempt is made to compensate for the missing parameter details.

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

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

Clearly states it pages through exported marker/regime ranges and lists key attributes like hierarchy, path, parent id, and duration. The resource is specific enough to distinguish from timeline-event tools, though it does not explicitly contrast with the similarly named sibling list_gpu_trace_marker_ranges.

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

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

Provides clear context that returned range_id can be used by metric, summary, and shader-occupancy tools, implying when to use this tool. However, it does not mention alternatives or exclusions, so it stops short of full guideline coverage.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context by noting that only 'queryable' reports are listed and that they are 'currently registered' in the MCP process, indicating the list is dynamic. However, it does not describe the return format or any extra behavior.

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

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

The description is a single sentence that is front-loaded with the action ('List') and the object ('queryable GPU Trace reports'). There is no redundancy or extraneous information, making it highly concise and well-structured.

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

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

Given the simplicity of the tool (no params, no output schema, strong annotations), the description is mostly complete. It clarifies the scope (queryable, currently registered) but does not detail what fields or metadata the returned list contains, which could be useful since there is no output schema.

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

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

The tool has zero parameters, so the empty schema fully covers parameter documentation. With 0 params, the baseline is 4, and the description does not need to explain any parameter semantics.

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

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

The description uses the specific verb 'List' and clearly identifies the resource as 'queryable GPU Trace reports' with scope 'currently registered in this MCP process.' This makes the purpose unambiguous and distinguishes it from sibling tools that list events, metrics, or capture resources.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The intended usage is implied by the verb 'List' and the resource, but there is no contextual guidance such as 'use this to see available reports before analyzing a trace.'

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. Beyond that, the description adds valuable caveats: 'A blob reference does not imply complete source/call-stack debug information' and 'Sample counts cover Entire Trace.' These clarify data semantics and scope, providing extra behavioral context not present in annotations.

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

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

The description is three sentences. The first sentence is dense but efficiently lists all key output fields. The second and third sentences each add a critical caveat without fluff. Every word serves a purpose, and the structure is front-loaded with the main action and resource.

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

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

The tool has 7 parameters and no output schema, and schema descriptions cover only 29% of them. The description explains output contents and a couple of relevant caveats, but it fails to clarify the behavior of shader_regex and include_inactive, or how pagination (limit/offset) works. This incompleteness is significant for an agent to select and invoke the tool correctly, especially given the absence of an output schema.

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

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

Schema description coverage is only 29%, so the description must compensate. It does add meaning for stage and debug_blob parameters by mentioning 'exact shader stage/name/hash' and 'debug-blob reference state,' but it omits explanations for shader_regex, include_inactive, limit, and offset. These parameters remain undocumented in both schema and description, leaving significant ambiguity for correct invocation.

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

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

The description clearly states 'Return the Shader Pipelines table grouped by Shader Object' with a precise list of output fields (shader stage/name/hash, sample counts, DXIL/SPIR-V correlation, debug-blob state, referencing pipelines). It distinguishes from siblings by the explicit grouping and the detailed output, especially versus list_gpu_trace_shader_pipelines, which likely provides a different view.

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

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

The description implies use when needing shader-object-level detail, but it does not explicitly state when to prefer this tool over alternatives like list_gpu_trace_shader_pipelines or list_gpu_trace_shader_occupancy. No exclusions or alternative references are provided, so usage context is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: it states the exact return contents (shader name/hash, aggregate warps/occupancy) and explicitly warns that the stage is heuristic, which goes beyond the structured annotations.

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

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

The description is two sentences, front-loaded with the core action, and contains no filler. Every sentence adds meaningful detail without redundancy.

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

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

For a 7-parameter tool with no output schema, the description gives a clear purpose and return value overview, but leaves out important parameter semantics and usage guidelines. It is adequate for simple listing use cases but incomplete for understanding filter behavior and alternatives.

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

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

Schema description coverage is only 29%, so the description must compensate. It mentions the 'full trace or one marker range' which clarifies range_id, but it does not explain limit/offset, shader_regex, include_inactive, or minimum_occupancy_percent. These filter and pagination parameters remain undocumented in both the schema and the description.

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

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

The description clearly states a specific verb ('Page through') and a specific resource ('per-shader PC-sampler occupancy rows'), and distinguishes itself from siblings by focusing on occupancy data and the scope (full trace or one marker range). It also notes the return details, making the purpose unambiguous.

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

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

The description implies usage for retrieving shader occupancy data, and mentions the optional marker range scope, but does not explicitly compare to alternatives like list_gpu_trace_shader_pipelines or analyze_gpu_trace_pc_sampling. No 'when not to use' guidance is given, so usage context is only implied.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond these annotations, including pagination ('Page through'), joining with raw PC samples and exported metrics, and the return of an explicitly named estimate as fallback/comparison. This enriches the agent's understanding of the tool's behavior.

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

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

The description is two sentences with a dense, information-rich first sentence listing many output fields. It is front-loaded with the action and the second sentence adds the estimate fallback. While efficient, the first sentence is a long run-on that could be broken up for readability.

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

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

With no output schema, the description does list many returned data fields, which helps. However, it does not explain the pagination response structure, the exact nature of the 'explicitly named estimate,' or the meanings of several key parameters. Given the tool's complexity and low schema coverage, the description leaves notable gaps.

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

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

Schema description coverage is only 25%, with only report_id and debug_blob having descriptions. The tool description does not compensate for this by explaining parameters like kind, sort_by, shader_regex, or include_inactive. It only hints at pagination with 'Page through,' leaving most parameter semantics undocumented.

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

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

The description clearly states the tool pages through shader pipeline data decoded from a binary report and lists specific output fields such as pipeline type/name, shader stage/hash, and sample counts. This distinguishes it from sibling tools like list_gpu_trace_shader_occupancy and list_gpu_trace_shader_objects by focusing on pipelines with detailed joined data.

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

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

The description gives clear context for when to use this tool (when shader pipeline data with sample counts and shader details is needed) but does not explicitly name alternatives or exclusion criteria. It implies usage through the detailed data description but lacks a when-not-to-use comparison.

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

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

Annotations already declare read-only and idempotent behavior; the description adds useful context about decoded command-stream calls and the meaning of coalesced intervals. This clarifies result semantics beyond the annotations, though it does not detail pagination or result structure.

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

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

The description is two focused sentences with no filler, front-loading the main action and resource. The second sentence adds a relevant nuance about coalesced intervals without redundancy.

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

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

The description covers the core purpose and one nuanced concept, but with 11 parameters, no output schema, and many sibling tools, it omits alternatives, filtering capabilities, and return structure. It is adequate but leaves significant gaps for a tool of this complexity.

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

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

With schema description coverage at only 27%, the description needed to compensate for undocumented parameters like limit, offset, sort_by, and the various filters. It only indirectly references timing groups via 'coalesced intervals' but does not map them to exact_timing_only or unique_timing_groups, nor does it explain the other parameters.

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

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

The description clearly states the tool lists (pages through) queue command-stream calls decoded from .ngfx-gputrace files, including queue identity and timestamp intervals. The specific verb and resource distinguish it from sibling tools like list_gpu_trace_ranges or get_gpu_trace_timeline_event.

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

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

No explicit guidance is provided on when to use this tool versus alternatives like get_gpu_trace_timeline_event or list_gpu_trace_ranges. The description implies it is for browsing timeline events but does not state exclusions or alternative use cases.

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

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

Annotations already declare it as read-only, idempotent, and non-destructive. The description adds context about locating a specific executable and reporting version/cache status, but it does not disclose potential edge cases (e.g., what happens if the executable is not found) or what 'MCP cache status' entails. It aligns with annotations without contradictions.

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

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

The description is a single, well-structured sentence that front-loads the primary action and clearly states what will be reported. Every word adds value, with no redundancy or fluff.

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

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

Given the tool is a simple status checker with no parameters and strong annotations, the description adequately covers its function and expected output (version and cache status). However, it lacks detail on the return format or what the cache status represents, which would be more helpful if no output schema is provided.

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

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

The tool has zero parameters, so the description has no parameters to clarify. Per the guidelines, a zero-parameter tool earns a baseline of 4. The description does not need to add parameter-level details.

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

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

The description clearly states the tool's purpose: locating the local ngfx-replay executable and reporting its version and MCP cache status. It uses specific verbs ('locate', 'report') and a specific resource, distinguishing it clearly from sibling tools that focus on capture analysis.

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

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

The description implies this tool is for checking the local Nsight Graphics installation and cache status, but it does not explicitly state when to use it versus the many sibling analysis tools, nor does it mention any alternatives or exclusions. It relies on the reader to infer that it is a preliminary health/status check.

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

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

The description adds non-obvious behavior beyond the annotations: it explicitly states 'without replaying the capture', requires specific files (FRAME.xls and GPUTRACE_FRAME.xls), and mentions registering a queryable session. These details are not available from the annotations and are valuable for setting expectations.

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

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

The description is two concise sentences: one states the operation and key benefit, the other states the precondition. Every word earns its place, with no filler or redundancy.

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

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

For a single-parameter tool with strong annotations, the description covers the operation, prerequisites, and a key behavioral trait (no replay). The only minor gap is that it doesn't state what the tool returns, but given the absence of an output schema and the simple nature of the tool, this is acceptable.

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

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

The input schema already provides a complete description of export_path (100% coverage). The description complements this by clarifying the required directory contents, which adds meaningful context about what the path should point to and how to validate it.

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

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

The description uses a specific verb ('Open'), names the resource ('existing Nsight GPU Trace auto-export directory'), and explains the outcome ('register it as a queryable report session without replaying the capture'). This distinguishes it from sibling tools like list_gpu_trace_reports or analyze_capture.

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

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

It provides clear context: use this for an existing export that you want to query without replaying the capture. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions.

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

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

With no safety annotations (all hints false), the description carries the burden of disclosure. It transparently reveals that the tool executes GPU work in a hidden, vsync-off window and is not a static read, which is critical behavioral context. It does not describe all side effects (e.g., file creation in output_directory), but the disclosed behaviors are valuable and accurate.

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

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

The description is two sentences, front-loaded with the main action and output, followed by a crucial behavioral warning. Every word contributes value, with no redundancy or filler. It is an exemplary concise yet informative structure.

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

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

The description gives a solid overview of the tool's purpose and execution, but with no output schema, it does not explain the return format or how the summary is delivered (e.g., stdout, file). The mention of output_directory in the schema implies file artifacts, but the description doesn't elaborate. For a moderately complex tool with six parameters, more detail on outputs and workflow would be needed for full completeness.

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

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

Schema description coverage is 67%, leaving loop_count and timeout_seconds without descriptions. The tool description does not compensate for these gaps; it only mentions 'optional GPU frame-time' which maps to collect_gpu_time, adding no new meaning beyond the schema. Thus, the agent may not understand the semantics of two parameters, making this dimension weak.

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

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

The description clearly states the tool's function with specific verb ('Replay' and 'summarize') and resource ('capture'), and lists precise measurements (CPU submit, finish-wait, reset, FPS, screenshot-difference, optional GPU frame-time). This distinguishes it from sibling tools like inspect_capture or analyze_capture by focusing on replay-based profiling.

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

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

The description provides clear context about when this tool is appropriate: when you need per-iteration profiling measurements from a captured replay. It also gives an implicit exclusion by stating 'This executes GPU work; it is not a static read,' signaling that it is not for passive inspection. However, it does not name alternative tools explicitly, so it falls short of a 5.

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

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

Adds explicit detail about what is deleted: 'Temporary artifacts created without output_directory are deleted; user-selected persistent output directories are never deleted.' This goes beyond the destructiveHint annotation by specifying exactly what is destroyed, which is critical for a destructive operation.

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

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

Two sentences, front-loaded with purpose, every sentence earns its place. No fluff or redundancy.

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

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

Simple tool with one well-documented parameter, annotations covering safety (destructive, idempotent), and description covering the key behavioral nuance about artifact deletion. This is complete for the tool's complexity.

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

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

Schema description coverage is 100% and report_id is well-documented in the schema. The tool description adds no additional parameter meaning, so baseline of 3 is appropriate.

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

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

Description states a specific verb 'Unregister' with a specific resource 'GPU Trace report', making it clear what the tool does. It is distinguished from siblings by being the only 'release' tool and its scope of managing report sessions.

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

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

Usage context is implied but not explicit. The description doesn't mention when to use this tool vs alternatives or provide exclusions, though the destructive nature and artifact handling give some situational context. No alternatives are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by naming the specific metrics returned, but it does not provide additional behavioral context such as output format, pagination, or any side effects. Given the annotations, the description is adequate but not rich.

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

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

The description is a single sentence of moderate length, front-loading the verb and list of metrics. However, the word 'same' is somewhat awkward and redundant given the sentence already lists the metrics. Overall, it is concise and informative without wasting words.

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

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

For a tool with two well-documented parameters and comprehensive safety annotations, the description provides the essential context: what metrics are returned and the scope (full trace or range). The lack of an output schema makes the metric listing particularly helpful. It does not explicitly state the return format, but the metrics imply a structured summary, which is sufficient for this simple tool.

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

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

The input schema already documents both parameters with descriptions, giving 100% coverage. The description adds the key semantic that the tool can operate on the full trace (when range_id is omitted) or on a specific exported marker range, which is not explicit in the schema. This goes beyond the baseline and clarifies the role of range_id.

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

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

The description clearly states the tool returns a summary with specific metrics (Top-Level Throughput, Active Threads Per Warp, SM Warp Occupancy) for a GPU trace or marker range. However, the phrase 'Return the same ... summary' is ambiguous about what it is the same as, which slightly weakens clarity and fails to explicitly name a sibling tool like get_gpu_trace_summary.

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

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

The description mentions 'for the full trace or one exported marker range,' implying when to use it (when you need these metrics for a full trace or a range). It does not provide explicit alternatives or exclusions, such as naming get_gpu_trace_summary for the full-trace-only case. The usage context is implied rather than explicitly contrasted with siblings.

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