mcp-toolbelt

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

No annotations are provided, so the description carries the burden: it discloses the full scope of the audit (robots.txt, AI-crawler policy, llms.txt, JSON-LD/OG, /.well-known/x402, /openapi.json, sitemap, meta) and the scoring semantics (0-100 plus letter grade). 'Audit'/'score' makes the read-only nature clear, but it omits operational traits such as whether it is idempotent, rate-limited, or requires auth, and no return structure is described.

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?

Front-loaded with the core promise (score 0-100 + grade) before the long enumeration, and the alternatives sentence is last where it belongs. The component list is dense but each item earns its place by defining audit scope; the only cost is a slightly run-on single sentence.

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-URL read-only audit with no output schema, the description supplies what an agent needs: the scale, the graded output, the checked signals, and the sibling alternatives. Minor gap is the absence of any note on response shape beyond the numeric score and letter grade.

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

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

With one parameter at 100% schema description coverage ('Any URL on the site to audit (origin is derived from it)'), the schema already does the heavy lifting. The description adds no further parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb (Score) plus resource (AI readiness of a website) and defines the output shape ('0-100 with a letter grade'), then enumerates the exact signals evaluated. It explicitly distinguishes itself from check_robots_sitemap and seo_audit, so an agent can pick it apart from siblings without opening any schema.

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

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

Gives explicit when-to-use ('the bundle to run before/after making a site agent-friendly') and names two alternative tools with the conditions that select them (raw robots/sitemap contents, classic search SEO). This is the strongest possible 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?

No annotations are provided, so the description carries the full burden. It discloses same-origin crawling, maxPages bounds, one-level sitemap-index nesting, that crawling never follows off-site links, and that some external sites may produce false positives due to blocked automated requests. It does not mention timeouts or rate limits, but the behavioral disclosure 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 front-loaded with the core purpose, then explains the default mode, the sitemap mode, and a relevant false-positive caveat. Every sentence adds useful information with no filler.

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

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

With no annotations and no output schema, the description does a good job covering modes, scoping, and return behavior for crawl mode. Sitemap-mode return semantics are slightly less explicit, and runtime details like timeouts are omitted, but the definition is close to complete for an 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds useful mode context for url, maxPages, and viaSitemap, but does not add meaning for checkExternal beyond what the schema already states. Baseline 3 applies.

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

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

States a specific verb and resource: find broken links. It clearly describes two operating modes, crawl mode and sitemap mode, which lets an agent distinguish this from sibling tools like redirect_chain_check or check_robots_sitemap.

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?

Explains the default crawl mode and the sitemap mode trigger viaSitemap: true, giving clear context for when each mode applies. It does not explicitly compare against sibling tools or state when not to use this tool, but the mode selection guidance is strong.

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

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

With no annotations, the description carries the full burden. It usefully discloses the scan technique (TCP-connect, i.e. non-stealthy), the default common-ports behavior, the 100-port cap, and the Team Cymru enrichment source, but omits timing, rate limits, and what the returned results contain.

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 action and its enrichment, then defaults and the cap constraint. The em-dash aside is slightly dense but every clause earns its place; no filler.

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

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

For a two-parameter tool with no annotations and no output schema, the description covers action, enrichment, defaults, and limits well. It leaves return shape and scanning caveats implicit, which is a minor gap rather than a blocking one.

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

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

Schema description coverage is 100%, so both parameters are already documented, which sets a baseline of 3. The description only slightly enriches this by illustrating what 'common ports' means (SSH, HTTP/S, mail, DBs) and restating the 100-port cap; it adds no syntax or format detail 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?

States a specific verb and resource ('TCP-connect scan a host for open ports') and adds a second concrete deliverable (network intel: ASN, network owner, BGP prefix, country). No sibling performs port scanning, so the agent can differentiate it immediately from the surrounding security/network 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?

Provides clear context ('For checking your own infrastructure's exposure') that also implies authorization intent. It does not name when-not-to-use or an alternative, but with no sibling overlap on port scanning, the practical routing risk is low.

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 burden, and it does disclose a real trait beyond the name: content is returned truncated, and the crawler analysis distinguishes explicit named-bot rules from wildcard/default rules. It is silent on failure modes (unreachable origin, timeouts) and rate limits, which for an external-fetch tool leaves a modest 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?

Front-loaded with the core action in the first clause, and the routing hint is correctly placed last. The middle enumeration of AI crawler names is long but each item carries real informational value; the only cost is that it reads as one dense run-on sentence.

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

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

No output schema exists, so the description must describe returns, and it enumerates them thoroughly. With only one required parameter and no annotations, the remaining gaps are error/edge-case behavior and pagination or truncation limits beyond the word 'truncated'.

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's meaning ('any URL on the site, origin is derived from it') is already documented in the schema. The description adds no syntax, format, or edge-case guidance beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource pair (checks robots.txt and sitemap.xml) plus the exact deliverables: raw contents (truncated), sitemap presence, AI-crawler policy analysis, and llms.txt presence. It also explicitly separates itself from the sibling ai_readiness_audit, so an agent can distinguish the two without opening either schema.

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

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

The closing sentence names the alternative tool (ai_readiness_audit) and the exact condition that selects it (a scored, whole-site AI-readiness report). Combined with the enumeration of what this tool does cover, the agent knows both when to call it and when to route elsewhere.

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?

With no annotations, the description carries the burden, and it does disclose scope boundaries ("WHOIS + DNS only") and that it flags common misconfigurations. It does not mention rate limits, auth needs, or how failures are reported, but for a read-only audit tool the disclosed behavior is solid.

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 what is checked, then scope, then routing to alternatives. No filler; every clause carries information an agent needs for selection.

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

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

No output schema exists, but the enumeration of checked records (expiry, NS, A/AAAA, MX, SPF, DMARC) effectively communicates what comes back, and sibling routing covers the rest. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and the single 'domain' parameter is already documented with format guidance ("Bare domain ... no scheme/path"). The description adds no further parameter meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (check) and resource (a domain) plus the exact facets covered: WHOIS expiry, nameservers, A/AAAA, MX, SPF, DMARC. It explicitly distinguishes itself from three siblings, so an agent can select it without opening any other 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?

Names three alternatives with the precise condition that selects each: whois_lookup for the WHOIS record alone, email_deliverability_check for DKIM/DNSBL/PTR detail, and domain_report for everything plus SEO. When-to-use and when-not-to-use are both 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 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, the description carries the full behavioral burden and does so well: it states that only reachability metadata is returned, that file contents are never returned or stored, and that a random-path baseline mitigates SPA/catch-all false positives.

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 front-loaded with the core purpose and is generally efficient. The long enumeration of paths is useful for scope but makes the first sentence heavier than ideal.

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

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

Given one parameter, no annotations, and no output schema, the description is complete enough for an agent to invoke it correctly. It covers scope, return metadata, privacy behavior, false-positive handling, and intended use.

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 single url parameter is already documented as "Any URL on the site to probe (origin is derived from it)." The main description does not add further parameter semantics beyond what the schema provides, 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 states a specific verb and resource: probing a site for publicly exposed sensitive files. It lists the exact file classes checked and clearly distinguishes this from sibling security/audit 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 gives clear usage context ("For auditing your own sites' exposure"), which also implies an authorization boundary. However, it does not explicitly name when not to use it or point to alternatives among 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?

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 and does well: it discloses the operation sequence (handshake, info capture, tool listing, grading) and the output shape (0-100 score, letter grade, per-tool detail). It stops short of stating safety profile (read-only vs. mutating), timeout/network-failure behavior, or rate limits.

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?

Front-loaded with the verb and the enumerated operations, followed by the use case. Every clause earns its place; the grading-detail list is dense but directly informs the agent about scope and output.

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

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

No output schema and no annotations, yet the description specifies the returned artifacts (score, grade, per-tool detail) and the pipeline of steps, which is enough to call it correctly. It omits failure modes and latency expectations, a minor gap for a network probe.

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

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

Only one parameter and schema coverage is 100%, so the schema already documents 'url' fully with an example. The description's phrase 'remote MCP server' adds minor framing but no format or constraint detail beyond 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?

States a specific verb (probe) and resource (remote MCP server), then enumerates the exact steps — initialize handshake, server info, protocol version, tool listing, quality grading. Nothing else in the sibling set does anything similar, so an agent can distinguish it immediately.

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 says to use it 'to vet an MCP server before connecting an agent (or paying per call) to it,' giving a clear use context. It does not name a when-not condition or an alternative, though no close sibling alternative exists to route away to.

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 carries the full burden and does substantial work: it enumerates the measurements taken and the four failure conditions it flags (missing compression, missing Cache-Control, oversized payloads, slow TTFB), and notes the fetch originates "from this server," which matters for interpreting timing. It stops short of disclosing redirect handling, timeouts, or return shape, so it is strong but not exhaustive.

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

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

Two sentences, no padding. The primary purpose and metrics lead, and the disambiguation from the sibling tool closes. Each clause adds either scope or routing information.

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

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

No output schema and no annotations, so the description must define both behavior and expected results; it does reasonably well by listing the metrics and flags, which effectively previews the output. Gaps remain on redirect following, timeout behavior, and whether the fetch is authenticated, minor for a lightweight probe but not fully covered.

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

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

Schema description coverage is 100% and there is only a single required url parameter, so the schema already does the work (baseline 3). The description adds one genuinely useful semantic detail beyond the schema — that the measurement is performed from this server, not the caller's environment — which affects how the TTFB figure should be read.

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

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

"Fetch a URL and measure time-to-first-byte, total fetch time, and response size" names a concrete verb, resource, and the exact metrics produced. It further differentiates itself from the sibling pagespeed_insights by name, so an agent can route between the two without opening either schema.

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

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

Explicitly frames itself as a "lightweight raw-timing check" and states the alternative route: Lighthouse scores, Core Web Vitals, and real-user field data belong to pagespeed_insights. Both the when-to-use and the when-to-use-something-else conditions are present.

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 does disclose auth/rate-limit behavior ('works without an API key at low volume; set GOOGLE_PAGESPEED_API_KEY server-side for higher throughput'), which is real operational context. It stops short of describing latency, quota behavior, or failure modes for an external network call.

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 tight clauses, front-loaded with what the tool produces, then the sibling disambiguation, then the auth note. Every sentence earns its place and none repeats the schema.

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

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

For a read-only external measurement tool with no output schema, the description compensates by naming the return payload (scores, CWV, field data) and the credential requirement. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so 'url' and the 'strategy' enum (default mobile) are already fully documented. The description adds no syntax or format detail beyond the schema, which is the expected baseline when structured data does the heavy lifting.

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

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

States a specific verb and resource ('Run Google's real PageSpeed Insights ... against a URL') and enumerates the outputs (performance score, Core Web Vitals LCP/CLS/INP/TBT, field data). It explicitly distinguishes itself from the sibling page_performance_check, so an agent can route without opening either schema.

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

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

Names the alternative (page_performance_check) and the exact condition that selects it: 'for a quick raw TTFB/size timing check from this server use page_performance_check instead.' It also states the auth prerequisite and its throughput consequence, leaving nothing 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 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 full burden and does disclose meaningful behavior: the CORS probe actively sends a foreign Origin header and specifically flags wildcard-origin + credentials combinations and arbitrary-origin reflection. That is valuable non-obvious context. It still omits operational details like auth requirements, rate limits, and redirect handling, so it falls short of a 5.

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

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

The description is a single dense paragraph that front-loads the core action and check list before giving scope and alternatives. Every clause carries information, though the parenthetical enumeration of headers is somewhat long; it is efficient but not maximally tight.

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 audit tool with no output schema and no annotations, the description adequately covers what is checked, the active CORS probing behavior, and alternative routing. It gives a hint about return content ('with a score') without needing to detail the full response, leaving only minor operational gaps.

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

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

Schema coverage is 100% and the single 'url' parameter is already documented in the schema. The description implies what is fetched but adds no format details (scheme requirements, redirects, etc.) beyond what the schema provides, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('Fetch a URL and audit its response headers') and enumerates exactly what is checked: specific security headers plus a CORS policy probe. It explicitly distinguishes itself from siblings by routing server/TLS-level checks to ssl_cert_check or ssl_labs_grade, so an agent can select it without opening any schema.

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

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

It states the scope ('Header-level checks on a single response') and names the alternative tools with the condition that selects them ('for server/TLS-level checks use ssl_cert_check or ssl_labs_grade instead'). This is explicit when-to-use and when-to-use-something-else guidance, matching the strongest calibration example.

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 burden. The exhaustive scope list implies a read-only fetch-and-analyze operation, which is useful, but it says nothing about network dependency, latency/timeouts, rate limits, or failure modes on unreachable URLs. Adequate implied behavior, no disclosed operational traits.

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?

Front-loaded with the core verb+resource, then the audit checklist, then the sibling routing. The catalogue of checks is long, but each item is concrete and non-redundant, so it earns its place; slightly dense as a single block.

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 audit tool with no output schema or annotations, the description covers scope and alternatives well enough to invoke correctly. It does not describe the shape of the returned report, but the enumerated checks largely telegraph what comes 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?

One parameter with 100% schema description coverage, so the baseline is 3. The description adds no meaning beyond the schema — it doesn't clarify URL format expectations (scheme, redirects, non-HTML targets) even though 'fetch a URL' hints at network behavior.

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

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

Specific verb+resource (fetch a URL and run a full on-page SEO audit) followed by an explicit enumeration of what gets audited. It also distinguishes itself from the nearest siblings by naming structured_data_extract and tech_stack_fingerprint and stating the condition under which each is preferred.

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 the scope ('whole-page audit') and routes the agent away with named alternatives for two adjacent needs: raw extracted data → structured_data_extract, platform/framework → tech_stack_fingerprint. This is explicit when-to-use plus when-not-to-use 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 burden and does so thoroughly: it discloses the connection target and default port, the exact protocol handshake sequence, the STARTTLS upgrade behavior, what is reported back, and the crucial side-effect guarantee that 'no mail is sent and no relay attempt is made.' Nothing about the tool's behavior is left to inference.

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 core purpose is front-loaded in the first clause and the closing sentence delivers the highest-value fact (no mail sent, no relay). The long middle sentence packs the handshake sequence densely but every clause earns its place; only mild trimming is possible.

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

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

No output schema and no annotations exist, yet the description still tells the agent what comes back (banner, advertised capabilities such as STARTTLS/AUTH/SIZE/8BITMIME/PIPELINING, TLS protocol and certificate issuer/expiry). For a 2-param probe tool, that is complete.

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

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

Schema description coverage is 100%, so both parameters (host with MX fallback semantics, port with default 25) are already fully documented in the schema. The description only restates the port default ('port 25 (or a given port)') and adds no syntax or format detail beyond it. Baseline 3 applies when the schema does the heavy lifting.

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

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

Opens with a specific verb+resource ('Live-probe a mail server over SMTP') and then enumerates exactly what the probe does: banner read, EHLO, capability listing, STARTTLS upgrade, TLS/cert report. It is unmistakably distinct from siblings like check_open_ports or email_deliverability_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?

Explicitly positions itself as the server-side complement to email_deliverability_check, stating that the sibling 'reads DNS records only and never connects' — a clear routing rule. It stops short of stating exclusion cases (e.g., non-SMTP services should use check_open_ports instead), so it is strong but not exhaustive.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only network probe and discloses the returned fields, but says nothing about timeouts, failure/connection-error behavior, rate limits, or whether the check follows redirects or validates chains. For a simple connectivity check this is adequate but not rich.

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

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

Two tight sentences: the first states what it does and what it returns, the second carries the disambiguation. Nothing is padded 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?

With no output schema, the description correctly enumerates the return fields, and it routes the agent to the sibling for deeper analysis. Minor gaps remain around error/timeout behavior, but for a two-parameter read-only check the description is nearly complete.

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

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

Schema description coverage is 100%, so the schema already documents both hostname and port (with default 443). The description's 'Connect to a host' restates the hostname parameter but adds no format or syntax detail beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb (connect over TLS) and resource (the host's certificate), then enumerates the exact fields returned (expiry date, days remaining, issuer, subject). It explicitly distinguishes itself from the sibling ssl_labs_grade, so an agent can route between them without opening either schema.

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

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

Gives explicit when-to-use (quick 'fast facts' about a cert) and when-not ('for a full graded TLS assessment (protocols, ciphers, vulnerabilities)') and names the alternative tool by name. There is no ambiguity about which of the two TLS tools to pick.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does disclose important traits: latency up to ~90s on a cold cache and 24h server-side caching of SSL Labs results. It does not mention authentication requirements, rate limits, or failure behavior (e.g. what happens on unreachable hosts), which is the remaining gap for an unannotated 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?

Three tightly written sentences: capability and coverage first, sibling disambiguation second, latency/caching caveat last. Every sentence earns its place with no filler.

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

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

With no output schema, the description usefully enumerates what the assessment returns (grade, protocol support, ciphers, chain issues, vulnerabilities) and covers the main behavioral caveat (runtime, caching). It stops short of auth/rate-limit or error-mode details, but for a single-parameter read-style check it is nearly complete.

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

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

Schema description coverage is 100% and there is a single required parameter whose format ('no scheme/path') is already documented in the schema. The description adds no additional parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb+resource ('Full SSL Labs-style TLS assessment') and enumerates the concrete outputs: overall letter grade, protocol support TLS 1.0-1.3, cipher strength, certificate chain issues, and named vulnerabilities. It also explicitly distinguishes itself from the sibling ssl_cert_check, so an agent can route without opening either schema.

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

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

Gives explicit when-to-use ('Use this for a deep grade') and when-not plus the named alternative ('use ssl_cert_check instead for a fast expiry/issuer check'). The tradeoff condition (depth vs. speed) is stated outright, leaving nothing 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, the description carries the full burden and does well: it discloses that no LLM is involved, that results are deterministic exact matches (not summarized or inferred), and that JSON-LD blocks are actively VALIDATED against @context/@type and required fields. It omits operational traits like fetch/rate-limit or auth behavior, keeping it short of a 5.

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

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

Well front-loaded: the core action and its outputs come first, and the seo_audit reroute closes the paragraph. It is slightly verbose in restating the selector example that the schema already provides, which costs a point.

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 annotations and no output schema, the description must carry the return-value burden, and it does describe what comes back (JSON-LD, meta tags, selector-field arrays) and the validation behavior. It is close to complete for a read-only extraction tool, missing only edge-case behavior on fetch failure or empty matches.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including attr and selectors. The description repeats the selector-map example already present in the schema and adds no syntax or format detail beyond it, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource ('Fetch a URL and extract structured data') and enumerates exactly what it extracts: validated JSON-LD blocks, OpenGraph/meta tags, and optional caller-supplied CSS-selector fields. It distinguishes itself from siblings by naming seo_audit as the tool for whole-page SEO auditing.

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

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

Explicitly routes the agent to seo_audit for whole-page SEO audits, giving clear when-to-use guidance with an alternative. However, it does not address the potential confusion with the sibling url_to_markdown, which also transforms page HTML, so the alternative coverage is incomplete.

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

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

No annotations exist, so the description carries the full burden, and it does disclose the operationally critical traits: passive reconnaissance, no packets sent to the target, and the exact upstream sources with fallback behavior. What is missing is output shape (flat hostname list? deduplicated? sorted?) and whether upstream rate limits can delay results.

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?

Dense but front-loaded: the enumeration action and source come first, then the passivity guarantee, then the use cases. Each clause adds information and nothing is redundant with the schema.

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

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

For a single-parameter, no-output-schema tool the description covers source, safety profile, and intent, so an agent can decide and call it correctly. It only lacks expected return shape and any bounds or rate-limit caveats on the upstream CT sources.

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

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

Only one parameter and schema coverage is 100%, so the schema already documents the domain format. The description adds no syntax, validation, or edge-case detail (e.g. wildcard handling, subdomain-only input, IDN support) beyond what the schema states, so the baseline 3 applies.

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

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

Specific verb (enumerate) plus resource (a domain's subdomains) with the data source named (Certificate Transparency logs, crt.sh with Cert Spotter fallback). This clearly separates it from siblings like ssl_cert_check, whois_lookup, or dns_propagation_check, which touch adjacent data but do not enumerate hostnames from CT logs.

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

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

It gives concrete use cases (attack-surface reviews, migration inventories, hunting forgotten test/staging hosts), which tells the agent when this tool is the right pick. It stops short of explicit when-not conditions or naming an alternative sibling, so it is context rather than 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?

No annotations are provided, so the description carries the burden, and it discloses meaningful limits: 'Best-effort — not exhaustive, no additional paths are probed.' It also reveals the detection method (headers plus HTML markers), which sets expectations about false negatives. It stops short of stating auth/cost/rate behavior or the exact return shape.

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?

Front-loaded with the action and detection method, then routing guidance, then the limitation clause. Every clause carries distinct information with no repetition 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?

With no output schema and no annotations, the description still covers method, purpose, alternatives, and the best-effort limitation. It does not spell out the returned structure or depth of evidence per detection, a minor gap for a single-param tool.

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

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

Only one parameter with 100% schema description coverage, so the schema already documents 'url' fully. The description implies the fetch target but adds no format, protocol, or validation detail beyond 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?

Specific verb+resource ('fetch a URL and fingerprint its likely tech stack') with concrete evidence sources (response headers, HTML markers) and a plain-language restatement ('what is this site built with?'). It explicitly names siblings seo_audit and structured_data_extract, so an agent can distinguish it without opening any schema.

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

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

Gives explicit routing: on-page SEO/content signals go to seo_audit, raw structured data goes to structured_data_extract. The 'what is this site built with?' framing and the best-effort/no-extra-paths caveat further bracket when this tool is the right choice.

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.

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

No annotations are provided, so the description carries the full burden. It usefully discloses the data source ('direct from the TLD registry') and the exact fields returned, but says nothing about edge cases an agent would care about: unregistered/expired domains, rate limits, or lookup failures. Adequate but incomplete for a tool with zero annotation coverage.

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

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

Two sentences, no waste. The output-field enumeration and the sibling routing rule are both front-loaded, so the agent gets scope and alternatives before any schema inspection.

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

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

With no output schema, the description compensates by enumerating the returned fields, which is exactly what the agent needs to interpret results. The only gap is behavior for unregistered or lookup-failure cases, which is a minor omission for a simple read tool.

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

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

Schema description coverage is 100% and the single parameter's format constraint ('bare domain, e.g. example.com, no scheme/path') is already documented in the schema. The description adds no syntax, format, or validation detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (look up) and resource (domain WHOIS registration record), then enumerates the exact fields returned: registrar, creation/expiry dates, days remaining, name servers, statuses. It explicitly distinguishes itself from domain_health_check and domain_report, so an agent can route without opening another schema.

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

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

Explicitly bounds scope ('Registration data only') and names both alternative tools with the condition that selects each: domain_health_check for DNS/mail health and domain_report for a combined report. Nothing is left to inference.

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