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 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?

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 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 this a safe, idempotent, open-world read. The description adds genuinely useful behavioral context beyond them: what the capture covers, that it returns an inline filmstrip JPEG plus a .webm path, and that it requires the optional playwright and ffmpeg-static dependencies. It does not state duration limits, timeouts, or failure behavior for heavy sites, keeping it 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?

Two dense sentences: the first front-loads purpose and scope, the second covers output and dependency requirements. No filler, and the most important information leads.

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 correctly carries the return format (filmstrip JPEG plus .webm path) and runtime prerequisites. With 100% schema coverage the parameters are handled elsewhere. The only real gap is sibling/usage discrimination, which keeps it from being 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 the schema already explains url, frames, viewport, and waitStrategy fully. The description adds no parameter-level detail (e.g., how long a 'short' recording is or how frame count affects runtime), 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 — recording a short motion-through video of a live website — and enumerates the exact animation types captured (preloader, scroll-triggered, hover/cursor). It is unambiguous on its own, but it never names or contrasts with close siblings like capture_live_site or watch_site, 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?

There is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as capture_live_site (static capture) or watch_site (monitoring). An agent must guess which recording/capture sibling fits a given request.

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 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.