mcp-toolbelt

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

With no annotations, the description carries the burden of disclosure. It makes the read-only nature clear via 'Check' and specifies exactly what is inspected: robots.txt directives for a named set of AI crawlers and the presence of llms.txt. It does not discuss rate limits or errors, but nothing about the behavior is hidden or misleading.

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 two sentences with no filler: the first front-loads what is checked, and the second explains who benefits. The crawler-name list is long but earned, because it removes ambiguity about which bots are in scope.

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, low-complexity tool, the description covers the target resource, the exact crawlers of interest, and llms.txt; the schema covers the input contract. It could mention the response shape or behavior when robots.txt is absent, but those are minor gaps for a check-style tool with no output 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?

The single parameter is already fully described in the schema with coverage at 100%, including the fact that any URL on the site works and the origin is derived. The description reinforces this by talking about 'a site's robots.txt', but it adds no new parameter semantics beyond what the schema provides, so it stays at the 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 opens with a specific verb and resource: 'Check a site's robots.txt for explicit directives targeting known AI crawlers', then adds llms.txt as a second target. It also enumerates the exact crawler names and differentiates itself from generic siblings like check_robots_sitemap by scoping to AI crawler policy.

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, concrete use cases: publishers checking whether their AI-crawler content policy matches intent, and auditing a competitor's stance. It does not explicitly mention alternatives or say when not to use this tool, so it misses the highest bar for routing an agent away from siblings like check_robots_sitemap.

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 key behaviors: same-origin only, bounded by maxPages, checks every linked URL, and notes false positives from external sites that block automated requests. However, it does not mention redirect handling, timeouts, or confirm read-only status. It is adequate but not comprehensive.

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 two sentences plus a useful note, with no filler. The core action and scope are front-loaded, and the caveat about external sites is valuable. Every sentence 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?

The description covers purpose, scope, return value (broken links with pages), and a key limitation. Without an output schema, it could be more explicit about the response format, but the described output is sufficient for an agent to understand what to expect. It is complete enough for its complexity.

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

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

Schema coverage is 100%, so parameters are well documented. The description adds context about the crawl scope (same-origin, bounded) and the external-site false-positive note, reinforcing maxPages and url meaning. It does not repeat schema details, but the added value is marginal beyond 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 the action (crawl and check) and the resource (linked URLs on a site), with specific scope (same-origin, bounded by maxPages) and returns broken links with pages. It distinguishes itself from siblings like sitemap_url_validator and domain_health_check by focusing on broken link detection through crawling.

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 context: it crawls a site from a starting URL and checks linked URLs for broken status codes. It does not explicitly mention alternatives or exclusions, but its specificity makes the appropriate use case (finding broken links across a site) obvious. It lacks explicit 'use instead of' guidance, so a 4 is appropriate.

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 behavioral burden. It discloses that this is an active TCP-connect scan, that it defaults to a curated ~20-port common-services list, and that each call is capped at 100 ports. This is meaningful context beyond the bare 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?

Three short sentences front-load the core action and then give defaults, intended scope, and the call limit. There is no filler and every sentence 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 two-parameter tool with full schema coverage, the description covers purpose, defaults, and limits. The only notable gap is the lack of an output schema and no explicit statement about the response shape, though 'scan for open ports' adequately implies the result.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful color by naming common port categories, but the parameter meanings are already fully documented in 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?

States an exact operation — 'TCP-connect scan a host for open ports' — with a clear resource and method. It is immediately distinguishable from sibling checks like ssl_cert_check or security_headers_audit.

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?

Provides a clear use context: checking your own infrastructure's exposure, plus default behavior when ports are omitted. It does not explicitly list exclusions or alternatives, but the tool's niche is distinct enough among the siblings and the 100-port cap conveys practical constraints.

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 disclosure burden. It usefully reveals that results are read-only and that raw contents are returned truncated, but it does not explain validity criteria, truncation limits, or failure behavior for missing files.

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 sentence front-loads the action, scope, and return behavior with no filler. Every phrase adds 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?

The tool is low-complexity with one well-documented parameter, and the description covers what the call returns. Some detail is missing around truncation length and output shape, but nothing essential prevents an agent from invoking 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 coverage is 100% and the one parameter is already described ('Any URL on the site to check (origin is derived from it)'). The description adds no parameter-level detail, so the baseline score 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?

The description names a specific verb ('Check'), a concrete resource ('robots.txt and sitemap.xml'), and an output behavior ('return their raw contents (truncated)'). This is enough to distinguish it from siblings like sitemap_url_validator, which focus on URL validation rather than presence/content 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?

No explicit guidance about when to prefer this tool over alternatives such as sitemap_url_validator or ai_crawler_policy_check. The only usage cue is implied by the description, so the agent receives no exclusionary or selection criteria.

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 explicitly discloses that the tool sends an active probe request with a foreign Origin header and inspects response headers, which is the key behavioral trait. It does not mention request method, exact origin value, or whether credentials are included, but the disclosed behavior is sufficient for a focused scanner of this kind.

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 with no filler. The action is front-loaded, the resource is named, and the detection targets are given in a compact but informative second sentence. 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 one-parameter tool with no output schema, the description covers what it does, how it does it, and what it flags. It does not detail the exact return format, but the phrase 'report its CORS response headers' and 'flags' gives enough context for an agent to select and invoke 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?

The input schema has 100% coverage for the single 'url' parameter, so the baseline is 3. The description adds context about why the URL is being probed, but it does not add meaning to the parameter itself beyond the schema's 'The URL to probe'.

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 ('Send a probe request with a foreign Origin header to a URL'), a clear resource ('CORS response headers'), and specific detection outcomes ('wildcard-origin + credentials combinations' and 'arbitrary-origin reflection'). This clearly differentiates it from sibling security tools like security_headers_audit or ai_crawler_policy_check.

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 makes the intended usage context clear: it is for probing a URL's CORS behavior and detecting common misconfigurations. It does not explicitly name alternatives or say when not to use it, but the specialized wording provides enough context without being misleading.

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 provided, the description carries the behavioral disclosure burden. It transparently explains the parallel-resolver behavior, the comparison logic, and the meaning of flagged mismatches. It does not mention potential limitations like resolver caching or timeouts, but the core behavior and interpretation are clearly disclosed.

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 first describes the mechanism, the second explains the interpretation. Every piece of information earns its place, and the core purpose 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?

The tool is simple with only two well-documented parameters, and the description covers both the query behavior and the meaning of results. With no output schema, it hints at the return behavior ('flags mismatches') but does not detail the exact response structure, making it complete enough for invocation but slightly short on output granularity.

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

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

Schema coverage is 100%, so the schema already documents both 'domain' and 'recordType'. The description adds useful context about why those parameters matter (comparison across multiple resolvers), but it does not add detail about accepted values, defaults, or edge cases beyond what the schema provides. 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?

The description states a specific action ('Query a DNS record'), the exact resource (a domain's DNS record), the method (against major public resolvers in parallel), and the goal (compare answers and flag mismatches). This clearly differentiates it from neighboring health-check tools like domain_health_check or ssl_cert_check.

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 second sentence provides clear context for when to use the tool: after a DNS change, mismatches usually indicate propagation is still in progress. It does not explicitly name alternative tools or state when not to use it, but it gives enough situational guidance for an agent to select it appropriately.

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 provided, the description carries the full burden. It discloses the WHOIS-based method, the scope (popular TLDs, typo-squat variants), and the 40-variant cap to manage latency. This is transparent about what the tool does and its limitations, though it doesn't mention any potential side effects or that it is read-only (which is implied).

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 two sentences, front-loaded with the primary purpose, and includes the cap and TLD list efficiently. There is no fluff; every clause adds useful information 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 has no output schema, so the description must cover the main functional aspects. It explains what is checked, the variants, the TLDs, and the latency cap. It does not describe the return format, but for a tool of this type, the description is sufficiently complete for an agent to invoke it correctly without ambiguity.

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% (both parameters documented). The description adds value by clarifying the checkSquats behavior with concrete examples (adjacent-key substitution, etc.) and the list of TLDs, which enriches understanding of what the tool will scan. This exceeds the baseline and helps the agent set parameters correctly.

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 ('Check whether') and resource ('a domain is registered') plus an additional action ('scan common typo-squat variants'). It lists the specific TLDs and variant types, making it clearly distinct from sibling tools like domain_health_check or domain_report, which focus on other aspects.

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 usage context: 'for brand-protection or domain-flipping research'. It also discloses the WHOIS-based nature and the 40-variant cap, which helps an agent decide if this tool fits the task. However, it does not explicitly name alternatives or state when to prefer another tool, though the context is sufficient for typical selection.

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?

There are no annotations, so the description carries the full burden. It discloses the method ('via WHOIS'), the checked record types, and the outcome ('flags common misconfigurations'), which is sufficient behavioral transparency for a read-only diagnostic tool. It does not describe edge cases like invalid domains, but the core behavior is not hidden.

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 that lists the exact checks and ends with the value-add ('flags common misconfigurations'). There is no redundant or filler wording.

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 one well-documented parameter, no annotations, and no output schema, the description is almost complete: an agent knows exactly what is checked and that misconfigurations are flagged. It does not detail return shape or failure modes, which would strengthen it, but the core information needed to invoke the tool is present.

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 documents the only parameter well: 'Bare domain to check, e.g. example.com (no scheme/path)' with 100% coverage. The description adds no additional parameter-specific meaning, so the baseline score 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?

The description names a specific verb ('Check'), resource ('a domain'), and the exact scope: registration expiry via WHOIS plus DNS records such as nameservers, A/AAAA, MX, SPF, and DMARC. This distinguishes it from sibling tools like domain_availability_check or dns_propagation_check because it clearly covers health-and-misconfiguration checking rather than availability or propagation alone.

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 makes the use case clear: use it to check domain registration expiry, DNS record setup, and common misconfigurations. It does not explicitly name alternative tools or state when not to use it, but the scope is specific enough for an agent to select it appropriately.

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 behavioral burden and does it well: it discloses the one-charge batching, the independent reporting of sub-checks, and that a failure in one area does not invalidate the others. It does not cover output shape or potential rate/quota side effects, but the disclosed traits are material.

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

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

Three sentences, each earn their place: bundle composition, cost/usage advantage, and failure isolation. The word 'Bundle' is front-loaded and prevents mistaking it for a standalone check.

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 composite tool, the description covers what is bundled, why to use it, and how sub-results behave. It lacks an explicit note on the returned report structure, which would fully compensate for the absent output schema, but this is a minor gap.

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

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

Schema coverage is 100%, with the schema already specifying a bare domain without scheme/path. The description only says 'against a domain,' adding no meaning 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?

Description names the exact verb/function — a bundle running seo_audit, domain_health_check, and email_deliverability_check against a domain — and thereby distinguishes itself from those standalone siblings. It also clarifies it is a composite call rather than a new check.

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?

States a concrete reason to choose the bundle over the alternatives: one call/one charge and cheaper than running the three tools separately. It does not explicitly state when to avoid the bundle and use a single tool instead, so it stops short of 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the tool's behavior well: it performs four named checks, including a network-dependent MX lookup and role-account detection. It does not describe the return format or error behavior, but for a read-only validation tool the disclosed operation list is substantial.

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 two sentences and every clause earns its place: the first lists all validation checks, and the second explicitly routes the agent away from the domain-audit sibling. The information is front-loaded and densely packed 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?

For a single-parameter tool, the description is complete: it states the input, the exact operations, and the key sibling distinction. A minor gap is the absence of return-format information since there is no output schema, but the behavior is specific enough that an agent can infer the nature of the result. Overall, no critical selection or invocation context 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 100%, and the single parameter (email) is fully documented in the schema as 'Email address to validate'. The description reinforces that this is a single-address check but adds no new format or constraint details beyond the schema. A baseline score of 3 is appropriate because the schema already carries the parameter semantics.

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 ('Validate') and clearly identifies the resource ('a single email address'). It then enumerates the exact checks performed (RFC syntax, MX lookup, disposable/role detection), leaving no ambiguity about what the tool does. It also explicitly contrasts itself with email_deliverability_check, making sibling differentiation immediate.

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 states this is a per-address check and names the alternative for domain-level reputation auditing: 'different from email_deliverability_check, which audits a whole domain's sending reputation...' This gives an agent a clear rule for selecting this tool instead of a sibling. The guidance is explicit enough to avoid misuse.

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 present, so the description carries the full disclosure burden. It adds a valuable non-obvious behavioral caveat: DNSBL lookups via public resolvers are often rate-limited, so a null `listed` result means 'unknown', not 'clean'. This goes beyond the obvious read-only implication of 'check'.

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, with the scope list front-loaded and the caveat kept as a separate note. Every element earns its place, though the comma-separated enumeration is dense.

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?

All functional areas of the check and the most confusing result interpretation are covered. It stops short of describing the overall output shape, but the mention of a `listed: null` field offers a partial view of the return.

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 only parameter, `domain`, is already fully documented in the schema with a 'Bare domain' example, and the description adds no new constraints or formatting details. Baseline 3 for high schema coverage 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?

Describes a specific resource ('a domain') with a precise verb ('Deep-dive ... check') and enumerates the exact tests performed (MX, PTR, DKIM, SPF, DMARC, DNSBL). The detail clearly differentiates it from siblings like email_address_validate or dns_propagation_check.

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?

While it frames the tool as 'deep-dive', it does not explicitly say when to choose this over alternatives like domain_health_check or email_address_validate, nor does it state exclusions. Usage must be inferred from the scope of checks.

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 provided, the description carries the full burden. It discloses that the check only tests 'presence' of items, not validity, and that it is a 'quick' check. It does not reveal operational details such as how the URL is fetched, whether JavaScript-rendered content is considered, or what the return payload looks like; this is a moderate gap for a tool with 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?

The description is a single 22-word sentence with no filler. It front-loads the action ('Check a site for...') and the object list, and the context clause 'quick completeness check' adds useful scope 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?

For a simple one-parameter check tool, the description sufficiently explains what is checked and implies a quick read-only audit. Non-obvious details such as output format are absent, but the schema fully documents the input and the tool's scope is narrow, so an agent can select and invoke it correctly with minimal ambiguity.

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 only parameter, url, is fully described in the schema as 'Any URL on the site to check (origin is derived from it),' so schema coverage is 100%. The tool description does not add further parameter-level meaning, but it is unnecessary given the schema's clarity.

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 action ('Check') and enumerates the exact resources examined (favicon, apple-touch-icon, web app manifest, theme-color). This distinguishes it from siblings like seo_audit or page_performance_check by targeting PWA/browser chrome metadata. The phrase 'quick completeness check' further clarifies it is a focused, non-exhaustive scan.

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 text implies a use case — checking PWA/browser metadata completeness — via 'quick completeness check for browser/OS chrome and PWA metadata.' However, it does not explicitly state when to prefer this tool over alternatives (e.g., seo_audit or page_performance_check) or provide when-not-to-use conditions. The intended context is clear but not formally contrasted with sibling tools.

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 provided, the description carries the full burden of behavioral disclosure. It discloses the checks performed and the flagging behavior for abandoned/unlicensed repos, but does not mention rate limits, authentication needs, or return format. It adds some behavioral context beyond the schema but lacks comprehensive disclosure.

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 entire description is a single sentence that front-loads the action, lists the health signals, and ends with usage guidance. There is no redundant wording, and the structure is efficient.

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 two-parameter tool with no annotations and no output schema, the description covers the purpose, the data checked, and the intended usage. It could be more explicit about the return format, but the 'flags' behavior implies a report, and the description is sufficient for correct invocation.

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%, with both 'owner' and 'repo' described in the input schema. The description does not add parameter-specific details beyond the schema, so the baseline 3 is appropriate—the schema already 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 specific verb ('Check') and resource ('GitHub repository's health signals'), then enumerates the exact signals checked. It clearly distinguishes itself from sibling tools, which target URLs, domains, SSL, and web content, by being GitHub-specific.

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 clear usage context with 'Useful before depending on a repo,' which tells the agent when to apply this tool. It does not explicitly name alternatives or exclusion criteria, but the sibling set makes it obvious this is the GitHub-specific health check, so guidance is adequate though not fully 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?

With no annotations, the description carries the full burden of behavioral disclosure. It usefully adds the data source (Team Cymru), the DNS-based mechanism, and the no-API-key requirement. It does not mention failure behavior, rate limits, or that this is a read-only operation, but for a simple lookup tool the disclosed behavior is reasonably adequate.

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 with no filler. The first sentence front-loads the main purpose and data returned, and the second sentence adds a crucial scope limitation and the no-API-key detail. Every word 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-parameter lookup tool, the description covers the input type, the resolution behavior, the returned data fields, the service used, and the country-level limitation. No output schema exists, but the enumerated return fields give the agent enough context. Minor gaps like explicit failure handling or output formatting do not materially impair correct invocation.

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 fully describes the single 'host' parameter as 'Hostname or bare IPv4 address to look up' (100% coverage). The description restates this concept and adds that the hostname is resolved to IPv4 addresses, but it does not add meaningful new parameter semantics 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?

The description names a specific action ('Resolve a hostname to its IPv4 addresses'), the data source (Team Cymru's DNS-based WHOIS), and the exact fields returned (ASN, network prefix, country code, network owner). It also distinguishes itself from generic geolocation by stating 'Country-level only', which separates it from any city/street lookup 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?

The description clearly implies when this tool is appropriate: for hostname-to-IP-ASN/country lookups. It gives an explicit exclusion ('not city/street geolocation') and notes the no-API-key advantage. It does not name a specific sibling alternative, but the sibling list contains no other geolocation tool, so the context is clear.

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 key behaviors: fetching every JSON-LD block, validating specific structural requirements, and reporting per-block errors instead of failing the whole call. It does not mention edge cases like no JSON-LD found or network failures, but covers the core behavior well.

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 information-dense sentence with no filler. It front-loads the primary action, then adds validation specifics and error-behavior nuance 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?

For a one-parameter validator with no output schema, the description adequately covers input, extraction, validation targets, and error reporting. The exact return structure isn't spelled out, but 'Reports per-block errors' conveys the output shape sufficiently.

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 only parameter, 'url', has full schema description coverage ('The URL to check'). The tool description adds little beyond 'Fetch a URL', so it doesn't meaningfully augment the schema. 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 clearly identifies the resource (URL), the action (fetch, extract, validate), and the validation scope (@context/@type plus required fields for specific schema.org types). It distinguishes itself from the sibling 'structured_data_extract' by its validate focus, though it doesn't name that 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?

The description implies this tool is for validating JSON-LD structure on a URL, but it gives no explicit when-to-use guidance or comparison with alternatives. The per-block error handling is a behavioral cue rather than a usage guideline.

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 burden of disclosing behavior. It communicates a read-only external lookup against OSV.dev and lists aggregated sources and supported ecosystems, which is enough to infer non-mutating behavior. It does not mention rate limits or failure behavior, but these are lower risk for a simple advisory lookup.

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 focused sentences with no filler. The main purpose is front-loaded, the source list is compact and useful, and the use-case sentence adds practical 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?

For a straightforward lookup, the description covers the data source, supported ecosystems, version semantics, and intended use case. There is no output schema, and return structure is not detailed, but 'known CVEs/advisories' gives an agent enough expectation about the result.

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 name, version, and ecosystem. The description reinforces that a version is optional/pinned and lists ecosystems, but it does not add meaning materially beyond 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 identifies a specific verb ('Look up'), a specific resource (a package against OSV.dev's aggregated vulnerability database), and the outcome (known CVEs/advisories). This clearly distinguishes it from siblings like safe_browsing_check or security_headers_audit, which focus on different security concerns.

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 concrete usage context with 'Useful before adding a dependency,' making it clear when an agent should consider this tool. It does not explicitly name alternatives or state when not to use it, but no sibling appears to be a direct package-vulnerability alternative.

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 is the sole behavioral disclosure. It clearly states that the tool issues a fetch to the target URL and produces diagnostic flags about compression, Cache-Control, payload size, and TTFB, which is meaningful beyond the schema. It does not cover edge behaviors such as redirects or timeouts, but the core operation is transparent.

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 two tight clauses that front-load the action and then list the diagnostic checks, with no filler or repetition. Every phrase carries 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?

For a one-parameter, low-complexity tool, the description covers input, measured outputs, and flag categories. It omits concrete thresholds such as what counts as 'slow TTFB' or 'oversized', but an agent can still select and invoke it 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?

The schema already documents the single url parameter at 100% coverage. The description reinforces that the URL is what gets measured but adds no new parameter-level details, so the baseline score 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?

The description names a concrete verb ('Fetch'), a resource ('a URL'), and the exact measurements/findings (TTFB, total fetch time, response size, compression/Cache-Control flags). These specifics distinguish it from browser-oriented siblings such as pagespeed_insights without needing to open 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 description implies the tool is for low-level HTTP performance triage by listing what it flags, but it never names alternatives or explains when not to use it. An agent must infer the use case from the metric names rather than receive explicit routing 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?

With no annotations, the description carries the burden, and it does disclose meaningful behavior: it makes an external call to Google, works without an API key at low volume, and requires a server-side key for higher throughput. It also caveats that field data is included only 'where available.' It does not discuss error behavior or side-effect safety explicitly, but the read-only nature is implied by the described read 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?

Three sentences, front-loaded with the core purpose and outputs, followed by the authoritative positioning and auth/rate guidance. Every sentence adds value and none duplicate schema fields.

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 two-parameter read-only tool with no output schema, the description covers what it returns, the external dependency, key/rate behavior, and field-data caveat. It lacks explicit error/failure semantics, but an agent has enough to select and invoke it 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%, so the baseline applies. The description mentions a URL and field data but adds no parameter-level meaning beyond the schema, and it does not elaborate on strategy defaults or constraints.

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 opens with a specific action and resource: running Google's PageSpeed Insights (Lighthouse + CrUX) against a URL, and it lists concrete outputs (performance score, Core Web Vitals, field data). It also distinguishes itself as the authoritative counterpart to a local timing check, which helps separate it from nearby performance 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?

It communicates when to prefer this tool ('Authoritative version of a local timing check — hits Google's own infrastructure') and gives operational guidance about API-key requirements and throughput. It stops short of naming explicit alternatives or when-not-to-use conditions, so it is clear but not fully exclusionary.

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 zero annotations, the description carries the full burden of behavioral disclosure. While it does reveal what the tool detects (loops, hop limits, HTTPS downgrades), it doesn't disclose whether the request is actually performed (potential side effects, though likely just a GET), whether rate limits apply, what the output structure looks like, or how it reports issues. Since it performs a network request to an arbitrary user-supplied URL, this missing context is a notable gap.

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 well-crafted sentence that front-loads the verb and resource, then efficiently enumerates the four key output categories without waste. The structure is pristine — every clause adds meaningful 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?

The description covers what the tool does and what it reports, which is adequate for simple invocation. However, missing details such as whether it follows redirects client-side, whether it respects robots.txt, what constitutes 'too many hops' (configurable default?), and the output format would improve completeness. For a diagnostic tool with no output schema, the return format is genuinely undisclosed, and there's no way to know what the agent will receive back.

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% with a single 'url' parameter described as 'The starting URL to trace', which aligns perfectly with the description's 'Follow a URL through every HTTP redirect hop'. The description and schema reinforce each other without contradiction, and at 100% schema coverage the baseline of 3 is appropriate. No additional parameter-level detail is needed.

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 ('Follow') with a clear resource ('URL through every HTTP redirect hop') followed by a precise list of outputs (full chain, final destination, loops, too many hops, HTTPS-to-HTTP downgrades). This clearly distinguishes it from siblings like broken_link_check and sitemap_url_validator, which have different purposes.

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 makes the use case evident: when you need to trace redirect behavior of a URL. However, it doesn't explicitly state when NOT to use it or name alternatives for near-overlapping tasks like broken_link_check (which may also encounter redirects) or url_to_markdown. The use case is clear but no exclusion criteria are given.

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?

There are no annotations, so the description carries the behavioral burden. It usefully discloses that an API key must be configured server-side and lists the blocklist categories. But it does not disclose what the tool returns (e.g., boolean, matched category), how it fails if the key is missing, or any rate-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?

The description is two sentences with no superfluous content. The core purpose is front-loaded, and the operational prerequisite is provided in the second sentence 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?

With no output schema and no annotations, the description does not explain the return value or failure semantics, which an agent would need to correctly use the result. It covers the API requirement adequately, but the missing return-format information creates a notable 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% for the single `url` parameter, and the description adds no additional meaning beyond 'The URL to check' already in the schema. The baseline of 3 applies because the schema already documents the parameter.

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 ('Check') and a precise resource ('a URL against Google Safe Browsing's malware/phishing/unwanted-software/PUA blocklists'). This clearly differentiates the tool from siblings like ssl_cert_check or security_headers_audit without needing to open 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 description implies the tool is used when you need to determine whether a URL is listed on Google Safe Browsing blocklists. However, it does not explicitly state when to use it versus alternatives like package_vulnerability_check or domain_health_check, and provides no 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 carries the burden of disclosing behavior. It does reveal that the tool makes a network fetch and returns a score, which is helpful, but it does not explain the score range, what constitutes 'misconfigured', redirect behavior, or failure handling for 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?

One sentence delivers the action, the target, the specific headers audited, and the output format. No filler or redundant wording; 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 one-parameter read-only audit tool, the description covers the essential invocation details: the URL to pass, the audit behavior, and the score plus flags as output. It could be richer by describing the score scale or failure cases, but the absence of an output schema does not leave the agent without a workable mental model.

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 fully documents the single 'url' parameter with 100% coverage. The description adds only that the URL is fetched for header audit, without extra format or constraint details, so it does not significantly enhance the schema's own description.

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 ('Fetch') and resource ('URL response') and precisely names the audit domain: security-relevant HTTP headers. It lists the exact headers checked and the outcome (a score with flags for missing/misconfigured values), which clearly differentiates it from broader audit siblings like seo_audit.

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 described behavior makes the intended use case clear: audit a URL's security headers. It does not explicitly name alternative tools or state when not to use it, but the focus on security headers provides enough context to distinguish it from the many sibling audit tools.

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 communicates a read-only network fetch and a list of checks, making the core behavior visible. With no annotations provided, however, it does not disclose behaviors like whether JavaScript is executed, how redirects are handled, or how unreachable URLs are surfaced.

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 dense sentence with the main action front-loaded and every listed item carrying substantive meaning. It could be organized as bullet points for easier scanning, but there is no fluff or redundant wording.

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 tool, the description thoroughly explains what is audited, which is enough for basic invocation. Yet without an output schema, it never states the return shape—score, report, boolean flags, or errors—leaving an important gap for agents that need to interpret the result.

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?

There is only one parameter, url, and the schema already describes it as 'The URL to audit' with 100% coverage. The description reinforces that the URL is fetched but adds no extra guidance on format, protocols, or URL normalization.

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 opens with a specific verb and resource—'Fetch a URL and run an SEO audit'—and then enumerates a precise checklist of audit dimensions. This immediately distinguishes it from more narrowly-scoped sibling tools like json_ld_schema_validator, check_robots_sitemap, or structured_data_extract.

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 intended use is implied clearly: use this when you want a broad SEO audit of a URL. However, there is no explicit when-not-to-use guidance or comparison to specialized siblings, so an agent is left to infer when a smaller tool would be preferable.

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 meaningful non-obvious behavior: following one level of sitemap-index nesting, concurrency limiting, a per-call cap of 200 URLs, and reporting broken/redirecting URLs. This gives an agent a solid behavioral model, though it stops short of defining which HTTP statuses count as broken or redirecting.

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, each earning its place: the operation, the key constraints, and the output. It is front-loaded and free of 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?

For a tool with one required parameter, no annotations, and no output schema, this description covers input, behavior, limits, and high-level output. A little more detail about what 'reports' means structurally — e.g., whether truncation at the cap is indicated — would make it 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 coverage is 100%, including the notable fallback behavior that any page URL resolves to /sitemap.xml on that origin. The description reinforces the sitemap target but adds no parameter semantics beyond what the schema already 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 states a specific action ('Parse... check the HTTP status'), a specific resource (a site's sitemap.xml), and the scope ('every listed URL'). It clearly distinguishes this from sibling tools like broken_link_check or check_robots_sitemap by focusing on sitemap-declared URLs rather than on-page links or sitemap discovery.

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?

Clear context is provided: use this when validating URLs found in a sitemap, with explicit behavioral constraints such as one level of index nesting and a 200-URL cap. However, it does not explicitly say when not to use it or name a preferred alternative among the many sibling tools.

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 provided, the description carries the full burden. It discloses the core behavior (connecting over TLS and reporting specific certificate fields) and clearly indicates a read-only action via 'report'. It does not mention error handling or network assumptions, but the described behavior is accurate and transparent enough for a simple check 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, efficient sentence that front-loads the action ('Connect to a host over TLS') and then lists the output fields with no filler or redundant wording. Every word 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?

There is no output schema, but the description enumerates the key returned certificate details (expiry date, days remaining, issuer, subject), making the tool's purpose and expected output clear. It omits potential error states or details like port defaults, but the schema covers the port and the core invocation is fully understandable.

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%: both hostname and port have explanatory descriptions in the schema. The tool description itself does not add further parameter semantics, but with full schema coverage 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?

The description uses a specific verb ('Connect') with a clear resource (TLS certificate) and clearly states what it reports: expiry date, days remaining, issuer, and subject. It does not explicitly distinguish itself from the sibling tool ssl_labs_grade, which may perform a related but different check, hence not a 5.

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 is implied through the description: it is for checking SSL certificate details over TLS. However, there is no explicit guidance on when to use this tool versus alternatives like ssl_labs_grade or check_open_ports, and no exclusions or prerequisites are mentioned.

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 provided, the description carries the full burden. It discloses that the tool is slower (up to ~90s) and that results are cached for 24h, which are important behavioral traits. It also specifies what it assesses. While it doesn't mention possible failure modes or rate limits, it goes well beyond a minimal description and is transparent about timing and caching.

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 with no filler: the first states the purpose and scope, the second provides timing and comparison to the sibling tool. Front-loaded, efficient, and every word contributes to decision-making.

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 tool with no output schema, the description covers the essential context: what it does, how long it takes, and how it differs from the sibling. It doesn't describe the output structure, but that's not required without an output schema. The missing piece is any error handling or edge cases, but overall it is complete enough for an agent to invoke 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?

The input schema already describes the only parameter (hostname) with a clear format and example ('no scheme/path'). The description adds no additional semantic information about the parameter itself, so it stays at the baseline of 3 given the high schema coverage.

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 it is a 'Full SSL Labs-style TLS assessment' and enumerates specific aspects (overall grade, protocol support, cipher strength, certificate chain issues, known vulnerabilities). It also explicitly contrasts with the sibling tool ssl_cert_check, making the purpose distinct and 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?

Provides explicit comparison to ssl_cert_check by noting it is slower, implying it should be chosen when a comprehensive assessment is needed rather than a quick check. It also mentions the caching behavior (24h server-side) which helps set expectations. This gives clear guidance on when to use this tool vs alternatives.

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 behavioral burden and does well: it discloses determinism, pure HTML parsing via CSS selectors, no LLM involvement, and exact-match output. It stops short of documenting failure, redirect, or rate-limit behavior, but for a fetch-and-parse tool the disclosed traits are substantive and accurate.

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 with no filler: the purpose, output categories, selector example, and the no-LLM/exact-match distinction all fit compactly. Information is front-loaded and 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?

There is no output schema, but the description names the output categories (JSON-LD, OpenGraph/meta, selector fields) and the exact-match contract, which is enough for an agent to know what it will receive. Minor gaps are the lack of explicit response shape and error semantics, but the tool is simple and the parameter schema is fully documented.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema with a concrete selector-map example and clarifies the deterministic exact-match semantics underlying the selector parameters. The schema already handles individual property semantics, so the description's framing and example justify moving above 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?

Description states a specific verb and resource: 'Fetch a URL and extract structured data deterministically', enumerating exact output classes (JSON-LD blocks, OpenGraph/meta tags, caller-supplied CSS-selector fields). The 'no LLM involved' / 'exact matches only' phrase distinguishes it from extraction-style siblings and from URL-to-markdown or validator 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?

The description implies when to use the tool (when deterministic HTML extraction is needed) and sets a boundary ('exact matches only, not summarized or inferred'), but it never names a sibling alternative or states a clear when-not-to-use condition. An agent has to infer the use case from the capabilities rather than receiving explicit routing 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?

With no annotations, the description carries the full behavioral disclosure burden and does well: it specifies the data sources (headers, HTML markers), states it is best-effort and not exhaustive, and explicitly says no additional paths are probed. It does not cover redirects, timeouts, or output shape, but for a simple read-only fetch tool the disclosure is strong.

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 two sentences, front-loads the core action, then efficiently lists the fingerprinting sources and the key limitation. Every sentence adds value with no redundancy or 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 tool is simple (one parameter, no output schema) and the description covers the process, sources, and best-effort nature. It does not detail the exact return format or failure behavior, but the purpose and outcome are clear enough for a competent agent to invoke it 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?

The schema already documents the only parameter 'url' with 100% coverage, so the baseline applies. The description adds that the URL is fetched and used for fingerprinting, but does not add URL format requirements or edge-case semantics 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 ('Fetch') and resource ('a URL') and clearly defines the tool's purpose: fingerprinting a likely tech stack from response headers and HTML markers. This distinguishes it from sibling tools like security_headers_audit or url_to_markdown, which have different objectives.

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 explicit guidance on when to use this tool instead of a sibling, nor does it name alternative tools or exclusion criteria. The 'best-effort' caveat is a limitation, not a usage guideline, so an agent is left to infer when this tool is appropriate.

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 of behavioral disclosure. It does disclose that scripts, styles, and HTML tags are removed, which is useful. It does not mention redirects, JavaScript rendering, timeout/error behavior, or whether the output can be parsed as markdown vs plain text, leaving some important edge cases undisclosed.

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 with no filler. The first sentence front-loads the core action and expected output; the second adds a specific, valuable detail about content stripping. Every sentence contributes, and the structure is easy 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?

The tool has one required parameter, no annotations, and no output schema, so the description must cover the core contract. It states the input, the output format, and the transformation behavior. It lacks edge-case information such as failure handling and redirects, but for a simple fetch-and-extract tool this is sufficient for an agent to call it 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% — the url parameter is already described as 'The URL to fetch.' The description's 'Fetch a URL' phrase echoes the schema without adding new meaning. With full schema coverage, a baseline of 3 is appropriate; the description does not compensate with extra parameter details.

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 a specific action (fetch), a specific resource (URL), and the precise output (main text content as plain text/markdown). It also notes the stripping of scripts, styles, and HTML tags. Among the many sibling diagnostic tools, this is the only one focused on content extraction, so it is easy to distinguish.

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: whenever an agent needs the readable text content of a webpage. However, it provides no explicit alternatives, exclusions, or conditions such as 'use this when you need page text' or 'not for checking site health.' The context is clear enough but left entirely to inference.

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

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

With no annotations available, the description carries the burden of disclosure. It clearly states that the tool attempts the handshake and reports success/failure, time-to-open, and close code/reason. It does not cover timeout or error edge cases, but for a simple connectivity probe the main behavior is transparent.

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 with no fluff. The first sentence front-loads the action and output fields; the second sentence provides the use-case context. Every clause contributes 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?

For a one-parameter tool with no output schema, the description names the observable results and the intended pre-traffic use case. It does not detail exact response formatting or timeout configuration, but those are minor at this simplicity level.

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 covers the single parameter with a description and example, giving 100% coverage. The description adds only the explicit ws:// and wss:// scheme mention, which is minor; 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?

The description opens with a specific verb and resource ('Test a WebSocket endpoint'), names the supported schemes (ws://, wss://), and enumerates the exact outputs (success/failure, time-to-open, close code/reason). None of the 28 sibling tools mention WebSocket, so it is clearly differentiated.

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 a concrete trigger and context ('before you wire real traffic to it') and the verification goal ('server is reachable and completes its upgrade handshake'). However, it stops short of naming alternatives or explicit when-not-to-use conditions, so it does not reach the full 5.

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