Reconstruct

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

Annotations already declare non-readOnly, non-idempotent, non-destructive, so the mutation profile is known; the description adds real context beyond that — it is asynchronous (pending, not immediate) and gated by subscription, URL safety and duplicate checks. The duplicate-check note is valuable against idempotentHint=false. It stops short of naming the follow-up tool (wait_product_request) or the returned request identifier, leaving a small gap.

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?

Roughly six short sentences, front-loaded with the core action, then mode requirements, prerequisite tool, and guardrail. Every sentence carries either a constraint or a routing rule; nothing is redundant with the title 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?

For an 8-parameter, non-idempotent mutation with an output schema and annotations, the description covers mode conditionals, prerequisites, asynchronous semantics and validation gates. The only material omission is what the agent should do after submission (polling via wait_product_request or get_product_request), which the "pending request" phrasing only implies.

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, but the description adds cross-parameter constraints the schema documents only per-field: add needs a public HTTPS url plus an empty product, update needs an existing published product key with the source URL derived by the backend, and subject is optional. It also flags that payloadJson is backend-validated rather than free-form.

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?

States a specific verb and resource ("Submit a product capture request") and immediately splits the two modes (add vs update) with their distinct inputs. An agent can distinguish this from read-side siblings like get_product_request or list_product_requests without opening the 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?

Explicit conditional routing: "Call only when the user asks to submit a request; do not automatically submit while browsing missing captures" gives a clear when-not rule, and "Select platform/environment from get_request_options" names the prerequisite sibling. It also declares "Creates a pending request, not an immediate capture," which sets expectations against synchronous tools.

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=false, so the safety profile is covered. The description adds the useful behavioral detail that only *visible* elements are matched and names the returned data (layout, rectangles, computed styles), but says nothing about result ordering, pagination/truncation behavior, or what happens when nothing matches.

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 with no filler: verb, searchable facets, and return payload packed in order of importance. Nothing could be removed without losing 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?

An output schema exists so return values need not be explained, and the schema plus annotations cover parameter and safety detail. The main residual gap is the absence of any guidance on the search-versus-direct-fetch choice within this 60+ tool family, and no mention of result caps or pagination beyond the schema's limit field.

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 every parameter including the required non-empty, case-insensitive query and the limit clamp is already documented in the schema. The description contributes only the 'visible elements' scoping nuance on top of that, so the baseline of 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 states a precise verb (Find) plus resource (visible elements) and enumerates the searchable facets — text, content, label, href, action, CSS path, tag — and the payload returned (layout, effects, rectangles, computed styles). It is clear what the tool does, though it never distinguishes itself from the very close sibling get_elements, so an agent must infer that find_ is query-driven lookup while get_ is direct retrieval.

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 is only implied: the list of searchable facets suggests 'use this when you have text/label/href to match.' There is no explicit when-to-use condition, no when-not, and no routing to alternatives such as get_elements or list_component_candidates, which are plausible competing choices in this large sibling set.

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 covered structurally. The description adds useful content scope (availability plus stage names) but says nothing about version-pinning discipline, completeness guarantees, or any cross-call consistency requirement.

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 that names the resource, its scope and the notable fields with zero 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?

An output schema and full annotation coverage exist, so the description need not explain returns or safety. What it provides is sufficient for a read-only manifest fetch, though it omits any hint about when this manifest should be preferred over the closely named 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 100%, and the schema itself carries rich semantics, including the explicit 'do not use latest as an alias' warning and the environment-omission rule. The description adds no parameter meaning beyond the schema, 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?

States a specific verb ('Return') and resource ('complete route inventory for a captured application version') plus scope detail (desktop/mobile availability, stage names). It is clear on its own, but it never distinguishes itself from semantically adjacent siblings like get_route_tree, get_replay_manifest, or get_scenario_manifest.

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 when-to-use guidance, prerequisites, or alternatives are given despite the presence of several manifest/route siblings. The agent must infer context entirely from the name.

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 readOnlyHint/idempotentHint/destructiveHint already declared, the description still adds genuinely useful context: the return shape (path, URI, hash, MIME, size) and the key behavior that bytes are not embedded and page JSON is excluded. This goes beyond the safety profile the annotations carry.

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?

Three tight sentences, front-loaded with the core action and return summary, then discovery routing and an exclusion. 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?

Output schema exists so return values needn't be explained (though the description usefully previews them), and annotations cover the safety profile. The description adds the exclusion and discovery pointers, making it largely complete, with only minor gaps around pagination/size limits.

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 schema already documents all five parameters, including path constraints and the environment default. The description only echoes 'by relative path,' adding little beyond the schema, 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?

States a specific verb (materialize) and resource types (archived resource, screenshot/MP4/WebM) retrieved by relative path. It names discovery siblings (list_archived_assets, get_fonts, get_page_artifacts), which aids differentiation, though it does not clearly separate itself from other retrieval siblings like get_page_image or get_element_asset.

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?

Gives workflow guidance by pointing to the discovery tools that produce the path (list_archived_assets/get_fonts for resources, get_page_artifacts for recordings) and notes page JSON is excluded. No explicit when-not or limits on the other asset-getter siblings, so it stops short of full alternative 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/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: only allowlisted WebP files are readable, paths must be relative and present in storage. It stops short of describing what happens on a missing or non-allowlisted path (error 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?

Two tight sentences, front-loaded with the core action and scope, followed by the readability constraint. No filler, no repetition of the title or schema fields.

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?

An output schema exists, so return-value details need not be explained. Combined with 100% parameter coverage and annotated safety hints, the description supplies everything required to invoke correctly: what is read, in what format, and the allowlisting constraint.

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 all five parameters with detail (path format, product key, pinned version, platform/environment IDs). The description adds only concrete example paths, which is marginal value over the schema, 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 gives a specific verb and resource ('Read one allowlisted WebP from a product version by relative path') and even supplies example paths, so the agent knows exactly what it retrieves. However, it does not differentiate this tool from the many sibling image retrievers (get_capture_asset, get_page_image, get_stage_image, get_component_image), leaving the agent to infer which image source applies.

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 is implied rather than stated: the agent should call this when it holds a relative .webp path from an inventory tool. The phrase 'Only .webp paths present in storage are readable' establishes a boundary condition, but there is no explicit when-to-use/when-not guidance or named alternative among the image siblings.

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 without the description. The description adds the concrete artifact naming (before.webp/after.webp) and that the source is a CLI click capture, but nothing about availability, error behavior, or fallbacks. The schema carries the 'must exist' precondition. A 3 is appropriate.

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 short sentences, zero waste, purpose front-loaded ahead of the parameter hint. Nothing is padded.

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?

An output schema exists, so return-value detail is not owed, and annotations plus a fully covered schema handle the rest. The remaining gap is that similar image-retrieval siblings are not disambiguated, which matters for this tool family.

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 the schema documents kind, product, platform, version, and environment thoroughly, including how to source IDs from list_platforms and list_versions. The description's 'Pass kind=before or kind=after' merely repeats the schema, 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?

States a specific verb (Return) and resource (before.webp/after.webp screenshot from a CLI click capture), which scopes it well. However, the sibling list contains many near-identical image getters (get_capture_image, get_replay_step_image, get_page_image), and the description never distinguishes itself from them.

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 only routing information is 'Pass kind=before or kind=after,' which is an invocation instruction, not usage guidance. There is no statement of when to choose this over get_capture_image or the other *_image siblings.

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=false, so the safety profile is covered. The description adds genuine behavior beyond that: the two-tier resolution strategy (id/parent tree preferred, rectangle containment fallback) and the fact that a crop rectangle for the page image is included in the result.

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?

Three short sentences, zero filler, and the core behavior (what is returned) is front-loaded before the resolution and crop-rectangle 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 an output schema present, return-value explanation is unnecessary, and the rich schema covers parameter semantics. The description supplies resolution behavior and crop-rectangle output, leaving only the sibling-selection routing 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 baseline is 3; every parameter (page, view, version, elementId, environment) is already documented in the schema with usage warnings. The description adds nothing about parameter syntax or constraints beyond that.

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?

States a specific verb+resource (return one component candidate and its descendants) and adds scope detail about the fallback resolution. It does not name or contrast with close siblings like get_component_tree, get_page_components, or list_component_candidates, so an agent can't distinguish them from the description alone.

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 when-to-use or when-not-to-use guidance. The 'prefers the id/parent tree; falls back to rectangle containment' line describes internal resolution behavior, not the conditions under which an agent should pick this tool over the many sibling component/element retrieval tools.

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 cover the safety profile (readOnly, idempotent, non-destructive), but the description adds a genuinely useful behavioral fact not present in annotations or schema: idle animation declarations are excluded from results. It also flags pagination and optional y-range scoping, though those are largely mirrored in the schema.

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 the core action front-loaded and the exclusion clause last. Nothing is padded, though the second sentence packs three distinct facts (pagination, y-range, idle exclusion) into one clause chain.

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 an output schema present the description need not explain return values, and the input schema fully documents the ten parameters. It is complete for calling the tool correctly; only the absence of sibling routing keeps it from being fully self-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 description coverage is 100%, so all ten parameters are already documented, including the non-obvious page/view/version/environment semantics. The description's 'paginated and optionally limited to a y range' only loosely gestures at limit/offset/yStart/yEnd and adds no new meaning, 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?

States a specific verb ('Read'), a specific resource ('captured motion and active CSS animation'), and scopes it to one component ID, which separates it from the page-level get_page_motion sibling. It stops short of naming that sibling or explicitly contrasting the two.

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?

Implies usage through 'for one component ID' and the y-range/pagination qualifiers, but never states when to choose this over get_page_motion, get_component_styles, or get_component_assets, nor any prerequisites beyond what the schema already encodes.

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, non-destructive, so the safety profile is covered. The description still adds real value by disclosing that the default response is a URI/path rather than bytes and must be resolved through get_element_asset, a trait present in neither schema nor 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 tight sentences with the primary purpose front-loaded, followed by scoping and the byte-resolution pointer. No filler and nothing redundant.

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?

An output schema exists, so return values need no explanation, and the description covers purpose, scoping, pagination and byte resolution for a 10-parameter tool. A brief note on whether results include geometry alongside media would make it fully 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 100%, so all ten parameters are already documented in the schema. The description only restates pagination and y-range scoping in passing and adds no syntax or format detail beyond that, 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: 'Read media references and geometry for one component ID.' That clearly distinguishes it from byte-fetching siblings like get_component_image, though it does not explicitly contrast itself with the other get_component_* readers.

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 states the paginated/y-range scoping and routes the agent to get_element_asset to resolve actual bytes, which is genuine when-to-use guidance. It stops short of naming when not to use this tool or listing sibling 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that the image is a crop of the visible rectangle from the saved screenshot, but it says nothing about resolution, viewport/DPR handling, or what happens when the element is clipped or off-screen.

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?

One sentence, front-loaded with the output artifact (WebP crop) and then the source (saved page screenshot). No filler, no restatement of the title.

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 an output schema present, the description need not explain the return payload, and the schema fully documents the six inputs. It is complete enough to call confidently, with the only real gap being how the returned crop relates to the requested element's bounds (padding, clipping, scale).

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 all six parameters (including the optional environment with its default) are fully documented in the schema, setting the baseline at 3. The description adds no parameter-level meaning, such as how page/view/version must be pinned together or that elementId is zero-based.

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?

States a specific verb and resource: returns a WebP cropped to one component candidate's visible rectangle, sourced from the saved page screenshot. That is meaningfully distinct from data-returning siblings like get_component or get_component_styles, though it never explicitly names how it differs from the adjacent image tools (get_page_image, get_element_asset, get_component_assets).

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?

There is no explicit when-to-use statement and no named alternative. An agent must infer from the phrase 'component candidate' that this follows list_component_candidates or find_elements and that sibling image tools cover other crops. No prerequisites or exclusions 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 this a read-only, idempotent, non-destructive operation, so safety is covered. The description adds genuine behavioral context beyond that: pagination, optional y-range restriction, the fact that expanded changes the return shape to individual elements/rectangles, and what data is deliberately omitted. It stops short of mentioning auth, defaults, or rate limits.

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?

Three short sentences, front-loaded with purpose, then scope modifiers, then the highest-value flag. No filler or repetition, and the exclusion clause is placed where it does the most differentiating work.

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 100% schema coverage and an output schema present, the description does not need to enumerate returns or parameters. It covers scope, exclusions, pagination, and the granularity toggle, which is sufficient for an 11-parameter read tool; only prerequisite guidance (which upstream calls supply componentId/page/view/version) is left entirely to 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?

Schema description coverage is 100%, so the schema already documents all 11 parameters including expanded, yStart/yEnd, limit, and offset. The description largely restates these; its only marginal additions are clarifying that expanded yields 'individual elements and rectangles' and naming the excluded content categories. Baseline 3 applies when the schema carries the detail.

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?

States a specific verb and resource ('Read grouped layout and paint styles for one component ID') and then draws the boundary explicitly by excluding text, animation, and media source bytes, which is exactly what siblings like get_component_text and get_component_animations cover. An agent can route correctly without opening the 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 implies usage via the expanded flag ('Set expanded=true for individual elements and rectangles'), giving a granularity choice, but it never states when to call this versus the sibling style/text/animation tools or what prerequisite calls must precede it. Usage is inferable from scope, not stated.

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=false, so safety is covered structurally. The description still adds real behavioral value: it discloses pagination, an optional y-range restriction, and a scope boundary ('no CSS or asset payloads'), which tells the agent what this call will not return. It does not mention rate limits or auth requirements, so it stops short of a 5.

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?

Three dense sentences: what is returned, when to use it instead of the bundle, and the operational constraints. Front-loaded with the core deliverable and free of 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?

An output schema exists, so return-value explanation is not required, and the description covers routing, pagination and scope. Prerequisite pinning (version/page/view consistency) is handled entirely by schema descriptions, leaving little the agent still needs to infer, though a note on truncation behaviour at the limit cap would round it out.

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 page, view, version, componentId, yStart/yEnd, limit and offset are all already documented in the schema. The description only alludes to pagination and the y range without adding syntax or defaults beyond what the schema 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?

States a specific verb and resource ('visible own text, line breaks, IDs, parents, and rectangles for one component ID') and names the exact scope of what comes back. It also distinguishes itself from the sibling get_section_bundle, so an agent can choose between them without opening 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?

Explicit routing: 'Prefer get_section_bundle text/texts first; call this when the bundle marks textTruncated or you need uncapped runs/lines.' This gives both the preferred alternative and the precise triggering condition, which is exactly what usage guidance should do.

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/destructiveHint, so safety is covered. The description adds real behavioral value by characterizing the response as a 'compact parent/child skeleton' and enumerating what is deliberately omitted, letting an agent predict payload weight versus the heavier asset/style siblings.

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 sentence that front-loads the action and resource, then qualifies scope with the exclusion list. No filler, no repetition of schema facts.

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 a rich schema (9 params, 5 required, 100% coverage), an output schema, and full annotations, the description covers what an agent needs to invoke it correctly. Only a brief note on pagination or result shape would improve it, and the output schema already handles returns.

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 the schema documents defaults, clamps (0..4, 1..50), and pagination semantics in detail. The description only echoes 'element ID and depth', adding no syntax or constraint beyond the schema, so the baseline of 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?

States a specific verb (Read) and resource (component's parent/child skeleton) and immediately scopes the payload by element ID and depth. The exclusion clause (no text, CSS, animation, asset data) separates it cleanly from siblings like get_component_text, get_component_styles, and get_component_assets without opening any 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 'without text, CSS, animation, or asset data' exclusion gives clear context that routes the agent toward the specialized sibling tools when those payloads are needed. However, it never explicitly names an alternative or states a when-not condition, so the routing is implied rather than spelled out.

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=false, so the safety profile is covered. The description adds behavioral context beyond that: pagination, optional y-range limiting, and the grouped/count/sample-ID nature of the result.

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 zero filler, front-loading what the tool reads before noting pagination/range behavior and the sibling alternative.

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?

An output schema exists, so return-value explanation is not required, and annotations cover safety. The description is nearly complete for a read tool; the only gap is that it does not differentiate from the other component-level get_component_* siblings.

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 all ten parameters including defaults, clamps and coordinate semantics. The description mentions component ID, pagination and y-range only in passing, adding no syntax or format detail beyond the schema. 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?

States a specific verb and resource ('Read grouped text font styles for one component ID') plus the return shape (counts and sample element IDs). It names get_fonts as the tool for family names/URLs, routing away from one sibling, but it does not distinguish itself from the closely-named get_component_styles or get_component_text.

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?

Gives clear usage context (paginated, optionally bounded by a y range) and points to get_fonts when family names or origin URLs are needed. No explicit when-not conditions or prerequisites are stated, but the routing to the alternative is helpful.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond the annotations: the default return shape (path/URI, hash, MIME, byte size) and the fact that oversized assets stay as references even when includeContent=true.

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 compact sentences, front-loaded with the core action and default return shape before the optional includeContent detail. No filler, and each sentence carries distinct 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?

With an output schema present, the description needn't detail returns, yet it summarizes them usefully, and it covers the one non-obvious parameter (includeContent). Complete enough to call the tool correctly; only sibling disambiguation is thin.

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 baseline is 3 and the schema does the heavy lifting. The description still adds value by explaining includeContent's raw-byte-limit and oversized-fallback semantics, which the schema only states more tersely.

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?

States a specific verb ('Resolve') and resource ('one captured element asset'), with a clear single-item scope. It does not, however, name or differentiate itself from close siblings like get_capture_asset or get_component_assets, so an agent must infer the 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?

Gives one useful directive: 'Download or copy it outside model context,' and conditions includeContent=true on wanting inline bytes. But there is no explicit when-to-use-this-vs-sibling guidance among the many asset/get_* tools, leaving routing to inference.

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=false, and the limit/offset clamping is documented in the schema's own parameter descriptions. The remaining behavioral claim, 'small paginated slice', is vague and adds little beyond what the structured fields already convey.

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?

One front-loaded sentence that wastes no words, leading with the action and scope before the payload list. It is appropriately short, though the trailing field enumeration reads like a comma dump rather than prioritized 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?

An output schema exists, so return values need not be re-explained, and the schema carries all parameter guidance. What is missing is routing context against the many sibling get_* tools; for a seven-parameter retrieval tool this leaves a real 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 all seven parameters (including the required page/view/product/version keys) are already documented in the schema. The description adds no syntax, format, or constraint detail beyond that 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?

States a specific verb (read) and resource (captured elements) plus the scope (small paginated slice), and enumerates the fields carried in the payload. However, it never names the obvious sibling find_elements, so the agent cannot tell from the description alone why it would read elements rather than search them.

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?

There is no when-to-use or when-not-to-use guidance in the description. Nothing points to find_elements as the alternative for querying elements or to the list_pages/list_versions prerequisites, which live only in the schema property descriptions.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds valuable behavioral context: original bytes are stored in the capture and must be read via resources[].path with get_capture_asset – a non-obvious workflow detail 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?

Three tight sentences, front-loaded with the core action and return value, followed by the essential follow-up step. No wasted text.

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 annotations covering safety, a full output schema, and 100% parameter coverage, the description supplies the key missing piece – how to fetch actual bytes via get_capture_asset. Complete enough 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 coverage is 100% and the path parameter is fully documented, including that it accepts a family name, original URL, or archive path. The description reinforces the family-name/URL resolution but adds little beyond the schema, so 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?

States a specific verb (resolve) and resource (one font) and explicitly names its scope source, get_fonts, distinguishing singular lookup from the sibling listing tool. The return contents (family plus origin download URLs) are named, so an agent knows what it gets.

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?

Clearly routes the agent: use this to resolve a single font from get_fonts, and use get_capture_asset to read the original bytes. It lacks an explicit 'when-not' beyond that handoff, but the context is clear.

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 establish readOnly, idempotent, non-destructive behavior. The description adds useful behavioral context by noting that origin URLs are metadata and can become unavailable, and by directing agents to get_capture_asset for stored bytes.

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?

Three tight sentences front-load the main purpose, then explain the two key flags, then add the critical alternative. Every sentence contributes useful information without 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?

Given a rich input schema, an output schema, and annotations covering safety, the description supplies the important caveat about origin availability and the recommended alternative for stored bytes. It is nearly complete, though it could mention its relationship to the singular get_font 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 100%, so the schema already carries full parameter semantics. The description adds modest clarification about includeUrls returning origin webfont URLs and archived resource paths and includeFaces including face ranges, but most meaning is already in 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?

States a specific verb and resource: listing font families and weights. It also distinguishes the stored-bytes use case from metadata by pointing to get_capture_asset. However, it does not explicitly differentiate itself from the singular get_font sibling.

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?

Gives clear guidance on how to use includeUrls and includeFaces and explicitly recommends get_capture_asset(resources[].path) for stored bytes. It lacks explicit when-to-use guidance versus get_font or component typography tools, but the key alternative is 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?

Beyond the readOnly/idempotent annotations, the description discloses substantive behavior: older Web captures are converted with explicit gaps, measured bounds are not fixed sizing, and declared actions do not imply successful interactions. These are real interpretive caveats not derivable from structured fields. It stops short of describing output shape, but an output schema exists.

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?

Front-loads what is exported, then moves to consumption rules and caveats. The opening content list is dense but each clause names a distinct artifact section. A sentence or two of the interpretive guidance could be tightened without loss.

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 read-only export with a full output schema and rich parameter docs, the definition covers the missing pieces an agent needs: per-view calling, conversion gaps, evidence limitations, and the no-inference rules. Return-value detail is rightly deferred to the 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 coverage is 100% and each parameter already documents its source (list_pages, list_versions, list_platforms) and disallowed values (no URLs, no OS names, no 'latest' alias). The description reinforces per-view and version-pinning intent but adds no new syntax or format details beyond the schema, 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?

Opens with a specific verb ('Export') and resource ('platform-neutral reconstruct.scene.v1 interface') and enumerates exactly what the artifact contains (profiles, frames, node hierarchy, layout constraints, transitions, motion). An agent can distinguish this composite scene export from narrower siblings like get_page_artifacts, get_page_stack, or get_scenario_scene.

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?

Gives concrete usage conditions ('Consume the JSON programmatically', 'Request each saved view separately', 'Native captures require a published scene; do not invent them') and exclusions about interpreting results. It does not explicitly name which sibling to prefer when a caller wants only components or styles, so routing to alternatives is left implicit.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds meaningful context beyond them: the data is read from languages.json and there is a path-prefix fallback, which tells the agent results may be derived rather than absolute. No fallback failure semantics are described, hence not a 5.

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?

One sentence, front-loaded with the outcome ('Return languages detected'), with the provenance detail tucked into a compact parenthetical. No filler and nothing redundant with the 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?

For a simple read tool with full annotation coverage, a complete schema, and an output schema, the description need not explain return values or pagination. It covers purpose and data origin, though a brief note on what an empty result versus fallback-derived result means would make it fully self-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 description coverage is 100%, so the schema already documents product, version, platform, and environment in detail, including cross-references to list_versions and list_platforms. The description adds no extra meaning about parameter format or constraints, making the baseline 3 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?

States a specific verb and resource plus its scoping dimensions: languages detected for a product version on a platform. An agent knows exactly what comes back. It does not differentiate itself from siblings (nor does it need to, since no other language tool exists), so it falls short of a 5.

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 when-to-use, when-not-to-use, or alternative is named. The statement of required inputs implies context but gives no criterion for choosing this tool over, say, get_version_metadata or get_technology_stack, which plausibly overlap in locale/stack discovery.

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 non-destructive, so the safety profile is covered. The description adds real context beyond that: relative (not absolute) paths, MIME types, capture-limit metadata, and the notable guarantee that absent recordings are not fabricated — a behavioral claim the annotations do not carry.

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?

Three tight sentences: contents first, then return shape, then the retrieval handoff and the no-fabrication caveat. Every clause earns its place and the most important information is front-loaded.

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?

An output schema exists to describe return values and annotations cover the safety profile, so the description need not carry those burdens. It supplies purpose, scope, artifact classes, return shape, downstream routing and a behavioral caveat — everything an agent needs to select and call 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% and the schema already documents page, view, version and environment with strong semantics (exact keys, no URL/path, no 'latest' alias). The description only echoes the 'one page/view' scoping, adding nothing the schema does not already say, 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?

States a specific verb (list) and resource (stored media for one page/view) and enumerates the artifact classes it covers: viewport/full-page screenshots, section tiles, scroll and interaction recordings. This distinguishes it clearly from single-asset siblings like get_page_image or get_capture_image and from bundle-style siblings.

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 routes the agent explicitly to the follow-up step ("Retrieve a chosen file with get_capture_asset"), which is useful workflow guidance. It stops short of naming when NOT to use this tool vs alternatives like get_page_bundles or list_version_files, so it is clear context without 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/idempotentHint/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the 8-selection ceiling, the textMode=preview default, and the textTruncated follow-up rule inherited from get_section_bundle, which tells the agent results may be clipped and need a follow-up.

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 tight sentences, front-loaded with the batching purpose before the parameter mechanics. 'Batch IR' is unexplained jargon and the final sentence defers to another tool's rules, but there is no padding.

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?

An output schema exists and the schema documents all nine parameters, so the description does not need to explain return values. It covers the key call-shaping facts (batching, selection cap, region preference, text mode) and lacks only an explicit contrast with single-bundle 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% and the parameters are individually well documented, so the baseline is 3. The description restates the sectionIds/regionIndexes semantics and the 'at most 8' limit, which the schema already documents, and adds the outline-vs-nested-leaves preference as the only genuinely new selection guidance.

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 first clause names the verb, the resource, and the mechanism ('Batch IR: multiple get_section_bundle results in one RPC'), which immediately separates it from the sibling get_section_bundle. An agent knows this is the batched variant without opening the 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?

It tells the caller what to pass (sectionIds and/or regionIndexes), the cap (max 8 total), and a selection preference ('prefer outline regions (bundleTarget=true), not nested leaves'). It never explicitly states when to choose this over repeated get_section_bundle calls, but the batching framing makes that condition obvious.

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/destructiveHint=false, so the safety profile is covered. The description adds real but modest context: this is an 'exact follow-up' query and over-calling across y bands produces 'exploratory spam.' It does not address auth, rate limits, or response characteristics, so it is adequate rather than 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?

Two sentences, front-loaded with the core action followed by the routing guidance; no filler. The parenthetical '(exact follow-up)' is slightly cryptic and could be clearer, which keeps it from a 5.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. For a 9-param, region-bounded listing tool the description supplies enough routing and scope context to call it correctly, though it omits page/view/version pairing nuance that the schema carries.

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 all 9 parameters (yStart/yEnd, limit, offset, page, view, product, version, environment) in detail. The description only gestures at the 'bounded y region' that yStart/yEnd encode, adding no syntax or 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?

Specific verb ('List') plus resource ('visual component candidates') and a scoping constraint ('in a bounded y region'), and it names two sibling tools (get_page_outline, get_page_bundles) as the preferred route. It is clear what the tool does, though it does not distinguish itself from the similarly named sibling list_component_candidates, keeping it just below a 5.

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?

Explicitly says to 'Prefer get_page_outline → one bundle per outline region (or get_page_bundles)' and gives the rationale ('to avoid exploratory spam across many y bands or micro-sections'). This is clear when-to-use and alternative-naming guidance; it lacks an explicit when-not/precondition statement, so not 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: it returns exactly one file, explains the parent/anchorPath relationship for reveal nodes, and describes the shape of each file variant. It stops short of stating error behavior when a file is missing.

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 that states the action first, then qualifies the three return variants. It is dense with parenthetical detail, but every clause carries information; slightly heavy for one sentence.

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 an output schema present the description need not explain return values, yet it usefully characterizes the JSON shapes. Combined with six well-documented parameters it is nearly complete for an agent to call correctly; only explicit sibling routing guidance 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 description coverage is 100% and the schemas already tell the agent that page/view/version/product are keys from list_pages, list_versions, etc. The description reinforces the file-type taxonomy (reveal/frame/viewport) but adds little syntax or format meaning the schema does not already carry, 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?

States a specific verb and resource (return one evidence JSON file for a page view) and enumerates the three distinct file categories it can return (reveal-*, frame-*, viewport-*). This clearly separates it from siblings like get_page_evidence_image and get_capture_asset, which are image-oriented.

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 is implied by the file-name references (the file must come from get_page_summary.evidence or element fields), but the description never states when to choose this tool over get_page_evidence_image or the other evidence/asset siblings. An agent must infer the routing from parameter semantics rather than being told.

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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description usefully adds the return format (WebP, one image per call) and the tie to structured evidence, but omits resolution, size, and error behavior when the file is missing or a non-image (e.g. the .json example in the schema).

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 return type, then the usage note. The enumerated scope list is long but each item carries real distinguishing information rather than 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?

An output schema exists, so return values need no explanation, and the schema carries full parameter sourcing detail. The description adequately covers what the tool fetches and why; only fallback/error behavior is left implicit.

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 every parameter (file, page, view, product, version, environment) is already documented with sourcing guidance. The description adds no parameter-level meaning beyond the schema, 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?

States a specific verb and resource (return one evidence WebP for a page view) and enumerates the exact categories of image it can return: component states, hover/click reveals, alternate color scheme, extra viewport width, embedded frame. This lets an agent distinguish it from generic image siblings like get_page_image, though no sibling is named explicitly.

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?

"Use for visual checks of what the structured evidence describes" gives an implied workflow (fetch the image after reading the structured evidence), but names no alternative or exclusion. With ~9 sibling image-fetching tools, the agent gets only partial 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?

Annotations declare readOnlyHint, idempotentHint, destructiveHint. The description adds context that it returns a WebP of a captured viewport (format and nature of result). But with annotations covering safety and an output schema present, a 3 is appropriate — the description adds the returned format but doesn't elaborate on behavioral nuances like pagination, caching, or error conditions.

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?

Single sentence, front-loaded with verb and resource, no unnecessary content. 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?

For a read-only image retrieval tool with full schema coverage and an output schema, the description is nearly complete. It states the return format and input source. The only missing piece is explicit routing relative to similar image-fetching siblings, but overall the agent has enough to call 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 schema fully documents parameters like page, view, version, environment. The description only reiterates 'exact stored page profile key' and 'selected environment', adding minimal value beyond what the schema already provides. Baseline 3 is correct.

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?

States a specific verb+resource: 'Return a captured viewport WebP' for a stored page profile key. The scope (exact stored page profile key from list_pages, selected environment) is clear. It distinguishes itself from siblings like get_page_artifacts/get_capture_image by specifying WebP and viewport, though it doesn't explicitly name what makes it different from get_capture_image.

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?

Implicitly guides via 'exact stored page profile key from list_pages' — telling the agent where the key comes from. But it lacks explicit when-to-use/when-not guidance, especially against closely related siblings like get_capture_image, get_click_image, or get_page_image vs get_page_artifacts.

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/destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: idle none/0s declarations are omitted and crawl does not record per-frame playback timings, which tells the agent what data will be missing. No pagination behavior is described, keeping it from a 5.

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?

Three short sentences, front-loaded with the resource scope and followed by the concrete contents and the two data-omission caveats. Every sentence carries information; nothing is redundant padding.

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 an output schema present, return-value shape need not be explained, and the description covers scope, item categories, and known data gaps (idle declarations, per-frame timings). The only omission is explicit guidance on when to use this versus the transitions/component-animations siblings.

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 every parameter (including the nuanced page/view/version/environment semantics) is thoroughly documented in the schema itself. The description adds no parameter-level syntax or format detail, so the baseline 3 for fully-covered schemas 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 gives a specific verb ('List') and a precisely scoped resource ('motion for one page view'), then enumerates the three motion categories returned: view entrances (fade/rise, stagger), procedural canvas/shader fields, and real CSS animations. This clearly separates it from component-level siblings like get_component_animations, though it never names an alternative tool outright.

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 is only implied: the tool is scoped to 'one page view' and must be driven by the page/view/version keys, but there is no explicit statement of when to reach for this versus get_page_transitions or get_component_animations. The agent must infer the routing condition from the resource scope alone.

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 readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuine workflow context — that nested outline leaves are structure hints rather than separate bundle targets — but does not clarify the 'bundleTarget=true top-level' filtering behavior or return shape in plain terms.

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, and the entry-point role is front-loaded. However, the density of unexplained jargon ('Batch IR entry', 'bundleTarget=true top-level') slightly undercuts 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies the missing piece — the workflow relationship to bundle tools — making it adequate for this complexity level, with only the cryptic filter syntax left unexplained.

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% and the parameter descriptions (page, view, version, environment) are already detailed and prescriptive. The description adds nothing about parameters, so the baseline of 3 applies since the schema carries the full semantic load.

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?

States a concrete verb+resource ('list page sections plus regions') and positions itself as the entry point of a bundle workflow. It differentiates from siblings by naming get_section_bundle and get_page_bundles, though 'Batch IR entry' and 'bundleTarget=true top-level' are internal jargon that a fresh agent may not parse.

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?

Gives explicit ordering ('Call this first, then one get_section_bundle / get_page_bundles per region only') and names the alternative tools. It lacks an explicit when-not-to-use, but the sequencing constraint is clear enough to route the agent correctly.

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/destructiveHint=false, so safety is covered. The description adds the shape of the banding output, which is useful, but discloses nothing about cost, granularity limits, or side effects beyond what annotations and the output schema supply.

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 the core purpose front-loaded and no filler. The second sentence is dense with undefined terms (bundleTarget, regionIndex), which costs a little clarity but not length.

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?

An output schema exists, so return values needn't be spelled out, and the description still sketches them. For a 5-parameter read tool with full schema coverage and annotations, this is close to complete; only the undefined regionIndex/bundleTarget vocabulary leaves a small 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% and each parameter (page, view, product, version, environment) is already documented with usage warnings in the schema. The description contributes no additional parameter meaning, 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?

Specific verb+resource: 'Map a page into viewport-height bands', plus the concrete payload of those bands (y bounds, element counts, heading previews). It also names the sibling get_page_outline regions and contrasts itself with it, so the agent can distinguish the two.

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?

Explicitly routes the agent: prefer get_page_outline with bundleTarget=true, and reserve regionIndex for viewport banding rather than micro-sections. That is real when-to-use guidance naming an alternative, though the conditions ('bundleTarget=true', 'micro-sections') are not defined anywhere in the schema.

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=false, so the safety profile is covered. The description adds only the 'when present' qualifier — useful, since the artifact may be absent — but does not say what an agent sees when it is absent (error vs empty result).

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 with no filler; the scope constraints are stated compactly. It earns its length, though the trailing 'when present' qualifier is the only piece of added 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?

An output schema exists, so return-value explanation is not required, and the fully documented input schema carries parameter burden. The remaining gap is the absent-artifact behavior, which is not described.

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 all five parameters are already documented in the schema with sourcing guidance. The description only echoes the view/environment scoping, adding no syntax or format detail 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?

States a specific verb and resource: it returns stack.json for a page capture, scoped to a view key and environment. It is distinguishable from siblings like get_page_artifacts or get_page_bundles, though it never explicitly names an alternative to route against.

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 'for an exact stored view key and environment' and 'when present' implies the required context, but there is no explicit when-to-use / when-not-to-use guidance and no named alternative for agents that need other page artifacts.

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 covered. The description adds only a contents list and parameter provenance; it discloses nothing further about auth requirements, rate limits, or whether the profile is a live capture vs. stored snapshot. Adequate but not rich given the annotation floor.

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, zero filler, and the payload contents are front-loaded before the key-sourcing note. Tight and well-ordered, though the field enumeration partly duplicates the 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?

An output schema exists, so return values need no explanation, and all five parameters are fully documented in the schema. The description supplies the routing-level overview an agent needs; only sibling differentiation 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 description coverage is 100% and each parameter carries detailed guidance (page is not a URL, view is not an OS, version must be pinned, environment sourcing). The description's "stored view key from list_pages" merely echoes the schema, so 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?

States a specific verb+resource ("Get one page profile") and enumerates the profile contents (URL, title, viewport, outline, layout, fonts, themes, links), which conveys it is an aggregate summary rather than a single-facet tool. However, it never names or contrasts against close siblings such as get_page_outline or get_themes, so differentiation is left to inference.

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?

"Use a stored view key from list_pages and the selected environment" gives a prerequisite for obtaining the view argument, which is useful context. But there is no when-to-use-this-vs-alternatives guidance, no exclusions, and no statement of when the summary is preferred over the more granular page tools.

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=false, so safety is covered. The description adds genuine semantic context beyond annotations: results are potential (discovered) transitions rather than observed navigation events, which tells the agent what the data does and does not represent.

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, zero filler; the core action is front-loaded and the disambiguating scope note follows immediately. 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 an output schema, full schema coverage, and annotations, the description only needs to convey scope and semantics, which it does. Minor gap: it speaks of a 'captured route' while the required parameter is a captured 'page' key, and a route-oriented sibling exists, so an agent may want one word tying the two vocabularies together.

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 all seven parameters (page, view, version, product, environment, limit, offset) are already documented with format and provenance guidance. The description adds no parameter-level meaning, so the baseline of 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?

States a concrete verb+resource: lists links discovered on a captured route and resolves them to captured route names. The clarifying line 'potential transitions, not observed clicks' distinguishes it from click-observation siblings, but no sibling such as get_route_tree is named for contrast.

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 is only implied — an agent can infer you call this to enumerate outgoing links for a page/route. There is no explicit when-to-use, when-not-to-use, or alternative (e.g., get_route_tree, list_pages) called out, so selection still requires inference.

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 covered. The description adds the cross-product/platform/environment scope and the multi-environment caveat, but says nothing about cost, aggregation breadth, or whether an environment-less call silently picks a default.

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 scope and then the environment caveat. The output enumeration is dense but each item earns its place by telling the agent what the summary actually contains.

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 an output schema present, return values need no explanation, and the description adequately covers what is aggregated and how environment selection works. It is slightly thin on prerequisites for the required version/platform values, but the schema descriptions carry those.

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 product, version, platform and environment in detail; baseline 3 applies. The description restates the environment hint ('specify environment from list_versions') but does not resolve the apparent source discrepancy with the schema, which points to list_platforms for environment IDs.

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?

States a specific verb (summarize) and resource (product version + platform + environment) and enumerates the summarizable dimensions: page count, stack, languages, media, fonts, themes, routes, recordings. That enumeration lets an agent distinguish it from narrower siblings like get_page_summary or get_version_metadata, though no sibling is named explicitly.

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?

Only actionable guidance is the conditional 'For multiple environments, specify environment from list_versions,' which addresses the optional parameter. There is no statement of when to prefer this aggregate summary over siblings such as get_version_metadata, get_page_summary, or get_technology_stack, leaving usage largely 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?

readOnlyHint=true already covers the safety profile, and the description adds real behavioral context on top: public scope omits owner identity, private details and safety/review notes, and capture progress is surfaced without job IDs. That goes beyond what the annotation provides.

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 front-loaded with the core purpose, then layers in scope behavior and provenance in compact sentences. It is slightly repetitive with the schema text but has no filler sentences.

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?

An output schema exists, so return-value detail is not required, and the description still covers both scope modes, the visibility restrictions, and where requestId comes from. It is essentially complete for a read tool of this complexity, with only inter-sibling routing left implicit.

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, and the description largely restates the scope semantics and the requestId provenance. The baseline 3 applies because the description adds little parameter meaning the schema does not already carry.

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?

States a specific verb and resource ('Get a product request') and clarifies the two visibility modes. It also names the siblings that produce the requestId (create_product_request, list_product_requests), giving partial differentiation without a full contrast against wait_product_request or get_request_options.

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?

Explains the scope=mine vs scope=public selection and what each returns, which effectively tells an agent when to pick each mode. It stops short of stating when to prefer this tool over list_product_requests or wait_product_request, so it is clear context rather than full when/when-not 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 cover the read-only/idempotent/non-destructive profile, yet the description adds substantial context: the size bound (two viewport heights), what is preserved and deduplicated, how inline media is replaced with references, and that the default returns a small manifest plus an artifact path meant to be consumed outside model context. That last point materially changes how an agent should handle the result.

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?

Front-loaded with what the tool produces, then handling guidance, then parameter routing. Dense but mostly waste-free; 'No screenshot analysis required' is slightly tangential but does preempt a common misread.

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 8-parameter tool with an output schema, the description covers output shape, size limits, media handling, and the default-vs-inline tradeoff. Nothing an agent needs to call it correctly is missing, and return-value explanation is not required given the 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 coverage is 100%, so the baseline is 3. The description reinforces inline semantics and the yStart/yEnd fragment intent, but these largely restate the schema's own parameter descriptions rather than adding new syntax, units, or constraints.

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?

States a specific verb+resource ('Exact reconstruction IR') and pins down the scope ('at most two viewport heights'), with a concrete inventory of what it preserves. It does not name or differentiate against the obvious siblings (get_section_bundle, get_page_bundles), so an agent still has to infer which bundle tool to pick.

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?

Gives actionable conditions: default vs inline=true, and 'Use yStart/yEnd for the requested fragment; do not fetch fine-grained layers for the same fragment' plus 'No screenshot analysis required.' That is clear when-to-use and a when-not, but it never names an alternative tool to route to.

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 covered without the description. The description adds only that the manifest 'includ[es] step results', a small structural hint, and says nothing about pagination, size, or failure modes for an unknown replay key.

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 with no filler or repetition of the title. Nothing in it is wasted.

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?

An output schema exists, so return values need not be explained, and the schema carries the parameter prerequisites. What remains missing is the family-level routing information that matters here, since this tool sits among scenario-manifest, replay-step, and replay-list siblings that are easy to confuse.

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 all four parameters including the optional environment default are already well documented in the schema. The description adds no parameter meaning, which lands at the baseline for high-coverage schemas.

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?

States a specific verb and resource: 'Return the manifest of one scenario replay', plus a scope qualifier ('one', i.e. not aggregated). It is readable alongside siblings like get_replay_step and list_replays, though it never explicitly distinguishes itself from get_scenario_manifest, whose name is close enough to invite confusion.

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 when-to-use, when-not-to-use, or alternative routing. The workflow context (replay key from list_replays, version from list_versions) lives entirely in the schema parameter descriptions, not in the description text, so the agent gets no guidance from the field it is scored on.

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=false, so the safety profile is fully covered by structured data. The description adds one piece of content context - that the payload is a pass/fail verdict with an observed outcome - but says nothing about behavior such as error handling when the step is missing or how large the response is. Modest added value over 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?

A single short sentence with no padding, front-loading the verb ('Return') and the resource ('one replay step'). It is efficient, though very terse for a tool with a four-parameter required chain.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a tool that requires product, version, replay, and step, the description omits the prerequisite discovery flow entirely (relying on the schema text) and gives no hint about what a failed step looks like. Adequate but with clear 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 100% and all five parameters are documented in the schema itself (including the one-based step index and the environment default). The description contributes no additional parameter meaning, so the baseline of 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 states a specific verb and resource: it returns one replay step, identified concretely as the result.json artifact containing pass/fail and observed outcome. It implicitly separates 'replay step' from the many get_* siblings (replay manifest, replay step image, scenario step), but never names an alternative, so an agent must infer the boundary.

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?

There is no explicit when-to-use guidance and no named alternative. The description does not tell the agent when to pick this over get_replay_manifest or get_replay_step_image, nor does it state the prerequisite chain (obtain replay via list_replays, version via list_versions). Usable context exists only in the schema's parameter descriptions, not here.

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 covered. The description adds one useful behavioral note with 'when present,' signalling an optional/absent result, but says nothing about how absence is surfaced or how the webp is returned. Additive but thin.

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 with no filler, identifying the resource before the availability caveat. It is appropriately sized for a simple fetcher, though it is arguably too terse to carry much operational 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?

An output schema exists, so return-value explanation is unnecessary, and 'when present' covers the absent-artifact case. However, given the four-required-parameter key chain (product/version/replay/step) shared with list_replays and get_replay_step, the description does not tie itself to that workflow, leaving the agent to reconstruct it from the schema alone.

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 all five parameters (including the replay/version/step key chain and the environment default) are already documented in the schema. The description adds no format or relationship detail beyond what the schema provides, so 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?

States a specific verb (Return) and a precise resource (the after.webp captured for one replay step), which distinguishes it from image siblings like get_scenario_step_image or get_page_image. It does not explicitly name those alternatives, so it falls short of a 5.

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 only guidance is the trailing 'when present,' which hints the artifact may be absent but gives no when-to-use condition, no prerequisites, and no routing versus the other image-fetching siblings. Usage is left to inference.

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 the description adds real context beyond them: availability is administrator-configured, results may be narrower than capture options, and an empty list is a meaningful signal that submissions are disabled. Not a 5 because it says nothing about freshness, caching, or what the response structure looks like beyond IDs.

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 short sentences, front-loaded with the resource definition and followed by the downstream usage, the narrowing caveat, and the empty-result semantics. Every sentence carries distinct information with no repetition of the title or 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?

For a zero-parameter read with an output schema and readOnlyHint coverage, the description supplies everything an agent needs: what the data is, how it differs from capture options, how to use the IDs, and the operational meaning of an empty 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to explain and the description correctly does not attempt any. It does clarify that the meaningful payload is 'returned IDs', which primes the agent for how to consume output.

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?

States a specific verb and resource (backend-defined platform/environment options for product requests) and contrasts them with capture options, so the agent knows this is a narrower, product-request-specific set. It does not name the obvious sibling (list_platforms) as an alternative, so differentiation is implied rather than explicit.

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?

Explicitly routes downstream usage: 'Use returned IDs in create_product_request,' which tells the agent this is a prerequisite lookup rather than a standalone query. It also gives a decision rule for empty results ('no platforms means new submissions are disabled'), but never states when to prefer this over list_platforms.

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 non-destructive behavior, so the safety profile is covered. The description adds genuine value by disclosing the data source and the fallback to captured page URLs when routes.json is unavailable, which the annotations do not convey.

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 carries purpose, source, and fallback behavior with no filler. It is dense but every clause earns its place; slightly more scannable phrasing could push it higher.

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 an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies the missing behavioral context (source file, fallback), leaving only sibling-routing guidance as a 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%, with each parameter richly documented and cross-referenced to list_versions and list_platforms. The description restates product/version/platform at a high level but adds no syntax or format detail beyond the schema, 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?

States a specific verb (Return) and resource (hierarchical route tree) scoped to a product version on a platform, and clarifies the data origin (routes.json with discovered router/sitemap/link paths). This clearly distinguishes it from flat listing siblings like list_pages, but it never names an alternative tool, so differentiation is implicit rather than explicit.

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 the tree is sourced (routes.json, falling back to captured page URLs) but never states when to prefer this over siblings such as get_page_outline or list_pages, nor any prerequisites. Usage is inferable from the resource description rather than spelled out.

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 true and destructiveHint false, so the safety profile is covered. The description adds one genuinely useful behavioral fact – the return format is WebP – but says nothing about size, caching, failure modes, or permissions. Appropriate credit for the format disclosure, no more.

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 with no filler; the resource and both scoping constraints are packed in efficiently. It is tight, though terse enough that it omits any routing guidance that could have earned space.

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 an output schema present, return values need not be explained, and annotations carry the safety profile; the schema itself fully documents all five parameters. The description is sufficient for an agent to call this correctly, missing only explicit sibling routing.

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 such as view, product, version, scenario, and environment are already richly documented in the schema, including how to obtain each key. The description only echoes the 'exact stored view key' and 'selected environment' constraints, adding no format or syntax detail beyond the schema. 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 gives a specific verb and resource ('Return the initial WebP from a recorded scenario') plus scoping qualifiers ('exact stored view key in the selected environment'), which distinguishes it from step/capture/page image siblings by the word 'initial'. It does not explicitly name a sibling to contrast with, so it falls short of a 5.

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 is only implied: 'initial' versus a step image implies this is the first-frame variant, and the schema descriptions reference list_pages/list_versions/list_scenarios for obtaining keys, hinting at the workflow. There is no explicit when-to-use/when-not statement or named alternative (e.g., get_scenario_step_image).

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 the useful content scope (step order, view, action, route transitions), but says nothing about error behavior, version-mismatch handling, or size/limits of the manifest.

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 sentence that front-loads the action and resource and then lists the payload contents. No filler, no restatement of the title.

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 an output schema present and annotations covering safety, the description need not explain return values. Parameters are fully documented. The only real gap is the absence of routing guidance among the many get_* manifest and step siblings.

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 product, version, scenario and environment are all documented in the schema, including the non-obvious warning against using 'latest' as an alias. The description adds no parameter-level meaning beyond that; 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?

States a specific verb (Return) and resource (the manifest of one recorded scenario) and enumerates the content it carries: step order, view, action, route transitions. This distinguishes it from step-level siblings like get_scenario_step, though it never explicitly contrasts itself with the similarly named get_replay_manifest.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative despite two closely related siblings (get_replay_manifest, get_scenario_step). The agent must infer from the name alone that this is the aggregate manifest for a scenario rather than its replay counterpart.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real context beyond that: the Admin review/redaction prerequisite, the fact that frames are re-read from current page artifacts so manual blur cannot leak stale text, and the explicit caveat that missing animation or intermediate interaction evidence stays unknown.

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 action is front-loaded in the first sentence and each subsequent sentence carries distinct information (prerequisite, discovery routing, privacy behavior, data limits). It is dense but nearly waste-free; only the framing could be trimmed slightly.

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 an output schema present, the description needn't describe return shape, and it instead covers the non-structural gaps an agent actually needs: availability gating, prerequisite review state, and known evidence limitations. Nothing required to call 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 description coverage is 100%, and the parameter docs already spell out product key format, version pinning ('do not use latest as an alias'), scenario ID provenance, and the environment fallback rule. The description only restates that the scenario comes from list_scenarios/get_scenario_manifest, adding no new syntax or format guidance, so 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?

States a specific verb and resource: 'Export a manually recorded scenario as canonical Scene with all referenced screen frames and observed transitions.' The qualifier 'manually recorded' distinguishes it from the replay-based siblings such as get_replay_manifest and get_interface_scene, so an agent can pick it without opening 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?

Gives a hard availability gate ('only for a published version after human Admin review/redaction') and routes discovery through list_scenarios and get_scenario_manifest. It stops short of naming the alternative for non-manual/replay scenarios, which is the one remaining inference an agent must make.

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, covering the safety profile. The description adds a summary of the returned payload, but since an output schema exists this overlaps structured metadata and discloses no auth requirements, rate limits, or error 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?

Single sentence, front-loaded with the verb and resource, with no filler. Every element of the sentence contributes to identifying the tool's output.

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 with complete parameter descriptions and an existing output schema, the description adequately identifies the resource and its payload. The only notable gap is the lack of usage routing against sibling step tools.

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 fully documents all five parameters. The description adds no parameter-level syntax or format details beyond what the schema already provides, making the baseline 3 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?

States a specific verb 'Return' and resource 'one recorded scenario step', then enumerates the payload (click target, pre-click state, post-click page capture, and observed CSS motion events). This distinguishes it from siblings like get_scenario_step_image or get_replay_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?

Provides no explicit when-to-use or when-not-to-use guidance. It does not contrast with alternatives such as get_replay_step or get_scenario_step_image, so an agent must infer selection from the resource name alone.

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 covered. The description adds only the format (WebP) and the timing semantics (captured after the step), which is modest value but not the kind of context (auth needs, availability of the captured step, failure when no step exists) that would be most useful.

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 sentence with zero filler, front-loading the action and the artifact. Nothing in it is redundant with the title and nothing is padded.

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 output schema exists, so return-value explanation is unnecessary, and the 100%-covered schema handles the calling contract. What is missing for a 47-sibling tool is disambiguation — the description never explains how this differs from the replay-step or initial-image variants, which is the main thing an agent must get right.

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 every parameter carries a detailed description, including cross-references to list_versions, list_scenarios, and list_platforms. The description adds no parameter meaning of its own, so 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?

States a concrete verb and resource: 'Return the WebP captured after one recorded scenario step.' The word 'after' pins the artifact to the post-step capture, which implicitly separates it from get_scenario_initial_image. However, it never names or contrasts with its closest siblings (get_replay_step_image, get_scenario_initial_image), so the differentiation is left to inference.

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 when-to-use guidance, no prerequisites, and no exclusions. With four sibling image-retrieval tools (get_replay_step_image, get_scenario_initial_image, get_capture_image, get_click_image) in the same listing, the agent gets no help choosing among them beyond the name itself.

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