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

Annotations already cover the safety profile (readOnly, non-destructive, open-world, non-idempotent), so the bar is lower. The description adds genuinely useful behavior beyond them: the ≤20 element sampling cap and the live-page/URL scope. It doesn't mention timing, rate limits, or failure modes, keeping it at 4.

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 the core operation, then the use case, then scope — every clause carries information. The trailing "does not fetch awwwards.com" note is slightly cryptic but functions as a useful scope boundary; near-optimal sizing overall.

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

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

With no output schema, the description steps in by describing the return content (counts, sampled elements, changed properties with duration/easing), which is exactly what an agent needs. It omits any note on result format or limits on the count output, so not quite 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 75%, so the schema already explains url, viewport, and reducedMotion. The description adds no parameter-level detail (e.g., what waitStrategy does or when to choose networkidle), so the baseline 3 is appropriate.

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

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

States a specific verb and resource — a ":hover interaction census" — and enumerates exactly what it produces: hover rule counts, up to 20 sampled interactive elements, and CSS properties that change with duration/easing. This distinguishes it clearly from siblings like analyze_scroll_map or analyze_page_structure that census different interaction axes.

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 it to reproduce micro-interactions and verify interaction-state coverage" gives a clear when-to-use rationale, and the scope note (runs on any URL, does not fetch awwwards.com) bounds applicability. It stops short of naming an explicit alternative (e.g., a motion or scroll analyzer) or a when-not condition, so it falls under 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 cover the safety profile (readOnly, idempotent, non-destructive, open-world). The description adds non-obvious behavioral context: it runs via a headless browser and accepts local file:// paths, which tells the agent this fetches and renders remote/local content. It stops short of noting timing/cost or pagination behavior, but that gap is minor given 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?

Two tight sentences, front-loaded with the action and output shape, followed by scope and intended use. Every clause earns its place with no redundancy.

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

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

With no output schema, the description usefully compensates by enumerating the per-band fields returned. Combined with the schema's full parameter coverage, an agent has enough to call it correctly, though return-format details (ordering, error shape) are not spelled 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 the schema already documents url, maxBands, viewport, and waitStrategy in detail. The description's field list describes the OUTPUT shape rather than adding meaning to the parameters, 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 (extract) and resource (a page's section band map) and enumerates the returned fields (tag, label, background color, offset, height per band). This clearly distinguishes it from siblings like capture_live_site, get_site_elements, and compare_sites, which operate on different data.

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

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

It names a concrete use case — comparing a reference site's structure against a local build — and clarifies it accepts both live URLs and file:// paths. However, it does not explicitly state when NOT to use it or name the sibling alternative for the comparison workflow (e.g. compare_sites).

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/closed-world, so the safety profile is covered. The description adds genuinely extra behavior: frames preloaded inline, camera path interpolated between snapshot scroll ratios, prefers-reduced-motion static fallback, and no network access — context an agent cannot get from the hints alone.

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?

Dense but front-loaded: the rendering action leads, then input provenance and behavioral caveats follow. Every clause carries information, though the em-dash run-on is heavy and the trailing 'no awwwards.com access' clause is a slightly awkward tack-on.

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 two-param build tool with no output schema, the description explains behavior thoroughly but never says what the tool returns or where the stub page lands (inline payload? file path? HTML string?). That missing return-shape detail is the main completeness 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 coverage is 100%, so the baseline is 3, but the description adds downstream meaning: scrollCensus yields 'census-derived st/pin/ease suggestions' and the pose grid is the 'pose-grid-v1' variant from a specific tool. That clarifies the effect of the optional input beyond the schema's terse field notes.

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 artifact: renders a pose-grid-v1 capture into a standalone scroll-scrubbed three.js stub page. It names the upstream producing tools (capture_pose_3d, analyze_scroll_map), so an agent can place it precisely in the pipeline rather than guessing among build/verify 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?

The origin of both inputs ('from capture_pose_3d', 'from analyze_scroll_map') implies the prerequisite flow, and 'Pure build — no page fetches, no awwwards.com access' draws a clear boundary against the fetch-oriented siblings. It stops short of an explicit when-not or a named alternative, so 4 rather than 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=true, openWorldHint=true, destructiveHint=false and idempotentHint=false, so the safety profile and the fact that results may vary between calls are covered. The description usefully adds what gets captured and the fact that it operates against arbitrary network URLs, but says nothing about auth, rate limits, timeouts, or where the resulting pack goes.

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 payload enumerated immediately after the verb. The trailing scope disclaimer is compact but its phrasing is slightly indirect, keeping this just short of 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?

For a four-parameter, network-touching capture tool with no output schema, the definition covers the action and the capsule contents that come back. It leaves open what the 'portable pack' looks like, how large a capture can be, and how failures on unreachable or restricted pages are surfaced.

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% — url, maxNodes, selector and viewport all carry descriptions, defaults, and ranges. The description adds only high-level payload content ('structure, computed-style tokens, animations'), which does not map to specific parameter semantics, 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?

Names a specific verb (serialize) and resource (a page component) plus the payload contents (structure, computed-style tokens, animations), which is far more than a restatement of the name. It does not, however, distinguish itself from plausible siblings like capture_live_site or analyze_page_structure, so the agent must still infer which capture tool fits.

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 statement, no prerequisites, and no routing to an alternative. 'Runs on any URL — does not fetch awwwards.com' reads as a scope disclaimer rather than guidance, and is ambiguous about whether awwwards URLs are supported or merely irrelevant.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description's only added behavioral fact is the headless-browser mechanism and the playwright dependency; it says nothing about timeouts, rate limits, or failure behavior on unreachable URLs.

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 action, zero filler. The dependency caveat is the only secondary detail and it is stated tersely.

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

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

With no output schema, the description does not indicate what a successful capture returns (image bytes, file path, URL). For a network-facing capture tool that omission is a real gap, though annotations and the rich schema cover the input side adequately.

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 url, viewport and waitStrategy are fully documented in the schema, including enum meanings and defaults. The description adds nothing beyond that, which is the expected baseline when the schema does the heavy lifting.

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 ('Take a fresh full-page screenshot of a live website URL') plus the mechanism ('headless browser'). It is clearly distinguishable from siblings like analyze_page_structure or record_site_motion, though it never names a sibling 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?

Usage is only implied by the name and the verb. The one piece of guidance given ('Requires the optional playwright dependency') is a prerequisite rather than a when-to-use rule, and no alternative tool is mentioned for overlapping tasks like structure analysis.

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 read-only/open-world annotations, the description discloses non-obvious behavior: it targets the largest canvas, uses toDataURL with a viewport-screenshot fallback, samples up to 10 scroll steps with per-step ratios, and carries a hard dependency on playwright. The fallback and dependency requirements are exactly the traits an agent must know before invoking.

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, no filler. The core action and its output are front-loaded, with constraints (URL scope, playwright dependency) trailing. Every clause carries information an agent can act on.

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

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

With no output schema, the description should ideally characterize the returned pose grid, but it only hints at 'per-step scroll ratios' without describing the output structure. Parameters are fully covered by the schema and annotations cover safety, so the remaining gap is modest but real.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that the steps parameter produces per-step scroll ratios used for camera-path reconstruction, and clarifies the scroll-sampling semantics tied to the 'up to 10' cap. This goes beyond restating the schema's defaults and ranges.

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 (capture) and resource (a page's WebGL/canvas 3D pose grid), then specifies the mechanism (largest canvas via toDataURL with screenshot fallback) and the analytic purpose (reconstructing scroll-driven 3D camera paths). This clearly separates it from siblings like capture_live_site, capture_component, and analyze_scroll_map.

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 context: works on any URL, explicitly does not fetch awwwards.com, and requires the optional playwright dependency. It does not, however, name a sibling or state when to prefer this over capture_live_site or analyze_scroll_map, so the alternative-selection guidance is implicit rather than explicit.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new context: output is text only (no imagery), and missing details are fetched and cached — implying network calls and possible latency. It stops short of stating caching lifetime or failure 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 sentences, front-loaded with the comparison scope, then a second sentence covering output mode and data-fetch behavior. No filler.

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

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

There is no output schema, so enumerating the returned facets in the description is exactly what's needed; combined with the text-only and fetch/cache notes, an agent has enough to invoke and interpret results.

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 single param (slugs) is fully documented in the schema, including the 2–3 distinct-slug constraint that mirrors min/maxItems. The description restates the count but adds no format guidance beyond the schema, 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 (Compare) and resource (design DNA of Awwwards sites) with explicit scope (2–3 sites) and enumerates the compared facets (titles, URLs, palettes, technologies, elements, awards, jury scores). This clearly distinguishes it from the single-site sibling get_site_details.

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 2–3 site scope implies this is the multi-site comparison tool versus get_site_details for one site, but it never states when to prefer it or what to do for a single site. Usage is inferable rather than explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds little beyond that: it does not say the tool fetches live Awwwards pages (openWorld), what the synthesized brief looks like, or how citations are attached. Note the mild tension between the 'create_' name and readOnlyHint=true, though the description's 'synthesize' wording does not itself claim persistence.

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 zero filler, and the key input constraint leads the phrasing. It is efficient, though arguably too sparse for an eight-parameter tool.

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 eight-parameter, no-output-schema tool, the definition omits what the brief contains, what citations mean, how audience/constraints/maxBands shape the result, and that live external sites are fetched. An agent can form a rough call but not a confident one.

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

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

Schema description coverage is only 25% — viewport and waitStrategy are documented in-schema while goal, audience, maxBands, constraints and includeStructure are not. The description only restates the slugs constraint (2–5 references), adding no meaning for the other six parameters, so it fails to compensate for the coverage gap.

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 (synthesize), resource (design direction / brief), and input scope (2–5 Awwwards references), which cleanly separates it from sibling analysis tools like compare_sites or analyze_page_structure. It stops short of saying what a brief actually contains, so it is clear but not fully self-explanatory.

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 guidance on when to reach for this tool versus the many sibling analysis tools, nor any prerequisites or exclusions. The only implicit signal is that you need 2–5 reference slugs in hand, which is already enforced by the schema's minItems/maxItems.

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, and closed-world, so the safety profile is covered. The description adds real value by disclosing the shape of the returned content (related elements, parent project), which is otherwise unknown since there is no output schema. Error behavior and any lookup limits are not mentioned.

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; the payload enumeration comes first and the prerequisite is placed last as an actionable instruction. Every clause earns its place.

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

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

For a single-param getter with no output schema, the description supplies the return-field inventory and the id-acquisition path, which is most of what an agent needs. It omits failure behavior for unknown slugs, a minor gap given the tool's simplicity.

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?

Only one parameter and schema description coverage is 100% ('Element slug from search_elements'), so the schema already carries the semantics. The description reinforces the id's origin but adds no format or syntax detail beyond the schema. 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?

Specific verb (get) plus resource (one Awwwards element) with an explicit enumeration of the returned payload: title, author, built-with stack, media URLs, related elements, and parent project. It separates itself from the sibling search_elements by being the single-item 'full detail' endpoint.

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 to search_elements first to obtain ids, which is the correct prerequisite for this tool. It stops short of stating when NOT to use it or what happens with an invalid/unknown slug, 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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the meaningful operational detail that this is an offline cache read with no live requests, plus a lock state indicator — useful context 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?

A single front-loaded sentence that lists the return contents. Every clause earns its place; 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?

There is no output schema, so the description carries the return-value burden — and it does, enumerating cached site count, progress, last successful finish, error, lock state and freshness. Nothing an agent needs to call this 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?

The tool takes zero parameters, so the baseline is 4; there is nothing to mis-document and the description correctly implies a parameterless read.

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 offline index status') and enumerates exactly what the status comprises: cached site count, progress, last finish/error, lock state, freshness. No sibling tool overlaps with index status, so the agent can route here unambiguously.

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 'No live requests' signals this reads cached/offline state rather than triggering network activity, which implicitly contrasts with the capture_live_site / watch_site siblings, but the description never says when to prefer this tool over others or any prerequisites.

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 and openWorldHint. The description adds genuinely useful operational context beyond them: it serves a cached corpus first and only then performs a live headless-browser capture, implying network access and variable latency for unseen URLs.

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; the output inventory comes first and the corpus/live-capture behavior follows. Every clause conveys usable 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?

No output schema exists, but the description enumerates the returned fields, which compensates. Combined with annotations covering safety and idempotency and the stated headless-browser fallback, an agent has enough to call this 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% (url and recapture are both documented in the schema), so the schema carries parameter meaning. The description does not add syntax or format detail for either parameter, nor does it cross-reference the recapture flag against the corpus-first behavior it describes. 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 ('Get the Motion DNA of a website') and enumerates the returned content (animation stack, ScrollTrigger/pin/scrub counts, easing vocabulary, duration distribution). This clearly separates it from search_motion or record_site_motion, 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?

Usage is only implied: 'Serves the corpus first; live-captures unseen URLs' tells the agent when a live capture happens, but there is no explicit when-to-use guidance versus siblings like search_motion or capture_live_site, and no stated exclusions or prerequisites.

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, open-world behavior, so the safety profile is covered. The description adds value beyond that by disclosing the actual returned content (palette, tech stack, elements, awards, inline screenshot), which matters since there is no output 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?

A single dense sentence with the verb and resource front-loaded and zero filler; every clause (palette, technologies, elements, awards, description, screenshot) earns its place by telling the agent what comes back.

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 one-parameter read tool with full annotation coverage, the definition is nearly complete: it states the payload and the schema supplies slug format and origin. The one gap is the absence of any usage/routing guidance relative to siblings such as search_sites.

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 slug property already carries a pattern constraint, a concrete example ('l-i-s-a') and its origin tool. The description adds nothing further about the parameter, 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 (Get) plus resource (one Awwwards site) and an explicit enumeration of the payload — color palette, technologies, design elements, awards, description, screenshot. That enumeration usefully separates it from siblings like get_site_elements or get_motion_dna, though no sibling is named 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?

The description gives no when-to-use, no prerequisites, and no alternatives. The only workflow cue ('slug from search_sites') lives in the input schema, not in the description, so an agent gets no routing guidance from the text itself.

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, open-world), so the bar is lower. The description adds genuine context the annotations cannot: posters are returned inline while video is delivered as URLs, which shapes how the agent handles the payload. It omits pagination or result-limit 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?

A single front-loaded sentence with no filler; the leading clause carries the action and the trailing parenthetical enumerates content types. Slightly dense with the nested list, but nothing 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?

With no output schema, the description usefully characterizes the return payload (inline posters, video URLs). It stops short of covering volume, ordering, or empty-result behavior for a site with no elements, which is the main remaining 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 even supplies a format hint ('l-i-s-a'), so the parameter is fully documented structurally. The description adds no syntax or sourcing detail beyond implying a single-site identifier, making the baseline 3 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 and resource ('Get the design-element highlights of one Awwwards site') and enumerates the component types returned (3D models, video content, mobile layouts, microcopy). The single-site scope implicitly separates it from search_elements/get_element, though no sibling is named 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: 'of one Awwwards site' signals per-site retrieval, but there is no explicit when-to-use, when-not, or pointer to alternatives such as search_elements for cross-site queries. An agent must infer the routing itself.

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). The description adds value beyond them by disclosing what the return content actually is (color hexes, tag/technology slugs) and how it feeds into search_sites, which is the real behavioral insight for a zero-arg lookup tool.

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 is named first, the contents second, and the downstream use last—no sentence 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?

With no parameters, no output schema, and annotations covering safety, the description is nearly self-sufficient for such a simple tool. It could optionally note the output shape (e.g., grouped lists) but nothing essential to correct invocation is absent.

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 no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-param tool applies. No parameter meaning is missing.

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 (filter taxonomy on Awwwards), then enumerates the concrete contents (color hexes and tag/technology slugs). An agent can immediately distinguish this discovery tool from sibling search tools like search_sites.

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 "usable with search_sites" makes the purpose context explicit: this is the tool to call first to learn valid filter values before searching. It does not spell out a when-not condition, but the intended workflow is clear from the linkage to a named sibling.

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, openWorldHint, destructiveHint=false, and the key idempotentHint=false. The description earns credit by explaining that non-idempotence: the first call seeds the baseline and returns no delta, and later calls return only new entrants. That stateful, call-order-dependent behavior is exactly what an agent needs and is not derivable from the annotations alone.

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 compact sentences, front-loaded with the core action and delta semantics before the polling cadence and sibling pairing. Every sentence carries information, though the two polling-related clauses overlap slightly in intent.

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

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

With no output schema, the description must convey the return shape, and it does so adequately by defining the result as new-entrant cards since the last call, including the baseline-seeding edge case. It omits error/rate-limit behavior, which is a minor gap for a polling 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% and the single 'award' enum is fully documented in the schema, so the baseline is 3. The description never mentions the award parameter or how it affects the delta, adding nothing beyond the structured schema.

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

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

The description states a specific verb ('Poll'), a precise resource ('today's new Awwwards winners'), and the exact mechanism ('as a delta against the previous poll'). It is immediately distinguishable from the read-oriented siblings like search_sites or get_site_details, and it explicitly names its closest relative, watch_site.

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

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

It gives clear usage context ('Poll daily for a winners feed') and routes the agent to the sibling tool for a related mode ('pairs with watch_site for structured monitoring'). It stops short of stating an explicit when-not condition or full alternatives, so it is strong but not exhaustive.

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/openWorld/idempotent/non-destructive, so the description's job is to add behavior beyond the safety profile — and it does: inline filmstrip JPEG plus a .webm path, an additional on-disk Motion Evidence Sheet (keyframes, diff masks, cursor-trail overlay, timeline strip), and the optional playwright/ffmpeg-static dependency requirement. What it omits is failure behavior when those optional deps are absent and any runtime/duration limits on 'short' recording.

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 sentences, front-loaded with the core action and output before the dependency and side-artifact details. The parenthetical inventories (preloader/scroll/hover; keyframes/diff masks/cursor-trail/timeline) are dense but each clause carries distinct information, so little is 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 no output schema, the description carries the return-value burden and does so — inline filmstrip JPEG, .webm path, and the evidence sheet are all named. Parameters are covered by the schema and the environment prerequisite is disclosed; only error/edge behavior (missing optional deps, very heavy sites, recording time bounds) is left unstated.

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 four parameters (url, frames, viewport, waitStrategy) are documented with defaults, ranges, and enum meanings in the schema itself. The description adds nothing parameter-specific — it names only the target ('live website') — so the baseline 3 for schema-carried parameter semantics 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 precise verb+resource ('Record a short motion-through video of a live website') and enumerates exactly what motion is captured (preloader, scroll-triggered, hover/cursor) plus the concrete outputs (inline filmstrip JPEG, .webm path, Motion Evidence Sheet). It is very clear what the tool does, but it never names or contrasts itself with the nearby siblings (capture_live_site, analyze_hover_census, analyze_scroll_map, get_motion_dna), so the agent must infer the boundary itself.

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 by what gets captured — there is no explicit when-to-use, when-not-to-use, or alternative-naming guidance, which matters given several sibling tools cover overlapping motion/scroll/hover analysis. The dependency prerequisite ('Requires the optional playwright and ffmpeg-static dependencies') is a useful precondition but does not tell the agent when to pick this over capture_live_site.

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, open-world, non-destructive behavior, so the safety profile is covered. The description adds two things annotations cannot: the mutual-exclusivity rule for category/stack and the fact that every result links back to its source element page and parent project, which tells the agent what it gets back.

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 compact sentences: the first names the resource, the second front-loads the usage rule. No filler, no restatement of the name or 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 no output schema, the description responsibly notes the shape of results (links to source element page and parent project). Combined with the input constraint, an agent has enough to call correctly; only the limit parameter's tuning guidance is left 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 coverage is 75%, so the schema already documents query, stack, and category. The description goes beyond it by stating that at most one of category/stack may be supplied, a constraint not encoded in the schema, which materially affects how the agent builds the call.

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 (search) and resource (Awwwards' curated element gallery) and clarifies the resource with concrete examples (footers, menus, loaders, transitions). An agent can see this is the component-level search, distinct from search_sites and search_motion, though it never explicitly names those siblings to sharpen the 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?

The 'Usage:' clause gives a real input constraint (query text plus at most one of category/stack), which is actionable. However, it says nothing about when to prefer this tool over get_site_elements, get_element, or search_sites, so the when-to-use decision is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, covering the safety profile. The description's 'Corpus only' line reinforces the closed-corpus behavior and adds the live-capture contrast, which is useful but largely consistent with openWorldHint=false. Nothing is said about result shape, ranking, or how limit interacts with the corpus.

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 verb and resource, then a single routing clause. No filler and nothing repeated.

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

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

With no output schema, the description should convey what comes back; 'find sites that...' implies site-level results, which is adequate for a four-param, all-optional search tool. Missing details are minor — result ordering and pagination behavior relative to limit.

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 75% (lib, hasPins, scrubOnly documented), and the description largely restates those same semantics rather than adding format, token, or matching detail. The undocumented 'limit' is self-explanatory via min/max. Baseline 3 fits when the schema already carries the parameter meaning.

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

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

States a specific verb (Search) and resource (captured Motion DNA records) and then concretizes the searchable properties: pinned sections, scroll-scrubbed animation, animation libraries. It also contrasts itself with the sibling get_motion_dna, so an agent can route 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?

Explicitly scopes usage to the existing corpus and names the alternative for the live path ('live-capture happens via get_motion_dna'), which is a real when-to-use/when-not split. It does not, however, distinguish itself from search_sites or search_elements, so the routing guidance is clear but incomplete.

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 the read-only, non-destructive safety profile, so the bar is lower. The description adds useful behavioral value by describing the return shape (site cards with inline screenshots, live URLs, awards, tags), but says nothing about pagination, result limits, or the effect of responseMode on payload size.

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, no filler, with the primary action stated first and the return contents immediately after. Nothing in it can be cut 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?

With no output schema, describing the card contents is necessary and present, which helps. However, a 9-parameter search tool with no usage scoping and undocumented pagination/count behavior is only minimally covered.

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?

Across 9 parameters the description adds no filtering semantics at all: it only mentions tags and awards as things returned in cards, not as query filters. With 67% schema coverage, page, award, and count have no documented meaning in either place, so the description fails to compensate for the gap.

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 ('Search award-winning websites on Awwwards') with the return payload named, so the agent can tell it is a query tool rather than a detail/fetch tool. It does not explicitly contrast itself with siblings like search_elements, new_winners, or get_site_details.

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, no prerequisites, and no named alternatives. The agent must infer from the name that this is the entry point before drilling into get_site_details or compare_sites.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description usefully adds the output shape (pass/warn/fail verdict with evidence lines) and the two analysis methods, but it ignores the notable idempotentHint=false, giving no signal about non-determinism or the cost/latency of fetching and rendering two live URLs.

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

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

Two dense sentences, front-loaded with the core action and result type, with no filler. The closing 'Closes the design loop' line is mildly promotional but earns some of its place by conveying workflow context.

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

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

There is no output schema, and the description compensates by naming the return artifacts (verdict plus evidence lines) and the comparison basis. Combined with annotations covering safety and network scope, it is nearly complete; only the failure/non-idempotency behavior remains unaddressed.

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 75% and the schema already documents buildUrl, referenceUrl and the viewport default with concrete dimensions. The description names the reference concept but adds no syntax, precedence, or guidance for waitStrategy, which the schema leaves entirely bare. 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 and two resources ('compare a built site against a reference') and concretizes the comparison dimensions (band-structure match + motion fingerprint). It does not, however, distinguish itself from the sibling 'compare_sites', leaving a plausible ambiguity for an agent picking between 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?

The phrase 'Closes the design loop: build → verify → fix → re-verify' implies the workflow position, and the examples (Awwwards winner, client's old site) hint at likely scenarios. But it never states when NOT to use it or which sibling (e.g. compare_sites, analyze_page_structure) covers adjacent needs, so the routing 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=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds non-obvious behavioral context beyond them: the mutation actions (add/list/remove) and the dependency that deltas only surface after new_winners or search_sites refreshes the underlying listing.

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 tightly packed sentences front-load the resource and the three target kinds before the action list and refresh dependency. Every clause earns its place with 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?

With no output schema and five parameters, the description adequately covers the targets, the three actions, and how deltas are produced. It leaves some ambiguity about exactly what 'list' returns and how the award filter interacts, though the schema covers those fields.

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

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

Schema description coverage is 80%, so the schema already documents kind, note, award and pattern. The description reinforces the kind semantics with concrete examples ('ToyFight', 'webgl', URL-slug), adding modest value, but introduces no syntax or format detail the schema lacks. 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 and resource — a longitudinal watchlist over Awwwards listings — and enumerates the three watchable targets (studio, tag, url) with concrete examples. It is clearly distinguishable from sibling tools like search_sites or new_winners 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 description gives clear workflow context: watches are managed via add/list/remove, and 'the delta is reported by watch_site list after new_winners or search_sites refreshes the listing,' explicitly naming the sibling calls that feed it. It stops short of stating when NOT to use the tool, so it lands at 4 rather than 5.

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