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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains dependencies, fallback behavior for untimed passes ('fill workload when untimed'), and what analytical outputs to expect. It could go further by stating that the operation is read-only or how it handles invalid/old captures, but the disclosure is otherwise strong.

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 dense but every clause earns its place: it states the goal, lists the verdict and ranked analyses, notes the conditional requirements in parentheses, and closes with an explicit recommended pairing. Important conditions are front-loaded, and there is no filler or repetition.

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 having no output schema, the description enumerates what the tool returns: frame budget, bound verdict, ranked render passes with size/format/MSAA/blend/shader annotations, bottleneck classification, heuristic issues, and ranked suggestions. It also covers the necessary capture conditions. For a single-optional-parameter analysis tool, nothing essential is missing.

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 only parameter, captureId, is already fully described in the schema as 'Capture id (default: most recent)', and schema coverage is 100%. The description adds useful capture-quality context via the capture_frames pairing but does not add parameter-specific semantics beyond the 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 opens with a specific verb-resource pair ('Diagnose a capture's performance') and a distinct deliverable ('concrete improvement suggestions'). It then enumerates unique outputs—frame budget, CPU/GPU/vsync verdict, ranked passes with bottleneck annotations, heuristics—that clearly set it apart from siblings like get_frame_stats or get_capture_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 gives explicit prerequisites: a live capture for CPU/refresh context and profilePasses:true for GPU time, plus a recommended capture_frames invocation. It does not explicitly discuss when not to use the tool or mention alternative tools, so it stops just short of full routing 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?

No annotations are provided, so the description carries the full burden. It adds useful behavior details—new tabs and navigations are instrumented automatically—and implies existing tabs are not unless reloadPages is set. However, it does not disclose potential side effects, prerequisite conditions beyond the flag, error behavior, or what 'instrumented' entails in practice, leaving gaps for a tool with no annotation coverage.

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

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

The description is two concise sentences with zero fluff. The key action is front-loaded, and the behavioral note is appended efficiently. Every word earns its place, matching the standard of the high-calibration example.

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 an attach tool with no output schema, the description covers the essential info: prerequisite (already-running with debug port), core action, and automatic instrumentation. It is missing return format and error handling, but given the tool's simplicity and the schema covering parameters, it is mostly complete. The absence of explicit return-value documentation is a minor gap.

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%, so both parameters are already documented. The description adds no extra meaning beyond the schema's definitions, hitting the baseline for full coverage. It references 'instrumented automatically' which relates to tool behavior rather than parameter details, so no additional semantic value is provided.

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 attaches to an already-running Chrome/Edge with the --remote-debugging-port flag. It uses a specific verb (attach) and resource, and the behavior of instrumenting new tabs/navigations distinguishes it from sibling tools like launch_browser or open_page.

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 clearly indicates when to use the tool (when a browser is already running with the debugging port). However, it does not explicitly name alternatives or state when not to use it, such as preferring launch_browser for a fresh browser instance. The context is clear but 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?

No annotations are provided, so the description carries the full burden. It clearly states what information is reported, and the content strongly implies a read-only status check with no side effects. However, it does not explicitly state that it is non-destructive, nor does it describe any potential prerequisites or error conditions. For a status tool this is acceptable but not fully transparent.

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 lists all key aspects without redundancy. Every word contributes to the functional purpose, and it is highly efficient.

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 no parameters and no output schema, the description covers the essential information an agent needs: what is reported (connection status, method, targets, pages). It could go into more detail about the exact format of the report, but given the low complexity, the description is sufficiently complete for correct usage.

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 takes zero parameters, and the schema coverage is 100% (empty schema). According to the rubric, this warrants a baseline of 4. The description does not need to explain parameters, and no additional parameter semantics are required.

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 'Report' and clearly identifies the resource ('controlled browser') and the exact information delivered (connection status, connection method, instrumented targets, and bridge-connected pages). This distinguishes it from sibling tools like launch_browser or attach_browser, which perform actions rather than report state.

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 makes the usage context clear: it is a status query about the browser bridge. It implies when to use it (before or after connection operations) but does not explicitly mention alternatives or when not to use it. However, given that no sibling tool has a similar reporting function, the usage scenario is unambiguous enough.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose useful traits: captures can be heavy/light (payloads:'none' for light capture), returns a summary, and the implied behavior that captures could be large (mention of shrinking via passLabel). However, it lacks explicit notes on side effects, error conditions, or whether the operation modifies state. It adds context but not a comprehensive behavioral profile.

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?

Four sentences, front-loaded with the core purpose, then flow into usage guidance. No redundant repetition of schema details, and each sentence carries meaningful information. Structure is logical and efficient, though a bulleted format could slightly improve scannability.

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, no output schema, and no annotations, the description is fairly complete. It explains the core behavior, provides performance-specific guidance, and names a follow-up tool (analyze_performance). It doesn't cover every edge case (e.g., error handling, capture persistence), but covers the primary usage scenarios an agent needs to invoke 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 coverage is 100%, so baseline is 3. The description enhances parameter semantics by linking profilePasses and payloads to performance analysis ('set profilePasses:true (and payloads:"none" for a light perf-only capture)'), and clarifying the implication of performance requests. This adds usage context beyond the schema's individual parameter descriptions, justifying a 4.

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 states the specific action (capture one or more WebGPU frames) and the resource (a connected page), then details the returned summary (command/draw/pass counts, object counts, validation errors, flagged issues). It distinguishes itself from analyze_performance by explicitly naming that as the performance-analysis follow-up, and mentions list_pages for initial selection. Clear and specific, though it doesn't explicitly contrast with all capture-related siblings like get_capture_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?

Provides explicit when-to-use guidance: 'Use list_pages first if unsure' establishes a prerequisite, and 'For a PERFORMANCE analysis, set profilePasses:true ... then call analyze_performance' gives a concrete usage pattern. It further states that a performance request implies profilePasses:true, offering a clear rule for invocation. This goes beyond generic context to actionable instructions.

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 annotations provided, the description carries the full behavioral burden, and it delivers: it discloses the non-obvious layout-resolution behavior (auto-derived from the draw's pipeline unless overridden), the output format via a concrete example, and the exact expected input provenance. It does not cover failure modes for invalid indices, but the core behavior is well 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?

Two sentences with zero filler: the first front-loads purpose and shows the output shape, the second handles the critical input provenance and layout resolution. Every clause 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 6 params, nested layout objects, and no output schema, the description compensates well with a workflow reference to get_draw_state and an example of the return format. The only notable gap is no explicit contrast with read_buffer and no error-condition guidance, but nothing essential to calling it correctly is missing.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it connects commandIndex to get_draw_state's bufferDataCommandIndex, treats layout and pipelineId as alternative override paths, and clarifies the auto-derived default. This is a clear step above the raw schema text.

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 opens with a specific verb+resource+outcome: 'Decode the first N vertices of a captured vertex buffer into per-attribute numbers' and includes a concrete output example ('attribute @location(2) (uv) = (0,0)'). This clearly differentiates it from raw-read siblings like read_buffer, which would deliver bytes rather than decoded attributes.

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 gives explicit operational context: the required commandIndex must come from get_draw_state's bufferDataCommandIndex, and it explains when to rely on the pipeline-derived layout versus passing layout/pipelineId as overrides. It stops short of a 5 because it does not explicitly name when-not-to-use conditions or contrast itself against read_buffer.

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 annotations, the description carries the burden, and it does disclose the core behavior: it compares resolved draw state rather than raw commands and lists the compared categories. It doesn't explicitly state return shape or read-only nature, but 'diff' strongly implies a non-mutating comparison.

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?

A single front-loaded sentence states the operation and its scope, followed by a use-case clause. No filler or redundant restatement of the tool name.

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 low-complexity, three-parameter tool with complete schema descriptions, the description is largely sufficient. It lacks an explicit statement of the output shape, but the absence of an output schema and the simple diff semantics keep this to a minor gap.

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%, so the schema already documents cmdA, cmdB, and captureId. The description adds context that these are draw commands to compare, but does not need to repeat parameter details; baseline 3 applies.

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 ('structurally diff') and a precise resource ('resolved state of two draw commands'), and enumerates the state components (pipeline, bind groups, vertex/index bindings, draw params). This distinguishes it from single-draw inspectors like get_draw_state.

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 gives a concrete scenario: use when a working and broken draw share a pipeline and the difference likely lies in bound resources. It does not explicitly name alternatives or state when not to use, but the context is clear enough for an agent to select it.

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?

No annotations are provided, so the description carries the behavioral burden. It discloses that output depends on capture configuration: profilePasses:true adds gpuTiming, and live-page captures add frameBudget. It also lists heuristic issue reporting. The read-only nature is implied by 'summarize' rather than explicitly stated, but there is no sign of mutation or side effects.

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 dense sentences with no filler. The main purpose and result contents are front-loaded, the conditional additions are grouped logically, and the alternative tool is stated in the final sentence. Every sentence 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?

With no output schema, the description does a good job enumerating what the summary will contain and which fields appear conditionally. Some terms like 'derived render statistics' are slightly vague, and it does not state whether the capture must already be loaded, but an agent has enough information to call the tool correctly with captureId and toggle flags.

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 each parameter is already well documented, including defaults and what toggling a boolean controls. The description adds broader output context but does not materially deepen the meaning of any specific parameter beyond what the schema already provides, so the baseline 3 applies.

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 opens with a specific verb and resource: 'Summarize a capture,' followed by a concrete list of what the summary contains. It clearly distinguishes itself from analyze_performance by naming that sibling explicitly, so an agent can tell this is the aggregate-summary tool rather than a focused performance tool.

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 last sentence explicitly gives a when-not-to-use instruction: 'For a focused performance report, use analyze_performance instead.' It also explains conditional behavior for different capture sources, which helps the agent interpret results and decide when this tool is appropriate.

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 annotations provided, the description carries the behavioral disclosure burden. It discloses two non-obvious behaviors: the result is paginated and base64 data is stripped. It also states the entry shape. It does not discuss mutability, but 'Return' implies a read operation and the description covers the most important behavioral traits.

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 tight sentences with no filler. The primary behavior is front-loaded, and the entry-field detail earns its place by substituting for an absent output schema.

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 is sufficient for a read-only list operation with well-documented parameters. It lists return entry fields, which matters because there is no output schema. It does not mention ordering or error cases, but these are minor given the simple scope and schema coverage.

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%, so parameters are already documented with defaults and semantics. The description adds no parameter-specific detail beyond what the schema provides, which is acceptable under the baseline.

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 ('Return') and clearly names the resource: a paginated, base64-stripped slice of a capture's command list. It also enumerates the per-entry fields, so an agent can tell this is a command-list retrieval tool and distinguish it from capture summaries or validation 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 establishes clear context: use it when you need command-list entries from a capture. It does not explicitly name alternatives or exclusion conditions, but the scope is specific enough that an agent can reasonably infer when to call it.

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 annotations provided, the description carries the behavioral disclosure burden. It details what the tool resolves and returns, including per-slot bind groups, vertex buffers with capture command indices, and draw parameters. It implies a read-only diagnostic behavior without explicitly stating side effects, but the enumerated behavior is substantially transparent.

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 no filler. The primary purpose and output components are front-loaded, followed by a direct usage statement. Every clause contributes useful 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 complex GPU-state inspection tool with no output schema, the description is notably complete: it names all major output categories and clarifies vertex-buffer provenance via command indices. Together with the schema, an agent has enough information to invoke the tool correctly and interpret its result.

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%, so the schema already documents captureId and commandIndex. The description adds contextual framing around what the resolved state includes, but it does not materially extend the meaning of the parameters beyond the schema's own descriptions.

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 verb ('Resolve'), the resource ('full GPU state for a draw/dispatch command'), and enumerates concrete contents such as bound pipeline, bind groups, vertex buffers, index buffer, and draw params. This distinguishes it from sibling tools like get_commands, get_object, and decode_vertex_buffer by focusing on complete per-command GPU state.

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 states when to use the tool: 'Use this to diagnose what a specific draw actually read.' It does not provide explicit exclusions or compare itself to alternatives, but the use case is clear and actionable.

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 annotations provided, the description carries the full behavioral burden. It discloses that it samples without side effects ('without taking a capture'), provides a precise list of what the tool measures (frame rate, dropped frames, CPU submit time, etc.), explicitly notes the limitation ('GPU time is not measured live'), and states the environmental requirement (requestAnimationFrame). This is far more transparent than many tools with annotation coverage.

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

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

The description is dense but not bloated—two sentences with a trailing requirement clause. It front-loads the core purpose and return values, then adds usage guidance and a prerequisite. It could be trimmed slightly (the list of metrics is long) but every sentence earns its place, and the structure is logical.

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 no annotations, no output schema, and only two optional parameters, the description covers what the tool does, when to use it, limitations, and a prerequisite. The only minor gap is that it doesn't specify what happens if the page doesn't use requestAnimationFrame (errors? null results?), but this is a rare edge case and the description already implies the requirement clearly. Overall, an agent can call this 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?

Schema description coverage is 100%, so both pageId and durationMs are already documented in the schema. The description adds little beyond the schema's own parameter descriptions—it mentions 'short window' and 'clamped 100–10000' which are already in the schema. Baseline 3 is appropriate since the schema does the heavy lifting and the description doesn't add meaningful new 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 opens with a specific verb ('Sample'), a resource ('live page's frame-health metrics'), and a distinguishing constraint ('without taking a capture'), then enumerates the exact aggregates returned. That level of specificity lets an agent immediately separate this from sibling tools like capture_frames or analyze_performance without needing to open their schemas.

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 gives explicit when-to-use ('tell whether a page is dropping frames and whether it's CPU/main-thread bound'), a clear when-not-to-use (GPU time is not measured live, so take a capture with profilePasses:true to measure GPU time), and even names the alternative action ('take a capture with profilePasses:true'). It also states a prerequisite ('Requires the page's rendering loop to use requestAnimationFrame'). This is textbook routing.

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?

Since annotations are absent, the description carries the full burden of behavioral disclosure. It does add value by explicitly noting that base64 payloads are omitted, which is a concrete behavioral trait. However, it does not mention whether the operation is read-only, any side effects, error conditions, or permission requirements, which are important for a tool without annotation support. This is a moderate disclosure but leaves significant gaps.

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 immediately states the core action and scope, then adds the key omission detail. There is zero fluff; every word earns its place, making it easy for an agent to parse and act on efficiently.

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 relatively simple get-by-id tool with full schema coverage and no output schema, the description adequately covers what is returned and what is omitted. It could be more complete by mentioning error handling or behavior when the object is not found, but given the low complexity, the current description is sufficient for correct invocation.

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% – both objectId and captureId have descriptions in the input schema. The tool description does not add any additional parameter semantics beyond what the schema already provides, so it stays at the baseline score of 3 for high 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 verb ('Return'), the resource ('one GPU object record from a capture'), and specific context (descriptor, label, stacktrace), with base64 payloads omitted. It is specific and actionable, but does not explicitly differentiate itself from sibling tools like get_shader or get_draw_state, so it loses a point for missing cross-tool distinction.

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 the tool: when you need a GPU object record from a capture, particularly its descriptor, label, and stacktrace. However, it does not explicitly state when to prefer this tool over alternatives (e.g., get_shader for shader-specific info), nor does it mention exclusions or prerequisites. The usage context is implied but not elaborated.

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 annotations, the description carries the full behavioral burden. It accurately discloses that the tool returns source code and is read-only in nature, but it does not mention edge cases like missing source data, invalid object IDs, or error behavior. This is adequate for a simple getter but not deeply transparent.

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 with no wasted words. It states the action, the resource, and the scope ('in a capture') efficiently.

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 simple read-only getter, the description plus the complete schema covers what an agent needs to invoke it. The only minor gap is lack of detail about failure modes or unavailable source, but that is not essential for this tool's basic usage.

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%, so the baseline is 3. The description itself does not add parameter-level detail, but the schema already documents objectId and captureId clearly. No additional 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 uses a specific verb ('Return') and names the exact resource ('WGSL source code of a ShaderModule object in a capture'). It clearly identifies what the tool does and is distinguishable from sibling tools like get_object or decode_vertex_buffer.

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 should be used when the agent needs WGSL source for a ShaderModule, but it does not explicitly state when not to use it or mention alternatives such as get_object. The usage context is clear enough, though no exclusions or comparisons are provided.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool returns validation errors but does not specify whether the operation is read-only, what happens if no errors exist, whether the data persists, or any side effects. For a simple getter, the lack of behavioral detail leaves ambiguity.

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, direct sentence that immediately conveys the tool's purpose. It is front-loaded and contains no extraneous words, making it highly efficient for an agent to parse.

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 this is a simple getter with one optional parameter and no output schema, the minimal description is barely adequate. However, it omits contextual clues such as when to use it (e.g., after a capture with errors) or any relationship to other capture-related tools. A bit more context would improve an agent's ability to decide to call it.

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 provides 100% description coverage for the single parameter (captureId). The tool description adds no additional meaning about the parameter, so it does not enhance what the schema already offers. With high schema coverage, the 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?

The description precisely states a specific verb ('Return'), a specific resource ('WebGPU validation errors'), and the context ('recorded during a capture'). This clearly distinguishes it from sibling tools like get_capture_summary or analyze_performance, which cover other aspects of a 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 provides no guidance on when to use this tool instead of alternatives. There is no mention of prerequisites (e.g., a capture must exist), nor any pointer to sibling tools for related functionality. The intended use case must be inferred from the name and one-line description, but no explicit or implicit selection 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?

With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that every opened page is instrumented, that no extension or page changes are needed, and that a first tab can optionally be navigated. It does not mention lifecycle details such as whether the launch is blocking or what happens on failure, but the core behavioral trait is clearly communicated.

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 primary action and critical instrumentation guarantee are front-loaded, and the optional URL behavior is summarized efficiently. Every clause 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?

For a launch tool with three optional parameters and no nested objects or enums, the description covers the essential purpose, the instrumentation behavior, and the optional navigation. It is slightly incomplete because it doesn't mention the return value or the relationship to attach_browser, but the agent can still invoke it correctly based on the provided information.

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%, so the baseline is 3. The description adds minimal meaning beyond the schema: it repeats the optional URL navigation and mentions auto-detection implicitly through 'controlled by this plugin,' but it does not provide additional context for headless or executablePath beyond what the schema already states.

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 specifies the action ('Launch a new Chrome/Edge instance'), the target resource, and the key differentiator: automatic WebGPU instrumentation with no extension or page changes. This distinguishes it from attach_browser, which presumably connects to an existing browser, without needing to open either schema.

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 conveys when to use this tool: when a new Chrome/Edge instance is needed and instrumentation is required. It implies this should be used instead of manually launching a browser or using attach_browser for a pre-existing instance. However, it does not explicitly name the alternative or state 'use attach_browser if the browser is already running.'

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 annotations, the description carries the behavioral burden. It discloses an important inclusion/exclusion behavior: only live captures and explicitly loaded capture files are listed, not arbitrary capture files. This is meaningful and goes beyond the tool name, though it doesn't mention output format or side effects, which are unlikely for a listing 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?

The description is a single, focused sentence. The parenthetical clarification is compact and adds necessary scope information 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 tool is simple and parameterless, so invocation is trivial, but there is no output schema and no mention of what fields or format the returned capture list will have. The description is sufficient for selection but not fully complete for an agent that needs to consume the result in a downstream step.

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 there is nothing for the description to clarify beyond the baseline. The description does not add parameter information, but none is needed.

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 and resource: 'List captures currently available to analyze' and clarifies the two inclusion categories: live captures and explicitly loaded capture files. This distinguishes it from siblings like load_capture_file and get_capture_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 phrase 'currently available to analyze' implies this is the tool to call when you need an inventory of loaded or captured data, but it does not explicitly state when to use this tool versus alternatives such as load_capture_file or get_capture_summary. No when-not or alternative-naming guidance is provided.

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 annotations, the description carries the behavioral disclosure burden. It explains what 'connected' means and how a page becomes eligible, which is meaningful behavioral context. It does not describe exact return shape or ordering, but this is a simple read-only listing 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?

The description is two sentences long. The first sentence states the core purpose directly, and the second adds essential lifecycle context. No filler or redundant wording exists.

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 simple no-parameter listing tool with no output schema, the description provides enough information for an agent to invoke it correctly and interpret what will be returned. It explains when pages connect, which is the main operational nuance. A return-value hint would be marginally useful but is not essential here.

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 and the schema confirms this. Per the zero-parameter baseline, the description does not need to add parameter information, and the score is set to 4.

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 states a specific verb-resource pair: 'List browser pages currently connected to the live bridge.' This clearly distinguishes it from sibling tools that list captures or manage files, and it immediately communicates what operation is performed.

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 pages appear in the list by explaining the connection lifecycle (after instrumentation or self-initialization). It does not explicitly name alternatives or exclusions, but for a zero-parameter listing tool this is sufficient 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?

With no annotations, the description must carry behavioral disclosure. It states the operation is loading a file for analysis, which is a non-destructive read, but it does not explicitly mention that it is read-only, any permission requirements, behavior on missing/invalid files, or side effects. The core behavior is transparent but lacks depth.

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 with the verb and resource front-loaded, and it includes relevant format details. 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?

The description is minimal and does not specify what happens after loading, such as whether it returns a capture handle or makes the capture the active one. Given no output schema, this missing workflow detail leaves an agent uncertain about how to reference the loaded capture with subsequent analysis tools. It is adequate for the core action but not fully complete for the workflow.

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 100% as the path parameter is described in the schema. The description adds context about how the file was created (saveCaptureData() or DevTools) and its purpose, which enriches the schema's basic description. It does not contradict or duplicate unnecessarily.

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 states a specific verb ('Load') with a clear resource ('WebGPU Inspector capture file') and provides formats and origin. It clearly implies use for analysis, and the scope distinguishes it from sibling tools like capture_frames (which creates captures) and list_captures (which lists existing ones).

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 no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used when you have a capture file on disk, nor does it contrast with tools like list_captures or capture_frames. The context is implied but not 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?

No annotations are provided, so the description carries the full burden. It discloses key behavior beyond the mere action: it waits for bridge connection and returns a page ready for capture. This gives the agent useful operational expectations, though it doesn't mention timeout behavior or what happens if the browser isn't available.

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, directly front-loaded with the action, and every clause adds value: what it opens, where it navigates, and what it waits for. 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 no output schema, the description provides essential context: it creates an instrumented tab, waits for connectivity, and returns a ready-to-capture page. It could be slightly more complete by stating a prerequisite (e.g., 'requires a controlled browser already launched'), but the current text is sufficient for most correct usage.

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 fully describes the only parameter with 'URL to open.' The description adds contextual phrasing ('navigate it to a URL') but no additional semantic detail, format requirements, or edge-case guidance. With 100% schema coverage, the 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?

The description uses a specific verb and resource: 'Open a new instrumented tab in the controlled browser and navigate it to a URL.' It also adds the outcome ('returns it ready to capture'), which distinguishes it from sibling tools like list_pages or screenshot_page. The scope and intent are immediately clear.

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: after a controlled browser exists, to create a fresh page for subsequent capture. It clearly sets context by saying 'in the controlled browser' and 'ready to capture.' It doesn't explicitly name alternatives or state when not to use it, so it falls short of a full 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the internal mechanism (copy to readback buffer, map, decode) and discloses a critical constraint (COPY_SRC usage requirement), which is essential for the agent to understand potential failures. This is transparent and detailed.

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 no filler. The first sentence states purpose and contrast, the second explains mechanism and constraint. It is front-loaded with the most relevant 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?

The tool has 5 parameters and no output schema, so the description needs to provide sufficient context. It covers the purpose, mechanism, and a key prerequisite, and mentions that the buffer is live and on a connected page. However, it does not describe anticipated failure modes (e.g., buffer without COPY_SRC) or the exact structure of the returned data, which would be helpful but not strictly necessary given the 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 schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema; it does not elaborate on 'size', 'offset', or 'type' beyond what the schema already states, but it does clarify the overall decoding behavior. Thus it meets the baseline without exceeding 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 clearly identifies the verb 'Read' and the resource 'current contents of a live GPU buffer', and distinguishes it from a full capture by stating 'without taking a full capture'. It also specifies the context of 'on a connected page'. This is a clear, specific purpose that differentiates it from sibling tools like read_texture and decode_vertex_buffer.

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 states when to use this tool (to read a live buffer) and when not to (instead of a full capture), and provides a prerequisite ('buffer must have been created with COPY_SRC usage'). It implicitly contrasts with capture tools and gives context for the connected page requirement, offering clear usage guidance without ambiguity.

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 annotations, the description carries the full burden of behavioral disclosure, and it delivers: it reveals the internal copy-to-readback-buffer operation, per-format decoding, the COPY_SRC prerequisite that the inspector adds only while a capture is armed, the TextureView-to-texture resolution behavior, and the pooling pitfall. This far exceeds what a bare schema would communicate.

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 core purpose is front-loaded ('Read a region of a live GPU texture'), followed by return-value semantics, then parameter guidance, then caveats in order of importance. Although it is a dense paragraph, every sentence earns its place — trimming any would lose critical information about prerequisites, pitfalls, or alternatives given the tool's GPU-readback 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?

This is a high-complexity tool (8 parameters, TextureView resolution, COPY_SRC prerequisites, pooling hazards) with no annotations and no output schema, so the description must compensate — and it does. It explains the return shape (stats, hole fraction, ASCII view, no raw pixels), the failure mode (pool recycling), and the escape hatch (screenshot_page), leaving nothing an agent needs to invoke 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 100%, so the baseline is 3. The description adds genuine meaning beyond the schema: it explains what a TextureView is (a render pass attachment), why passing one works without a get_object round-trip, and the COPY_SRC precondition on the textureId target. The region-oriented parameters (x/y/width/height, layer, mipLevel) are already fully documented in the schema, so no more is needed.

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 opens with a specific verb and resource — 'Read a region of a live GPU texture / render target' — and narrows scope with 'a connected page' and 'without taking a full capture'. It also enumerates exactly what is returned (per-channel min/max/mean, hole fraction, ASCII luminance view, 'never raw pixels'), which differentiates it sharply from siblings like screenshot_page, read_buffer, and get_object.

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 explicit when-to-use and when-not-to-use guidance: it names screenshot_page as the alternative 'to see the final image', warns that pooled render targets may have been recycled and are unreliable, and explains that a TextureView is resolved automatically so 'no get_object round-trip is needed'. This routes an agent to the correct tool without opening any schemas.

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 annotations provided, the description carries the full behavioral burden. It discloses that the tool reads the composited surface, explains why this is reliable (independent of pooling/aliasing), warns against reading pooled targets, and notes the dependency on an already-open page. This gives the agent a clear mental model of the operation's behavior and its edge cases.

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?

Every sentence earns its place: purpose, technical nuance, prerequisite, and usage guidance are packed into four sentences with no filler. The key differentiator (composited vs. pooled) is front-loaded, and the alternative tool names are given inline, making it highly scannable and efficient.

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 of moderate complexity (WebGPU rendering inspection) with no output schema, the description covers everything an agent needs: what it returns (PNG image), why it is the reliable method, when to use it, what it does not do, and the required precondition. There is no critical missing information for correct invocation.

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 descriptions for all three parameters (pageId, fullPage, selector), giving 100% coverage. The description adds no additional parameter-level detail, so it meets the baseline of 3 but does not exceed it; the agent must rely solely on the schema for parameter meaning.

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 opens with a specific verb-resource pair ('Capture a PNG screenshot of an instrumented page') and clarifies the output ('return it as an image'). It further distinguishes the tool from siblings by explaining it reads the composited page rather than intermediate buffers, naming read_texture and capture_frames explicitly, so an agent can separate it from similar functions without ambiguity.

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 states the exact when-to-use ('visually verify a rendering change') and when-not-to-use ('not to inspect intermediate G-buffer contents'), points to alternatives ('use read_texture / capture_frames'), and includes a hard prerequisite ('Requires a page opened via launch_browser/open_page'). This leaves no inference for the agent on how to select the tool.

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