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

With no annotations, the description carries the full burden, and it does add one useful behavioral fact: the tool returns scored findings with fix suggestions. However, it omits whether this is purely static analysis (no runtime/rendered DOM), whether it mutates anything, and any size or rate constraints, so the disclosure is partial.

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-loaded with the action and resource, then the return value. No filler, 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?

No output schema exists, but the description compensates by stating the return shape (scored findings with fix suggestions), and all parameters are documented in the schema. Minor gap: it does not clarify the static-vs-runtime nature of the analysis, which matters given the live_audit sibling.

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 framework, categories, wcag_level, and component_name are already fully documented in the schema. The description adds no meaning beyond that baseline (e.g., how framework changes parsing or what happens when categories is omitted).

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?

Uses a specific verb ('Audit') with a clearly bounded resource ('HTML/JSX/Vue/Svelte markup') and enumerates the three analysis dimensions (accessibility/WCAG, performance, responsive). An agent can tell it is a static markup analyzer, but it never names or distinguishes itself from close siblings such as live_audit or auto_fix_component.

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

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

Usage is only implied: the input types suggest 'use this when you have source markup to check.' There is no statement of when to prefer it over live_audit (runtime page auditing) or auto_fix_component (applying fixes), nor any prerequisites or exclusions.

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

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

With no annotations, the description must carry behavioral disclosure. It usefully bounds scope to 'common' accessibility and performance issues and states the return value, implying a non-destructive transform that hands back markup. It does not say whether every finding will be fixed, what happens to unfixable findings, or whether anything is written to disk.

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 fix behavior and its scope lead, followed by the return value. No padding or repetition of the schema.

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

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

For a two-parameter tool with no output schema and no annotations, the description covers purpose, scope limits, and the return shape (corrected markup plus applied-fix list). It is only mildly short on edge-case behavior such as findings it cannot auto-fix.

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

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

Schema description coverage is 100%, so both parameters (markup, findings) are already documented in the schema. The description adds no syntax, format, or size guidance beyond referencing 'audit findings', so the baseline 3 applies.

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

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

States a specific verb (fix) and resource (markup issues) scoped to accessibility and performance problems derived from audit findings. The phrase 'based on audit findings' effectively ties it to the audit_component sibling, though it does not name that sibling outright.

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

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

Usage is only implied: the input 'findings' come from an audit, so the natural workflow (audit_component then auto_fix_component) is inferable. There is no explicit statement of when to use this versus auditing again, nor when not to run it.

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

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

With no annotations, the description carries the full burden. It does disclose the destructive scope ('clear all design tokens from the active token store'), which is the key behavioral fact, but says nothing about reversibility, undo, permissions, or confirmation, leaving significant gaps for a destructive operation.

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

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

Two short sentences, front-loaded with the action and scope, followed immediately by the use case. No filler or repetition.

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

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

For a zero-parameter tool with no output schema and no annotations, the description covers purpose, scope, and intended timing adequately. It could add whether the operation is irreversible or what state remains after clearing, but nothing essential for invocation 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 there are no parameter semantics to explain and the baseline of 4 applies. The description correctly implies no filtering options exist ('all tokens').

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 — 'Clear all design tokens from the active token store' — with scope ('all') and target ('active token store'). It implies differentiation from import_design_tokens via the reset scenario, but does not explicitly name or contrast sibling tools.

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

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

Gives a concrete situation for use: 'reset before importing a new set of tokens.' That is clear context, but there are no exclusions (e.g., what to do instead if you only want to remove a subset, or whether a backup/export is required first).

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses meaningful output traits (imports, semantic structure, skip navigation), which is more than a bare restatement, but it omits failure modes, permission/auth needs, or what happens when a component name is unknown.

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

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

Two sentences, front-loaded with the core action and zero filler. Every clause earns its place by adding scope or output detail.

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 three-parameter tool with no output schema and no annotations, the description usefully sketches the return artifact ('a full page with imports, semantic structure, and skip navigation'). It is still thin on edge cases and on the relationship between component_names and the framework's expected output.

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 enum for framework is documented, so the schema does the heavy lifting. The description adds no parameter-level meaning (e.g., that component_names must match registry keys), so the baseline of 3 is appropriate.

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

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

States a specific verb ('Compose') and resource ('page layout') and scopes the source ('previously generated components in the registry'), which implicitly distinguishes it from the single-component sibling generate_component. It stops short of naming or directly contrasting with any sibling, but the resource is unambiguous.

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 'previously generated components in the registry' implies a precondition (components must already exist before composing), which is a useful usage cue. However, there is no explicit when-to-use vs. alternatives guidance, no mention of what to do if components are missing, and no routing to siblings such as generate_component.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints that only 'active' tokens are exported, which is useful, but does not say whether output is returned inline or written to a file, nor whether the operation is read-only or mutating.

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; every clause (verb, resource, formats) 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 simple one-parameter tool with no output schema, the description covers purpose and formats adequately, but omits the delivery mechanism (return value vs. file) and any usage context, leaving a meaningful gap for an unannotated 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?

With a single parameter at 100% schema coverage, the baseline is 3. The description restates the enum options and slightly clarifies what 'css' means (CSS custom properties), but adds little beyond the schema's own enum.

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 (Export) and resource (active design tokens) and enumerates the three target formats. It implicitly contrasts with siblings like import_design_tokens and clear_tokens, but never explicitly distinguishes itself from them.

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

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

The description never states when to export versus using an alternative sibling, nor any prerequisites or context of use. An agent must infer the appropriate moment to call it purely from the name.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses that a Personal Access Token is required, that extraction goes through a remote REST API, and that tokens are normalized and written into the active token store (a mutating side effect). It still omits what happens to pre-existing tokens when merge_strategy is left at its default and any rate-limit/error behavior.

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

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

Three short sentences, purpose front-loaded, no filler. The final auth sentence partially duplicates the figma_pat schema description, which keeps it just short of ideal.

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?

Covers source, destination, auth, and normalization for a 5-parameter tool with no annotations. The main gap is that no output schema exists and the description never indicates what the call returns or how success/failure is reported.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, including the PAT, the namespace prefix, and the merge_strategy enum. The description adds nothing beyond 'Requires a Figma Personal Access Token', which the schema already states, so the baseline 3 applies.

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

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

States a specific verb (extract) and resource (design tokens: colors, typography, effects), names the source (Figma REST API) and the destination (active token store). This clearly separates it from generic token siblings, though it never explicitly contrasts itself with import_design_tokens.

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 exclusions, and the obviously related sibling import_design_tokens is never referenced. The agent must infer that this tool is the Figma-specific path and that other importers cover other sources.

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

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

With no annotations, the description carries the full burden. It discloses two useful traits: output is 'production-ready' and token-aware ('uses active design tokens if loaded'). It does not explain side effects (does it write files?), what auto_audit actually does at runtime, or auth/permission needs.

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 with no filler; the core action is front-loaded and the token dependency is stated second as a qualifier.

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 9-parameter generator with no output schema and no annotations, the description is merely adequate. It never describes what the tool returns (code snippet, file path?) or how include_tests/auto_audit manifest, leaving those to the schema alone.

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

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

Schema description coverage is 100%, so all nine parameters are already documented by the schema, including enums and defaults. The description adds no syntax or format detail beyond restating the framework list, 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 (Generate) and resource (UI component) and enumerates the supported frameworks, so the agent knows exactly what it produces. It does not name or contrast against siblings like generate_story or compose_layout, but the purpose itself is unambiguous.

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

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

Usage is implied by the generation verb, and the phrase 'Uses active design tokens if loaded' hints at a precondition (run import_design_tokens first). However, there is no explicit when-to-use versus alternatives guidance and no exclusion conditions.

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

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

With no annotations, the description carries the full burden. It usefully discloses the generated output shape (CSF3, default + variant stories, play functions, a11y addon config), but says nothing about whether a file is written to disk, its path, overwrite behavior, or error conditions for unsupported frameworks.

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 artifact format, then the contents. No filler or redundancy.

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

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

For a generation tool with no annotations and no output schema, the description explains what the artifact contains but omits where it is written, what the tool returns, and any failure modes. Adequate but with clear gaps for an agent invoking it.

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

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

Schema description coverage is 100%, so all four parameters are already documented, including the framework enum and the story_title default. The phrase 'Detects props from code' hints that component_code is parsed, but no param-level detail is added beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Auto-generate') and resource ('Storybook story file (CSF3 format) for a UI component'), and enumerates the artifact contents (default story, variant stories, play functions, a11y config). It is distinguishable from generate_component, but it never names that sibling explicitly, so the differentiation is left implicit.

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

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

There is no when-to-use guidance, no prerequisites (e.g., must exist alongside generate_component), and no alternatives named among the many siblings. The only implied context is 'for a UI component', which is too thin to route an agent between this and generate_component.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the destination store and the downstream consumer, but says nothing about whether the import mutates/overwrites existing tokens, permission needs, or failure behavior for invalid JSON; the merge semantics live only in the schema.

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

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

Two sentences, zero waste, and the core action plus destination are front-loaded before the downstream-use note. Nothing is padded or redundant.

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

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

For a mutation tool with no annotations and no output schema, the definition should disclose more about side effects and results. Parameters are well covered by the schema, but the lack of any indication of overwrite risk, auth requirements, or return shape leaves a meaningful gap.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including the merge_strategy enum values and the namespace example. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (Import) and resource (design tokens) and names the three supported source formats plus the destination (active token store). It is clear what the tool does, though it does not explicitly contrast itself with the related sibling extract_figma_styles, which an agent could easily confuse with this tool.

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

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

Usage is only implied: the agent can infer this is the tool for bringing external token data in, and the description notes the downstream consumer (generate_component). There is no explicit when-to-use guidance and no exclusion versus extract_figma_styles or clear_tokens/export_tokens.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does reveal the payload (accessibility tree, component structure, performance metrics, optional screenshot) and the Playwright dependency, and inspection is inherently read-only, but it says nothing about runtime cost, latency of a headless navigation, failure modes, or whether the call has side effects against the target site.

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 written sentences: the operation is front-loaded in sentence one, and sentence two covers output and the dependency. Nothing is redundant or padded.

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

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

For a six-parameter, read-only inspection tool with no output schema and no annotations, the description supplies the missing return-value context (what gets extracted) and a dependency prerequisite. The remaining gap is disambiguation from near-neighbor siblings, but the operational picture is otherwise sufficient.

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

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

Schema description coverage is 100% and all six parameters (including enum, ranges, and defaults) are documented in the schema itself. The description only restates that a screenshot is optional, adding no syntax, format, or interaction detail beyond what the schema already provides — the baseline of 3 is correct.

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

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

The description gives a specific verb ('Inspect') and resource ('a live web page using a headless browser'), plus an enumeration of what it extracts. It is clear what the tool does, but it never distinguishes itself from plausible siblings such as live_audit, visual_diff, or responsive_preview, which an agent would have to guess between.

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 statement of when to reach for this tool versus the audit/preview siblings, nor any exclusion guidance. The only contextual information is a dependency note ('Requires Playwright (optional dependency)'), which reads more like an environment caveat than usage direction.

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

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

With no annotations, the description carries full burden. It mentions 'Requires Playwright' which is useful context about external dependencies. However, it doesn't disclose whether the audit is read-only, if it has side effects (e.g., page navigation), performance impact, timeout behavior, or what the output looks like. For a live navigation tool, these are significant omissions.

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 main action and scope, then the dependency requirement. No wasted words; efficient and clear.

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

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

For a tool with no annotations, no output schema, and 3 parameters (all schema-documented), the description is adequate but incomplete. It doesn't explain what the audit returns, whether it modifies state, or how it differs from sibling tools. The Playwright requirement is helpful but insufficient for full behavioral disclosure.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including enum values and defaults. The description adds no additional parameter meaning beyond what's in the schema. Baseline 3 is appropriate when 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?

The description states a clear verb (audit), resource (a live web page), and scope (accessibility, performance, and responsive checks on rendered HTML). It distinguishes itself from audit_component by specifying 'live web page' with navigation. The only minor gap is that it doesn't explicitly contrast with inspect_page or visual_diff.

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

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

The description implies usage by requiring Playwright and navigating to a URL, but doesn't state when to use this over audit_component or inspect_page. No explicit when-to-use or when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the exact viewport widths and the Playwright runtime dependency, but omits whether output is inline images or file paths, how page-load readiness is handled, and any auth or rate-limit behavior for a read-style capture.

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 viewport specifics; the prerequisite follows. No filler or redundancy.

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

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

For a single-parameter capture tool with no annotations and no output schema, the description covers what is captured and the Playwright requirement, but leaves the return format (images vs. saved files) unspecified, which is the main thing an agent still needs to know.

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 coverage is 100%: the schema already documents target_url, its maxLength, http/https restriction, and private-IP blocking. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

States a specific verb (Screenshot) and resource (a URL), plus the exact scope: three named viewports with pixel widths. An agent immediately knows the output is a responsive-comparison capture, though it never names the nearby siblings (visual_diff, inspect_page) to disambiguate.

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

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

The phrase 'for responsive comparison' implies the intended use case, but there is no explicit when-to-use guidance, no exclusions, and no pointer to an alternative such as visual_diff or inspect_page when only one viewport or a diff is wanted.

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

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

With no annotations, the description carries the full burden. It discloses the return shape (changed pixel count and percentage) and a dependency fact (Playwright not required), which is genuinely useful, but says nothing about whether a diff image is produced, side effects, or processing limits for large images.

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

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

Three short sentences with zero filler; the core action is front-loaded and each sentence adds a distinct fact (action, return, dependency).

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-image comparison tool with no output schema and no annotations, the description covers the action, inputs (base64 PNGs, inferable from schema), and return summary. It is nearly complete, only lacking detail on the optional threshold's effect and whether image artifacts are emitted.

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 threshold, before_image, and after_image parameters are already documented in the schema. The description adds no additional parameter meaning (e.g., how threshold interacts with the reported percentage), so the baseline of 3 applies.

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

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

States a specific verb and resources ('Compare two PNG screenshots pixel-by-pixel') plus the domain ('visual regression testing'). No sibling tool does image-to-image comparison, so the agent can route to it without opening the schema.

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

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

The 'for visual regression testing' phrase implies the use case, and 'Does not require Playwright' hints at an alternative execution path, but no explicit when-to-use vs when-not guidance or named alternative tool is given.

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