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

With readOnlyHint=true and openWorldHint=true already provided, the description adds meaningful behavioral context: it launches a real browser, runs axe plus dynamic checks (focus, target size, skip navigation), and is KWCAG-grounded. It does not contradict the annotations, though it could mention side effects like screenshots or network activity more explicitly.

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 purpose and method, then a clear usage instruction and prerequisite. Every sentence earns its place with no redundant 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?

The description covers purpose, when to use, and a prerequisite well. However, given the tool's complexity (10 params, nested objects, low schema coverage), the description does not fully prepare an agent to configure the audit correctly—especially around output handling, timeouts, and scoping options.

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

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

Schema description coverage is only 40% with 10 parameters, so the description carries a heavy burden to explain parameter meaning. It partially explains the 'checks' concept by naming axe, focus, target size, and skip navigation, but it does not clarify url constraints, viewport, timeoutMs, outputDir, screenshot, maxFindings, or excludeRules. This is a significant 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?

The description states a specific action ('opens the URL in a real browser and performs an audit') and a concrete standard (KWCAG 2.2) with specific dynamic checks. This clearly distinguishes it from siblings like check_html or check_contrast, which are narrower or static checks.

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 states when to call it ('site inspection / certification preparation') and gives an explicit prerequisite: check browser_status first. It does not explicitly discuss when not to use it relative to siblings, but the context and prerequisite are concrete enough.

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

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

Annotations already declare readOnlyHint=true, and the description is consistent with that. It adds useful behavioral context beyond annotations: the ordered browser fallback chain (Chrome→Edge→Playwright chromium) and the precondition relationship with audit_url.

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 a single sentence that states both the tool's purpose and its usage context with zero wasted words. The key fact (check before audit_url) is prominent and easy to parse.

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: no required parameters, a fully documented optional parameter, an output schema present, and read-only annotations. The description covers the essential workflow placement and browser scope, so nothing critical 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 sole parameter refresh is fully documented in the schema (100% coverage), so the description need not repeat it. With schema coverage this high, the baseline of 3 applies; the description adds no parameter-level meaning but does not need to.

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 and resource: it checks whether the browser that audit_url will use (Chrome→Edge→Playwright chromium) is installed. It also names the related sibling audit_url, making the tool's role in the workflow immediately distinguishable.

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 explicitly instructs the agent to run this check before calling audit_url. This is a clear, actionable when-to-use directive that leaves no ambiguity about placement in the workflow.

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 discloses the core behavior beyond the readOnlyHint annotation: it not only calculates a ratio but also returns a pass/fail judgment against a specific standard. It does not contradict the read-only annotation. Though it does not discuss invalid color handling or alpha edge cases, the read-only nature and output schema lower the burden, and the stated behavior is accurate and useful.

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

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

The description is a single, front-loaded sentence with no filler. It states the action, the object, and the evaluation standard, and every element contributes to agent understanding.

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 relatively simple two-color contrast checker, the description covers the essential purpose and standard, while required parameter formats are provided in the schema and return semantics are presumably covered by the output schema. The only notable gap is the lack of sibling comparison or explicit when-to-use guidance, but for this isolated utility the description remains 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 schema already documents foreground/background color formats well, covering 50% of parameters. The description adds the KWCAG criterion context but does not explain the effect of bold and fontSizePx on the threshold determination. The optional parameter semantics are mostly left to their names, defaults, and common knowledge, so the description provides only modest extra meaning over the schema.

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

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

The description clearly states what the tool does: it calculates the luminance contrast between two colors and determines whether the contrast passes KWCAG 5.4.3(1.4.3). The verb 'calculates' and 'judges' alongside the specific resource '두 색상 사이의 명도 대비' make the purpose unambiguous and distinguish it from sibling tools like check_html or audit_url.

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 in accessibility contrast-checking contexts via the KWCAG reference, but it does not explicitly state when to use check_contrast versus alternatives such as check_html or audit_url, nor does it provide exclusions. The intended use case is reasonably inferable, but the guidance is left to implication rather than explicit 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?

Annotations already declare readOnlyHint=true, and the description adds meaningful behavior beyond that: it runs without a browser, performs static analysis only, and explicitly discloses that contrast, focus indication, and target size checks are not fully performed and are marked as 'browser audit required'. This is honest, specific, and materially shapes agent expectations.

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

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

Three dense sentences with no filler: first states what the tool does, second states when to call it, third states the key browserless limitation. Everything earns its place and the most important information is front-loaded.

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

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

For a read-only static checker with an output schema, the description covers purpose, invocation context, and behavioral limitations well. It could be slightly stronger by explicitly naming sibling tools for the browser-required checks or clarifying network/auth assumptions, but nothing essential for correct 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?

Schema description coverage is 67%, so most parameters are already documented. The description reinforces the html/path either-or relationship by mentioning both HTML strings and local HTML files, but it adds no new meaning for baseUrl, ruleset, maxFindings, or excludeRules. With moderate schema coverage, a 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 action (static accessibility inspection), a clear resource (HTML strings or local HTML files), and a concrete standard (KWCAG 2.2). The addition of 'static' and 'without a browser' distinguishes it from sibling tools like check_contrast and audit_url.

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 tells the agent when to use the tool: 'must call when writing, modifying, or reviewing web UI code'. It also implies a boundary by stating that rendering-dependent checks are only marked as needing browser audit, but it does not name specific sibling alternatives for when a browser audit is required.

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 adds meaningful behavioral context beyond the readOnlyHint annotation: it explicitly warns that automated inspection alone does not determine certification pass and that remaining manual/user review items are reported. This is valuable transparency for an estimation tool and aligns with the read-only annotation.

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, both information-dense and non-redundant. The core action is front-loaded, and the important caveat about automated-only assessment is placed second without bloating the description.

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

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

Given the read-only annotation, fully described parameters, and clear input sources, the description provides enough context for an agent to invoke the tool correctly. It also communicates what the output conveys: per-item compliance rates and remaining manual/user review. A fully explicit output schema would raise this further, but its absence is partly compensated by the description.

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 parameters are already documented in the schema, including the mutual exclusivity of reports/reportPaths and the default for pageCount. The tool description adds high-level context about aggregating Reports but does not add parameter-level detail beyond what the schema provides.

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 plus resource: it aggregates multiple inspection Reports into per-item compliance rates to estimate web accessibility certification readiness. It also clearly distinguishes itself from lower-level inspection tools like check_html or audit_url by operating on their outputs rather than performing inspections itself.

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

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

The description implies when to use the tool: after obtaining Reports from check_html or audit_url, and when estimating overall certification readiness across multiple pages. It does not explicitly name alternatives or state when not to use it, but the input dependency and estimation purpose provide clear contextual 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool creates a checklist and lists scopes, but does not describe output format, whether the operation has side effects, authentication needs, or any behavioral quirks. For a tool with no annotation coverage, this is insufficient behavioral transparency.

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 a single sentence, front-loaded with the core action and scope. Every part contributes to understanding the tool's purpose, with no redundant or irrelevant material.

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 has no annotations and no output schema, so the description alone must provide sufficient context. It explains the purpose but omits usage guidance, return value/format, and behavioral caveats. Given the presence of siblings and a required scope parameter, the definition is not fully complete for an agent to invoke it correctly without extra assumptions.

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 67%, so the baseline for this dimension is neutral. The description adds the scope categories (검사항목/컴포넌트/페이지/사용자 평가), which map to the scope enum, but it does not add meaning for the id or component parameters beyond what the schema already provides. This is adequate but not compensatory.

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 ('만든다' - creates) and a specific resource ('KWCAG 2.2 체크리스트'), and enumerates the four scope types. This clearly distinguishes get_checklist from siblings like check_contrast, check_html, audit_url, and lookup_checkpoint, which are inspection/lookup tools rather than generation 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?

There is no explicit guidance about when to use this tool versus alternatives, no exclusions, and no mention of sibling tools. The scope list hints at use cases, but the description does not state e.g. 'use when you need to create a checklist by scope' or 'use lookup_checkpoint for individual checkpoint details.'

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 read-only, non-destructive, and idempotent behavior, so the description only needs to add contextual detail. It adds the accepted lookup keys and KWCAG 2.2 version, but it does not clarify what summary vs full returns or how results are formatted. No contradiction exists.

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

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

A single front-loaded sentence states the resource, action, and all supported query forms with no filler. It is compact and easy for an agent to scan.

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 lookup tool with a simple two-parameter schema and clear annotations, the description conveys the query scope needed for correct invocation. The summary/full payload difference is left unspecified, but that does not prevent an agent from selecting or calling the tool 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 roughly 50%: the query parameter has a description, while detail has only an enum and default. The description repeats much of the query schema content but adds 'alias' and 'wcag:' prefix semantics; it does not clarify the difference between summary and full.

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 ('조회한다'), names the resource ('KWCAG 2.2 검사항목'), and enumerates the query dimensions (official ID/alias, WCAG SC, axe rule ID, keyword). It does not explicitly differentiate from sibling tools such as get_checklist, so some sibling distinction is left to inference.

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

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

The description implies the look-up use case: call this when you need KWCAG items by ID, WCAG SC, axe rule, or keyword. However, it gives no explicit when-to-use or when-not-to-use guidance, nor alternatives, so an agent must infer how it relates to siblings.

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