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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description is relieved of safety disclosure. It adds valuable behavior: 'using headless browser' implies the tool fetches the live page and could be subject to site access or latency, and 'get back the exact values' hints at the output precision. This goes beyond the annotations without contradicting them.

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

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

The description is three sentences with zero fluff. It front-loads the primary purpose in the first sentence, then reinforces scope and integrates with siblings. Every sentence earns its place, making it concise and well-structured.

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

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

The tool is simple (3 params, 1 required, booleans with defaults) and has no output schema, so the description need not detail return structure excessively. It covers the purpose, usage context, and practical behavior adequately. Minor gaps like error handling or return format are not critical given the simplicity and existing annotations.

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

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

The input schema has 100% description coverage, so all three parameters (url, mobile, dark_mode) are already fully documented. The description adds no additional meaning about parameter usage or semantics, so it sits at the baseline of 3 as per the rubric.

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

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

The description uses a specific verb 'Extract' and a clear resource 'design tokens', enumerating the token categories (colors, typography, spacing, borders, shadows) and specifying it works on a live website via headless browser. This clearly distinguishes it from sibling search tools, which are about finding references, while this actually extracts values.

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

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

The description provides usage context by stating 'Give it any URL and get back the exact values used' and explicitly pairs it with search tools: 'find inspiration, then extract tokens from sites you like.' This implies a clear workflow, but it refers to 'search tools' generically without naming the specific sibling tools (e.g., design_search_styles), so it lacks the explicit alternative routing seen in the highest-scoring examples.

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 tool read-only, idempotent, and non-destructive. The description adds useful behavioral context by explicitly ruling out browsing, capturing, and invoking other MCPs, which goes beyond the structured annotations.

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

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

Two short sentences deliver the core action and key exclusions with no wasted words. The most important operational information is front-loaded.

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

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

For a zero-parameter, annotation-covered tool, the description fully covers what the tool does and what it avoids. The phrase 'selected references' assumes prior context, but the lack of parameters and strong annotations make this sufficient.

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

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

The tool has zero parameters, so there is no parameter semantics for the description to clarify. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any schema gaps.

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

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

The description uses specific verbs ('validate and normalize') and identifies the resource ('selected references'). It also explicitly distinguishes itself from sibling search tools by stating it does not browse, capture, or invoke other MCPs.

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

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

The description clearly positions the tool as a preparation step for already-selected references and tells the agent what it will not do. It implies the right conditions for use, though it does not explicitly name sibling alternatives as replacements.

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

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

The annotations indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive, which already establish safety. The description adds that it performs image search across specific sites and returns certain metadata, but doesn't disclose behaviors like pagination, rate limits, or result ordering, which might be relevant for a search tool. It doesn't contradict annotations, but adds minimal new behavioral context beyond the search scope.

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

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

The description is concise, at two sentences, with the core function stated upfront and the searching tip as a secondary sentence. Every sentence adds value without redundancy.

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

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

The tool is simple with three parameters, a clear output description in the description text, and extensive annotation coverage (read-only, idempotent). The description adequately covers: what it searches, what it returns, and query guidance. However, it lacks details on result pagination or how to interpret the returned metadata, but given the simplicity and annotations, it's sufficiently complete.

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

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

The input schema already provides descriptive parameter documentation, with near 100% coverage (the 'sites' parameter includes enum values and explanation). The description reinforces the need for specific query terms but doesn't add much beyond the schema. For 'num' and 'sites', the schema covers their usage, so the description adds limited value here.

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

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

The description clearly states the tool searches images across specified sites and returns URLs, dimensions, and source links. It uses a specific verb and resource, distinguishing it from sibling tools which focus on references or styles. However, it doesn't explicitly differentiate from design_search_styles, which might overlap, but the image-search focus is clear.

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

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

It provides explicit advice on query phrasing: use specific UI terms over vague ones, which guides when to use this tool effectively. However, it doesn't contrast against sibling tools like design_search_styles or design_search_references, leaving it to the agent to infer which search is appropriate based on context.

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

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

The description conveys that this is a read-only operation that is safe and idempotent. It adds the useful behavioral note that it searches the web, not a local database, and that it returns web results rather than being limited to visual output. It doesn't cover what happens with image search, but for a read query this is reasonable and exceeds 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?

The description is only two sentences, but those two sentences contain actionable guidance. The first sentence states what it does, and the second highlights when to use it over an alternative. This is efficient and well-structured.

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

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

For a read-only search tool with no output schema, the description covers the return value types and the when-to-use scenario. It doesn't mention pagination or result limits, but those are available in the schema. The sibling tools are not referenced to direct the agent toward or away from them, which would be a minor improvement.

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

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

The schema covers 100% of parameter descriptions, including examples for query and valid sites. The description field in the schema provides good context, so the main description isn't burdened with parameter details. However, the description does reference the general purpose and output type, which gives the agent a high-level expectation of what the parameters accomplish. Given full schema coverage, this is a solid 3.

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 ('web search scoped to design platforms') and the return types (article titles, snippets, links). It doesn't explicitly distinguish from the two sibling search tools, but the scoping gives useful context. The examples in the schema parameters provide additional clarity.

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 a when-to-use comparison against image search, which is a clear alternative. It fails to mention when image search might be better, but it does name one specific use case where this tool excels (case studies, write-ups, documentation), giving the agent a practical rule.

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

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

Beyond the annotations (read-only, idempotent, open-world), the description discloses that it runs image and web searches in parallel and merges results — genuinely useful operational knowledge an agent wouldn't get from the schema alone. This tells the agent to expect combined, multi-source output from a single call. The annotations already cover the safety profile, so the description earns credit for adding the execution model on top.

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: the first front-loads the purpose with concrete examples, the second covers the single non-obvious behavioral trait (parallel execution). Not a single wasted word.

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

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

For a read-only search tool with three well-documented parameters, the description covers purpose, scope, and combined-result behavior. The main gaps are an unspecified return format (no output schema exists) and no disambiguation from the similarly named sibling tools — minor for a low-risk, read-only operation.

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

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

Schema description coverage is 100%, so all parameters (style, type, num) are already documented. The description's style examples map naturally onto the type enum values ('color-palette', 'typography', 'layout', 'animation'), which provides a slight bridge between intent and schema. But it adds no format, syntax, or behavior details that the schema doesn't already state, landing at a solid baseline.

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

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

The description clearly states the tool's purpose: searching for a specific aesthetic direction with concrete examples like color palettes, typography, layouts, and animation references. The parallel image/web search detail adds specificity beyond a generic search. However, it doesn't explicitly distinguish itself from the closely related siblings design_search_images or design_search_references, which an agent would need to infer on its own.

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 opening 'Search for a specific aesthetic direction' conveys when to use the tool, and the style examples give useful intent context. But there's no explicit when-not-to-use guidance or any mention of alternatives, which is a real gap given sibling tools like design_search_images and design_search_references are topically adjacent. Usage is implied rather than stated.

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