Dechonet-MCP

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real context: no API key required, rate-limited, and that Tor exit / VPN / datacenter flags are informational and do not alter the result. It stops short of describing pagination or lookup-failure behavior, so not 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?

Front-loaded with the core purpose and the alternative routing early. Slightly dense in the middle (the X4BNet parenthetical and the trailing 'Returns ...' sentence) but every clause 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?

An output schema exists, so the description need not explain returns, and it mostly avoids doing so. The closing 'Returns operator, prefixes, classification, and abuse contact' partially duplicates the output schema, a minor redundancy rather than a 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?

Single parameter with 100% schema coverage, so the schema already documents both the IP and 'AS####' forms. The description adds no syntax or format detail beyond that; 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 with enumerated output scope (operator, prefixes, abuse contact, classification) and it names the sibling it is not (reverse_dns). An agent can distinguish it from ip_info or reverse_dns without opening the schema.

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

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

States the decision rule explicitly ('identify who runs a network or whether an IP is cloud/CDN-hosted') and names the alternative with its condition ('Use reverse_dns instead for the host-level PTR name of a single IP'). 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.

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

With annotations already covering read-only/idempotent/open-world safety, the description adds substantial context: it is rate-limited, the structure is not stored, paths/queries/field values are not accepted, the return includes signals with sources plus a signed observation record, and it carefully defines verdict semantics including that no_signals is not a safety guarantee and 'unchecked' lists what was skipped.

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 nearly every clause carries a specific, non-redundant fact (provider list, Korea/Japan rendering path, structural-omission rule). However, it is one very dense paragraph with heavy em-dash nesting and a long provider enumeration, which costs some readability for an agent parsing quickly.

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 complex, open-world, nested-schema tool with an output schema present, the description covers what the agent must know: the inputs' allowed shape and limits, the verdict vocabulary, what is and is not stored, and the signed-record return. Return-format detail is rightly delegated to the 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?

Schema coverage is 100%, so the 3-baseline applies, but the description adds genuine meaning beyond field names: card fields outside a named list of payment providers are flagged, a fake card window inside a real shop is only detectable via this structure, and only host names may be reported (paths, queries, values excluded). It also notes the expectedBrand effect of noting domains lacking the brand name.

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 precise verb+resource framing ('Check the page an agent is about to log in, pay, download from or submit to') and enumerates exactly what is examined: brand impersonation, domain age, prior flagging by DechoNet/licensed feeds, and rendered page behavior from Seoul/Tokyo. This composite, pre-action verdict framing is clearly distinguishable from single-signal siblings like phishing_link_check or lookalike_domains.

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

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

Usage context is explicit — the tool is meant for the moment before login, payment, download, or submission, and it further specifies that callers may submit page structure for payments. It stops short of naming alternatives or stating when not to use it (e.g., vs. phishing_link_check for a link you are not about to act on).

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

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

Beyond the annotations, it discloses the specific checks performed, the possible verdicts, the crucial meaning of no_signals, what unchecked means, that nothing sent is stored, and that the tool is rate-limited. These details materially help an agent interpret and trust the result.

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 pre-signing purpose and remains information-dense rather than padded. It is somewhat long and runs multiple check categories together, but the length is largely justified by the tool's complexity.

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

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

Given the output schema exists, the description need not explain return structure in detail. It still covers the verdict model, unchecked scope, storage behavior, and rate limiting, which makes it complete enough for an agent to call and interpret 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%, so the schema already documents the parameters. The description adds useful semantics by explaining the roles of to, url, and request, and by indicating they can be supplied in combination with 'and/or' even though none are marked required.

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 pre-signing/pre-send crypto safety check and enumerates the exact resources checked: destination address, requesting page, and EIP-1193 wallet request. It clearly distinguishes this from a generic address lookup by covering address, page, and transaction-approval risks together.

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 a clear trigger: use this before an agent signs or sends from a crypto wallet. It does not explicitly name alternatives such as wallet_address_check or phishing_link_check, but the pre-signing context and verdict semantics make the intended usage 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?

Beyond the annotations (readOnly, idempotent, non-destructive) it discloses several operationally important traits: no API key required, rate-limited, and that the phishing check of a front page 'may render it' - a real side effect an agent should know about. The remaining gap is that it does not say how rate limits manifest (error vs. throttle) or how long a check takes, but the added context is substantive.

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 front-loaded sentence that leads with the core question, then parenthetically expands scope and verdict meanings - efficient for the amount of decision-relevant information packed in. The exchange-name parenthetical list is slightly baggy but is genuinely useful for matching, so the length is largely earned.

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?

Even though an output schema exists, the description pre-explains the four verdicts precisely (including the subtle official/danger/not_official distinction, where a name alone is not impersonation), which is the exact ambiguity an agent would otherwise mis-handle. With the side-effect disclosure and source-of-truth description, an agent has everything needed to call it and interpret results 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% with a single required 'domain' parameter, so the schema already carries the baseline. The description still adds value by clarifying that a link/URL is also acceptable input and by explaining what happens for a domain that embeds an exchange name (registration date, first certificate, phishing check).

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 ('Check whether a domain or link is the official address of a crypto exchange, wallet or dApp') and enumerates the coverage (Korean exchanges, global exchanges, wallets, dApps). It clearly distinguishes itself from neighbors like phishing_link_check and wallet_address_check by naming the exact verdict vocabulary and the reference sources it compares against.

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 enumerated domain types (exchange / wallet / dApp) and the four verdicts give strong implied guidance about when this tool is the right one, and the 'compared with the addresses the companies publish themselves' clause explains how the judgment is made. It stops short of explicitly naming an alternative (e.g., phishing_link_check for non-exchange links) or a when-not-to-use condition, so it does not reach 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description adds traits not covered there: no API key or authentication required, and rate limiting applies. It also discloses the return shape (status, KPI summary, issues, recommended actions), giving the agent operational context beyond the structured fields.

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?

Purpose, record types, sibling routing, and operational traits are all front-loaded in a small number of dense sentences with no filler. It is slightly long, and the return-format sentence overlaps the existing output schema, but every sentence still 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?

Given a single required parameter, full annotation coverage, and an output schema, the description supplies everything an agent needs: purpose, record scope, sibling disambiguation, auth/rate-limit posture, and even a redundant-but-harmless return summary.

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 'domain' parameter is already fully documented (format, examples, no scheme/path). The description adds nothing about parameter syntax or format that the schema doesn't already carry, so the baseline 3 for a fully-covered single parameter 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 and resource ('Query DNS records... for a domain') and enumerates the exact record types plus the validation features (DNSSEC presence, SPF/DMARC syntax). It explicitly differentiates itself from dns_propagation and email_auth, 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?

Gives an explicit positive condition ('single authoritative answer about one domain') and two named alternatives with their selecting conditions: dns_propagation for cross-resolver comparison right after a change, email_auth for a full SPF/DKIM/DMARC deliverability assessment. This is textbook 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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description still adds real context beyond them: no API key required, rate-limited, and that output is per-resolver values plus a consistency verdict. Rate limiting is not quantified, which keeps 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?

Four compact sentences, front-loaded with what it does and followed by usage, routing, and operational traits in order of importance. Every sentence carries distinct 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?

For a two-parameter read-only tool with an output schema, the description covers purpose, when to use, the sibling alternative, and operational constraints. Nothing needed to invoke 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 coverage is 100% and both parameters are already documented in the schema, including the enum and default. The description restates the 'one DNS record' scoping and the cross-resolver comparison but adds no syntax, format, or edge-case guidance beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Query) and resource (one DNS record across 8+ named global public resolvers) plus the distinctive behavior of comparing stale vs updated values. It explicitly names the sibling dns_lookup as the alternative, 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?

Gives explicit when-to-use ('after changing a record to confirm worldwide propagation') and when-not, routing to dns_lookup for a single authoritative answer with SPF/DMARC validation. The alternative and its selecting condition are both named.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, and the description adds value on top: it discloses that no API key is required, that it is rate-limited, and that results come from either the daily watch timeline or the diff of the last two stored lookups. That mechanism disclosure explains why the tool behaves differently for watched vs unwatched domains, which annotations alone cannot convey.

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 routing value (when to use, what it is not) is front-loaded across well-formed sentences, and the two-source explanation earns its place. The final sentence enumerating return contents ('monitored tools, newest-first timeline, lookup-to-lookup changes, manage link') partially restates the output schema, which is minor waste in an otherwise efficient description.

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

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

For a moderately complex historical-diff tool, the description covers purpose, routing, data sources, auth, rate limits and constraints. With an output schema present and rich annotations, nothing an agent needs 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?

Only one parameter, and schema coverage is 100% — the schema already documents the domain input including that scheme and path are stripped. The description adds no format or edge-case detail 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?

States a specific verb and resource — reporting recorded changes for a domain over time — and enumerates the dimensions tracked (SSL grade, headers, DNS, OWASP, impersonation). It explicitly differentiates itself from the point-in-time siblings security_scan, owasp_check, and ssl_check, so an agent can route without opening a 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 triggers ('what changed on my domain since yesterday/last week?', 'first check to run when a domain looked at before comes up again') and names the alternative class (point-in-time tools) for the opposite case. It also explains the second-lookup precondition that makes the tool useful without a watch.

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

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

Annotations already establish read-only/idempotent/open-world, and the description adds substantial context beyond them: no API key required, rate-limited, and a precise coverage scope ('only what DechoNet itself observed ... not full passive DNS') that would otherwise cause an agent to over-trust sparse results. It also discloses the return shape (per-kind value timelines plus a coverage note).

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 purpose and the past-vs-present routing before the coverage caveats, and every sentence carries information. The opening sentence is somewhat run-on with its long record-kind list, which slightly hurts scanability but does not waste space.

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 an output schema present, the description needn't detail return values, yet it still notes the per-kind timelines and coverage note. For a single-parameter read-only history tool, all the context an agent needs (scope, limits, alternatives) 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?

Schema description coverage is 100% and the single parameter is fully documented in the schema, including the domain-or-IPv4 and www-stripping behavior. The description only restates the domain/IPv4 duality, adding no syntax or format detail 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?

States a specific verb and resource ('Show how a domain's ... infrastructure has changed over time') and enumerates the exact record kinds covered, including a parenthetical for IP targets. It also distinguishes itself from dns_lookup and rdap_lookup, so an agent can identify it without opening the schema.

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

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

Explicitly frames the selection criterion ('Use this when the question is about the past') with concrete example questions, and names the alternatives to use for the current state (dns_lookup, rdap_lookup). This is exactly the when/when-not routing an agent needs.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description still adds value beyond them: it discloses the depth of probing (15 DKIM selectors, blacklist check across all MX hosts), that no API key is required, and that the tool is rate-limited — though the rate limit itself is unquantified.

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?

Four sentences, front-loaded with what is checked before moving to routing guidance and operational notes; there is little redundancy. It is dense and informational rather than padded, though the mechanism list is long enough that the sentence carries heavy load.

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?

An output schema exists, so return values need not be specified, yet the description still summarizes the shape of the report (score, per-mechanism KPIs, issues, actions). Combined with the enumerated checks and sibling routing, an agent has everything needed 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% and the single parameter's schema text already explains the expected value, including that an IP address is accepted for PTR-based checks. The description adds no further syntax or format guidance for the domain argument, 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 (assess) and resource (domain's email authentication/deliverability posture) and enumerates the concrete mechanisms checked (MX, SPF, DMARC, DKIM, BIMI, MTA-STS, TLS-RPT, DANE, blacklists). It explicitly distinguishes itself from the closest siblings, dns_lookup and email_header_analysis, 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 primary use case ('full sending/receiving readiness review of a domain') and then gives explicit alternatives with the conditions that select them: dns_lookup for raw TXT/MX records only, email_header_analysis for diagnosing an already-sent message. When-to-use and when-not-to-use are both covered.

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

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds operational facts they do not: no API key required and rate-limited. It also scopes the Tor/VPN check as 'information only', preventing an agent from over-weighting that signal; the enumerated OUTPUT list partially duplicates the 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 diagnostic purpose and the sibling alternative come first, and each sentence is load-bearing. The trailing OUTPUT enumeration is the one redundant block, since an output schema already exists.

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 read-only analysis tool with full schema coverage and an output schema, everything an agent needs is present: what to paste, what the report contains, the routing decision against email_auth, and the rate-limit/key situation.

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 schema already spells out verbatim copying, folded continuation lines, and excluding the body. The description's 'INPUT is the full raw header block' restates this without adding format or edge-case guidance, 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 and resource ('Parse raw email headers') plus the concrete outputs it derives: Received path, SPF/DKIM/DMARC results, hop delays, non-TLS hops. It also names the sibling it is not (email_auth), 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?

Explicit when-to-use ('diagnose a specific message that was already delivered — spoofing, delays, or where mail was lost') and an explicit alternative with its own precondition ('Use email_auth instead to assess a domain's sending configuration before sending'). The dividing condition is post-delivery forensics vs. pre-send configuration.

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?

Goes well beyond the annotations: discloses that it is passive apart from a single first-page request per host, performs no logins or path guessing, needs no API key, is rate-limited and can take up to ~1 minute, and that the per-host list plus sensitive-file check are withheld to the DNS TXT-verified owner. These are exactly the constraints an agent needs before invoking it.

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 purpose and the payoff ('the forgotten assets AI-driven attack tools look for first'), and the operational caveats are grouped at the end. The single dense paragraph carries a lot; a slight trim of the category enumeration would improve scannability without losing meaning.

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?

An output schema exists, so return-value explanation is unnecessary, yet the description still signals counts per category, a verdict and remediation guidance. Combined with scope limits, access model and runtime expectations, nothing material is missing 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?

Only one parameter and schema coverage is 100%, with the schema already documenting the scheme/path/www stripping. The description adds no additional semantics about the domain argument, 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 (map) plus a precisely scoped resource: what an org exposes beyond its home page, with enumerated categories (dev/ops tools, admin screens, VPN logins, staging servers). It is clearly distinguishable from siblings like subdomain_discovery, port_scan and security_scan by its combination of CT-log enumeration plus one external fetch per host with categorisation.

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?

Explicit trigger conditions are given: 'Use this when a user wants to know their attack surface or after a breach in their sector.' It also states the public-view restriction and where the fuller report lives. It does not name a sibling alternative (e.g., when to prefer subdomain_discovery or port_scan instead), so it stops short of full when/when-not routing.

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?

Goes well beyond the annotations: discloses that it is a passive multi-probe that nonetheless resolves and fetches the domain, that no API key is required, that it is rate-limited, and the verdict decision logic (any failing essential -> not_ready, only cautions -> caution, all clear -> ready). This is rich behavioral context the annotations alone would not convey.

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 with the core verdict statement first, then scope, usage, decision logic, and constraints. It is dense and slightly long, and the closing sentence partly duplicates the existing output schema, but no sentence is 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?

Given a rich output schema and full annotations, the description supplies everything an agent needs: purpose, when to use, alternatives, side-effect/rate-limit context, and verdict semantics. Nothing material for correct invocation is missing.

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

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

Schema description coverage is 100% for the single 'domain' parameter, and the description adds no syntax or format detail beyond it ('scheme and path are stripped' is already in the schema). Baseline 3 applies when the schema carries 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?

States a specific verb+resource and enumerates the five essentials it checks (DNS resolution, propagation, SSL/TLS, HTTPS reachability, registration expiry), giving a precise scope. It also distinguishes itself from siblings by naming security_scan and 'the individual tools' as different 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?

Explicitly says when to use it ('right before flipping DNS to a new server, or to confirm a migration has landed') and answers the selecting question ('can I switch over yet?'). It names the alternatives (security_scan for posture, individual tools for depth), so routing is unambiguous.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds value beyond them: it specifies the probe is a GET-style request that sends no payload, requires no API key, is rate-limited, and returns a text report with grade, findings, redirect trace, issues and actions. It also discloses grading scope (COOP/CORP/COEP reported but not graded).

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 scope, then grading rules, then sibling routing, then behavioral caveats, then return shape. No sentence is redundant; every clause carries operational 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?

Complete for a single-parameter read-only audit tool: safety profile, prerequisites, rate limits, grading criteria, routing to alternatives, and return contents are all covered, and an output schema exists to carry the exact return structure.

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 url parameter is fully documented in the schema, including the https:// default and redirect-following behavior. The description adds no syntax or format detail beyond what the schema already 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 and resource (follow a URL's redirect chain and audit response security headers), enumerates exactly which headers are graded versus merely reported, and names the siblings it is not (ssl_check, security_scan). An agent can distinguish it from every other tool in the list without opening a 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 scopes itself ('Use this for HTTP-layer/header posture') and names two alternatives with the conditions that select them: ssl_check for certificate/TLS-handshake issues, security_scan for a full domain report. Both when-to-use and when-not-to-use are stated.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: fully passive execution that sends nothing to the target or lookalike domains, no API key required, rate-limited, and the return format. This is exactly the extra behavioral layer annotations cannot express.

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?

It is long, but front-loaded with the core purpose and grade output before the framing and passivity caveats, and each clause carries distinct information. Mildly dense in the middle, but no sentence is pure padding.

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?

An output schema exists, yet the description still briefly characterizes the return (grade, counts, per-category findings, shareable link), and it covers passivity, rate limits, and interpretation caveats. Nothing an agent needs 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 coverage is 100% on the single parameter, and the schema already documents the domain example and the scheme/path-stripping behavior, so the description adds little parameter-level meaning. Baseline 3 is appropriate 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?

States a specific verb+resource ('Assess how exposed a domain is to brand impersonation and phishing') and enumerates the concrete signals it evaluates (typosquats, lookalikes, exposed subdomains, wildcard certs), plus the output form (A+ to F grade). It explicitly names the sibling tools lookalike_domains and subdomain_discovery as the raw-detail alternatives, so the 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?

It tells the agent when this tool is the right choice (aggregate exposure grading) versus when to reach for the sibling tools ('Use lookalike_domains or subdomain_discovery for the raw per-tool detail'). It also frames how to interpret results — report as exposure to verify, not an accusation — which is genuine usage guidance rather than a restatement.

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

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses auth requirements (free API key, exact Authorization header, env var), the 20-row cap with variance by key, rate limiting, coverage scope, and the key behavioral quirk that shared infrastructure collapses to a count. This is unusually rich 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?

Front-loads purpose, then caveats, then auth/limits, so the important content comes first. It is dense and somewhat run-on with stacked parentheticals, but nearly every clause carries operational or behavioral information rather than 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 output schema present, return formatting needn't be explained, and the description still covers return semantics (count-only for shared infra), auth, rate limits, row caps, and coverage boundaries. Nothing an agent needs to invoke 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 coverage is 100% and the enum already lists the kinds, so the description largely restates them. It adds the semantic mapping of which real-world value each kind represents, which is marginal value over 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+resource: find other domains sharing an infrastructure value, and enumerates the value kinds (nameserver, IP, MX host, cert issuer, registrar). It distinguishes itself from siblings by naming the value sources and giving a concrete use case (other phishing domains on a rare nameserver).

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 when to use it ('after domain_history or dns_lookup gives you a distinctive value') and even when results are useless ('shared infrastructure ... returns a count only'). This routes the agent both toward and away from the tool.

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

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

Annotations already cover read-only/idempotent/non-destructive. The description adds important context beyond annotations: no input, reflects the MCP server's egress IP rather than the user's, requires no API key, and is rate-limited. It does not detail the rate-limit cadence or exact geolocation accuracy, but it covers much more than the annotations.

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

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

Three sentences, front-loaded with the purpose, then the key caveat about egress IP, then the alternative routing. 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 no-param, read-only introspection tool with an output schema, the description is complete. It clarifies the semantic caveat (server vs user IP), which is the main risk of misinterpretation, and points to alternatives. Output details are covered by the 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?

Takes zero parameters, so the baseline is 4. The description clarifies that there is no input and explains the implicit input is the server's network, which is useful even though no parameters exist.

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 ('Report information about the caller's own public IP') and enumerates the fields returned (IPv4/IPv6, ISP, ASN, geolocation, proxy/VPN heuristics). It also explicitly distinguishes itself from siblings asn_lookup and reverse_dns regarding known IPs.

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 when to use ('discover the server's outbound IP or test connectivity') and when not to ('To inspect a specific, known IP instead, use asn_lookup or reverse_dns'). This is about as clear as it gets.

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

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

Annotations already declare read-only, idempotent, open-world and non-destructive, and the description adds material context beyond them: no API key required, rate-limited, results derived from live NS delegation via DoH, and the key false-positive caveat that a registered variant is not proof of abuse. That caveat is genuinely important behavior an agent needs.

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

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

The core action and technique list are front-loaded and every sentence carries information (techniques, caveat, follow-up, operational notes). It is somewhat dense and long for a one-parameter tool, but there is 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 single-parameter, read-only tool with an output schema present, the description is more than sufficient: it covers purpose, method, caveats, follow-up, and even summarizes the return payload, which the output schema already handles. 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 coverage is 100% for the single parameter, so the schema already documents the domain format and what gets varied. The description's mention that label and TLD variants are generated restates what the schema says, adding no syntax or format detail beyond it. 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 (generate typosquat/lookalike variants and check which are registered) and enumerates the concrete techniques used. An agent can distinguish it from siblings like dns_lookup or whois_lookup 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?

Explicitly says to use it 'to assess brand-impersonation and phishing exposure for a domain the user is responsible for,' and routes follow-up to whois_lookup for each hit. The scope condition (a domain the user owns) plus the named next tool give clear when-to-use context.

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

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

Goes well beyond the annotations by disclosing the exact wire behavior ('sends initialize and tools/list only — no tool is ever called'), privacy handling ('query strings are removed before anything is sent or stored'), scope limits ('public addresses only'), auth posture ('requires no API key'), and rate limiting. It also states the negative space: what is behind a login or in the server code is explicitly listed as not checked.

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 and front-loaded — the first sentence establishes purpose and scope before details follow. It is long, but nearly every clause adds a distinct behavioral fact; a slight trim of overlapping 'what is not checked' phrasing would sharpen it.

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 diagnostic tool with an output schema, the description covers everything an agent needs: purpose, preconditions, safety profile, and scope limitations. The return values are even summarized (status, KPIs, issues, actions, report link) despite the output schema making that optional.

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 fully documented in the schema, so the description adds no syntax or format meaning beyond it. The mention of query-string removal duplicates the schema note rather than extending it, so the baseline 3 is correct.

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

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

States a specific verb and resource ('Check a remote MCP server from outside') and enumerates exactly what is checked (auth/OAuth metadata, world-acting tools, tool poisoning, CORS/Origin, HTTPS, annotations). No sibling tool (security_scan, http_security, owasp_check) targets MCP endpoints, so it is clearly distinguishable from the rest of the family.

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

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

Gives a clear triggering context ('before connecting it to an agent') that tells the agent when this tool belongs in a workflow. It does not name an alternative sibling or state when not to use it, so it stops short of full 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantial context beyond them: the exact passive techniques used (HTTPS request, TLS cert, CT-log lookup), explicit absence of port scanning or path probing, the owner-only gating of the sensitive-file check, no API key requirement, and rate limiting.

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: capability and scope come first, exclusions and safety characteristics follow, and the return shape is stated last. Every clause carries information, though the single long paragraph could be broken up for faster scanning.

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?

Despite an output schema existing, the description still summarizes the return (grade, per-category findings, out-of-scope list, shareable link), which is more than required. Scope limits, safety posture, prerequisites, and alternatives are all covered for a one-parameter 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 coverage is 100% and the single 'host' parameter's format (no scheme, URL host accepted) is already fully documented in the schema. The description adds no syntax or constraint 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+resource (assess a domain's OWASP posture) and precisely delineates what subset is covered (A04/A02/A03 plus Secure Headers) versus what is not (A01, A05-A10). It also names the sibling tools http_security and ssl_check as alternatives for single-layer depth, 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 when-to-use (external posture check), when-not (authenticated or active/injection testing categories are out of scope and listed as such rather than 'pass'), and routes the agent to http_security or ssl_check for depth. Also states it is suitable for domains you do not own because the technique is passive.

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

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

Annotations already cover read-only/idempotent safety, yet the description adds substantial non-obvious behavior: it reads landing-page HTML, may execute page scripts in isolated Chromium under a shared daily cap, explicitly does not click or submit forms, stores no message text, needs no API key, and is rate-limited. It also explains what each verdict does and does not mean (no_signals ≠ safe), which is high-value 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?

Front-loaded with the core action and the when-to-use cue, and every clause is informative rather than filler. It is a dense single block that could be broken into shorter sentences, so not quite a 5.

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-input check tool with an output schema already present, the description still supplies the full behavioral picture: signal sources, verdict meanings, privacy handling, auth/rate constraints, and the isolated-browser caveat. Nothing an agent needs to invoke 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?

There is one parameter with 100% schema description coverage, so the schema already documents the input, including the redaction advice and non-storage. The description restates 'paste the whole message or a single URL' and adds the 'up to 5 links' cap, but adds little semantic meaning beyond the schema, matching the baseline of 3.

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

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

States a specific verb (check/extract/follow/judge) and resource (links in a suspicious message) with exact scope, and the verdict taxonomy (danger, suspicious, unreachable, official, no_signals) makes it clearly distinct from siblings like lookalike_domains or report_page.

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 'Use this when a user asks whether a link or message is a scam,' giving a clear trigger condition. It does not name alternative sibling tools or state when not to use it, so it stops short of a 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?

Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true, and openWorldHint true, but the description adds substantial context beyond them: the probe is an ACTIVE TCP connect, it does not authenticate or send exploits, it changes nothing on the target, the connection appears in the target's logs, and it is unauthenticated but rate-limited. These details materially inform safe and responsible use.

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 action and scope, then layers behavior, safety constraints, alternatives, and rate-limit notes. Every sentence contributes actionable information, and the structure follows a logical progression from what it is to how to use it responsibly.

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 that an output schema exists, the description need not detail return values, yet it still summarizes the output ('per-port open/closed list with service names'). Combined with annotations covering safety and the description's coverage of authorization, rate limits, and behavior, it provides everything an agent needs to call and interpret the tool.

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

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

With one parameter and 100% schema description coverage, the schema already fully documents 'host' including the 'host:port' form. The description adds no additional parameter-level syntax or format 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 states a specific verb ('Probe'), resource ('a host'), and scope ('fixed set of common TCP ports'), and explicitly distinguishes itself from siblings ssl_check and http_security by naming them. An agent can identify the tool's unique purpose without opening its 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 provides explicit when-to-use ('confirm which services are exposed'), when-not/alternatives ('Use ssl_check or http_security instead to assess a specific service's configuration'), and a clear authorization precondition ('only scan hosts you own or are explicitly authorized to test'). This leaves no ambiguity about appropriate invocation contexts.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive, but the description adds substantial context beyond them: rate-limited, no API key required, what each verdict means, that the certificate chain is tracked but not scored, and why 'unknown' differs from 'no'. That is a genuinely useful behavioural profile.

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-loads the core question before the verdict taxonomy and scope caveats, and every clause carries information. The sentence is long and dense with em-dashes, which costs a little readability, but nothing is padding.

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?

Despite an output schema being present, the description supplies the verdict vocabulary, the scoring caveat, and the observability boundaries an agent needs to interpret and caveat results. Nothing material is missing for a single-parameter 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?

Single parameter with 100% schema description coverage, so the schema already documents 'domain' including that scheme and path are stripped. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 correct.

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

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

States a specific verb and resource ('Check whether a website's public TLS endpoint is ready for post-quantum cryptography') and pins the exact mechanism tested (TLS 1.3 handshake offering only hybrid X25519MLKEM768). This cleanly separates it from sibling ssl_check or http_security, which do not test PQC key exchange.

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 clear context for use (external indicator of PQC migration progress) and explicit exclusions (internal systems, VPNs, code, Korean PQC algorithms are not observable; port 443 public endpoint only). It stops short of naming which sibling tool to use for adjacent questions, so it is not a full when/when-not/alternatives statement.

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?

Goes well past the annotations: it discloses 90-day retention, exactly which fields persist (host, kind, anonymous reporter hash; endpoint path for malicious_mcp; observed values plus connection country for network_anomaly), what is NOT stored (query, page text, free text), and that the call returns immediately without opening the page. It also notes rate-limiting and prioritization of multiply-reported hosts, and its 'not read-only' framing is consistent with readOnlyHint=false.

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, with the kinds enumerated first and the retention/workflow consequences after; nearly every clause carries information an agent needs. However, it is delivered as one long paragraph with semicolon-chained clauses, which makes it harder to scan than it needs to be.

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 non-idempotent, open-world write tool, the description covers retention, anonymity, side effects, the follow-up verification workflow, and rate-limiting, and an output schema exists to carry return-value detail. Nothing an agent needs in order to decide and call 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 coverage is already 100%, so baseline would be 3; the description adds real meaning on top by specifying that url is the MCP endpoint for malicious_mcp and by explaining what belongs in 'observed' for network_anomaly (certificate serial/issuer, addresses seen). There is a slight tension with the schema note 'only its host is kept' versus the description's 'for malicious_mcp the endpoint path', which costs it a point.

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 ('Report a page to DechoNet') and immediately enumerates the eight reportable conditions, so an agent knows exactly what qualifies. It also names the downstream check tools (phishing_link_check, mcp_server_check, dns_lookup, ssl_check), which separates this reporting call from the sibling tools that actually perform 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?

Gives clear per-kind conditions for use (phishing, fake_payment, false_positive, missed, malicious_mcp, network_anomaly) and clarifies that a report does not by itself change a verdict, which prevents an agent from expecting immediate action. It stops short of explicitly routing an agent to phishing_link_check / mcp_server_check when a direct check rather than a report is wanted.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description still adds non-obvious operational context: no API key required and that the call is rate-limited, plus what FCrDNS actually checks and that a provider guess is inferred. It stops short of stating the rate-limit magnitude or failure behavior when PTR is absent.

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 primary action, then verification behavior, then routing guidance, then constraints and returns. Every sentence carries distinct information with no padding.

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?

An output schema already exists, so the brief return summary is a bonus rather than a requirement. The description covers purpose, alternatives, side effects, and operational constraints for a single-parameter lookup tool, leaving nothing an agent needs 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 coverage is 100% and the single parameter is fully documented in the schema, including the IPv4/IPv6 example and the 'must be an IP, not a hostname' constraint. The description restates that both IP versions are accepted but adds no format or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (resolve) and resource (PTR reverse DNS record) plus the extra FCrDNS verification behavior and provider inference. It explicitly positions itself against asn_lookup, so an agent can distinguish the two without reading schemas.

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 concrete use cases ('validate mail-server rDNS or identify a single IP's host') and names the alternative tool with the condition that selects it ('Use asn_lookup instead for network/BGP ownership'). No exclusion 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.

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

Goes well beyond the annotations (readOnly/openWorld/idempotent/non-destructive) by disclosing passivity, that open ports are not scanned, ~1 minute duration driven by the exposure lookup, no API key needed, rate limiting, and the scoring/penalty mechanics including how unreadable data is flagged rather than charged.

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 headline purpose and grade come first, followed by areas, scoring rules, and a labeled BEHAVIOR block. Length is justified by the complexity, though the sentence packing (semicolon-laden clauses) is heavier than strictly needed.

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 complex, multi-area audit tool with rich annotations and an output schema, the description covers scope, scoring semantics, timing, and safety boundaries completely. Return values are covered by the output schema, so nothing an agent needs to invoke 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?

Single parameter with 100% schema description coverage, so the schema already carries the meaning ('Domain to audit', and the scheme/path stripping note). The prose adds nothing further about the domain argument, 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?

Opens with a specific verb+resource+scope: 'One-shot comprehensive audit of a domain, scored 0-100 with an A+ to F grade.' It enumerates the five scored areas and explicitly contrasts itself with depth-oriented siblings (ssl_check, email_auth, exposure_map), so an agent can distinguish it from the 30 sibling tools 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?

States when to use this (broad one-shot audit) versus the individual tools for depth on one area, and clarifies the boundary with port_scan ('open ports are NOT scanned ... port_scan is the separate, active check'). Both the alternative and the exclusion condition are 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?

Goes well past the annotations: it discloses the daily re-check cadence, that unknown is never treated as a pass, the anonymous-vs-API-key split (no alerts and 30-day retention vs account ownership and daily mail on regression), the Bearer token requirement, and that results come from DechoNet's own servers plus a Seoul observation point. It also confirms the write nature ('Not read-only (it stores the set)'), consistent with readOnlyHint=false and destructiveHint=false.

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 and check kinds, then layered auth/retention/return details. It is a dense single paragraph and borderline long, with some restatement ('Not read-only (it stores the set)' echoes annotations, and the check list duplicates the schema), but nearly every sentence carries information an agent needs.

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 a nested expect array, auth-dependent behavior and a daily background job, the description covers the missing pieces: who owns the set, what happens without a key, retention, alert channel, observation sources, and unknown-vs-fail semantics. An output schema exists, yet it still briefly frames what comes back (set id, status page, per-check results, receipts), which is more than required.

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 nested item schema already documents each check kind, its required fields and the op/value/type enums, so the baseline is 3. The prose list of check examples largely restates that enum rather than adding new parameter meaning (e.g. no guidance on how op interacts with value for dns_record 'contains,' or on the 1-20 maxItems).

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 opening clause gives a specific verb+resource pair — record an outside expectation set for a domain and check it now — plus the concrete check kinds (HSTS, DMARC, issue_absent, grade, cert days, DNS record) and the daily re-check behavior. It is unmistakably distinct from one-shot tools like ssl_check or http_security. It never names verify_expectations, the sibling most likely to be confused with it, so sibling differentiation is only implicit.

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

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

Gives a clear triggering scenario: 'after changing DNS, TLS, headers or mail settings, to state the intended result and be told if it is ever reverted,' plus the scoping rule 'public checks only, so any domain is accepted.' It does not state when to prefer verify_expectations (re-check an existing set) over creating a new one, which is the one alternative an agent actually needs.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond that: one full TLS handshake plus ClientHello messages with only the first answer read, no application data, no vulnerability probes, no API key required, and rate limiting. It also discloses how weak findings cap the grade, which affects interpretation.

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 what gets inspected and the grade weighting, then usage routing, then behavioral guarantees, so priority information comes first. It is dense and long, with the cipher-suite enumeration adding bulk, but nearly every clause carries operational meaning.

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?

An output schema exists, so return values needn't be detailed, and the description still notes it returns a text report with grade, expiry/issuer KPIs, issues, and actions. Combined with the behavioral and routing coverage, nothing an agent needs to call this 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?

Both parameters are fully documented in the schema (100% coverage), including the no-scheme hostname format and port default of 443, so the schema does the heavy lifting. The description adds no parameter-level syntax or format detail beyond that baseline; its grade-weighting detail applies to output, not input.

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 (inspect a host's served TLS/SSL certificate and connection) and enumerates exactly what is checked: expiry, issuer, SAN list, chain integrity, revocation, TLS version, HSTS, plus a letter grade. It explicitly differentiates itself from http_security and security_scan, so an agent can place it without opening the schema.

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

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

Gives a direct when-to-use ('diagnose certificate or HTTPS-handshake problems for one host') and names two alternatives with the conditions that select them: http_security for response security headers and security_scan for an all-in-one domain report. This is explicit routing, not implied.

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?

Although annotations declare readOnlyHint=true and destructiveHint=false, the description adds meaningful context: 'fully passive (no packets are sent to the target)', 'requires no API key', and 'rate-limited'. It also lists return fields (subdomain count, risky-name count, wildcard flag, hostname list), which goes beyond typical annotation coverage. A 4 rather than 5 because it doesn't detail rate-limit thresholds or error conditions.

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 action, then progressively adds passivity, flagging rationale, usage guidance, alternatives, and output summary. Every sentence contributes essential information with no fluff.

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

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

Given the tool's complexity and the presence of an output schema, the description covers purpose, passivity, flagging logic, workflow position, alternatives, constraints (no API key, rate limits), and return summary. Nothing significant is missing 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 coverage is 100% for the single 'domain' parameter, so baseline is 3. The description adds value by explaining that the domain should be registrable and that subdomains found in CT logs are returned, giving contextual meaning beyond the schema's format example.

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 'Enumerate' and resource 'subdomains of a domain' and explains the source (Certificate Transparency logs). It explicitly distinguishes itself from siblings dns_lookup and lookalike_domains by naming them and their different roles.

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 explicit when-to-use guidance ('Use this as the first recon step to map a domain's attack surface') and names alternatives: dns_lookup for resolving discovered names and lookalike_domains for typosquat variants. It leaves no ambiguity about its position in the workflow.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, and the description is consistent with all of them. Beyond that it adds genuinely useful behavior: no API key required, no rate limiting, in-process computation, and RFC 3021 handling of /31 and /32 — context the annotations cannot convey.

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 capability and output list, and sized appropriately for a one-param tool. Slight redundancy in restating the local/no-network point twice and enumerating return fields already present in the output 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 simple deterministic calculator with a full output schema and complete annotations, nothing an agent needs is missing. Safety, behavior, edge cases, and inputs are all 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?

Only one parameter, and the schema already documents the CIDR format, prefix range 0-32, and IPv4-only constraint at 100% coverage. The description adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Compute) and resource (IPv4 subnet details from CIDR) and enumerates the exact outputs produced. It clearly distinguishes itself from network-oriented siblings like dns_lookup and ip_info by declaring it is purely computational.

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?

"Use this for IPv4 address planning" plus "It does not query DNS or contact any host" implicitly routes the agent away from dns_lookup/reverse_dns for this task. It gives clear context but never names or explicitly excludes a sibling tool, 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?

Annotations only declare the safety profile (readOnlyHint=false, idempotent, openWorld, non-destructive); the description adds substantial context beyond them: the stored set's state is updated and an anonymous set is retained 30 days, the domain mode stores nothing, outcomes are pass/fail/unknown with unknown never treated as a pass, each read yields a signed observation receipt, and the tool is rate-limited to a few checks per minute.

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 and the two modes, and every clause carries information (retention, outcomes, rate limit). It is dense with parentheticals in a single long first sentence, which costs a little readability but not correctness.

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?

An output schema exists, so return values need no prose. Combined with annotations and a fully described input schema, the description supplies everything else an agent needs: mode selection, storage side effects, outcome vocabulary, freshness expectations, and rate limits.

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 every field including the nested check kinds, establishing a baseline of 3. The description adds meaning the schema does not state: that 'id' and 'domain'+'expect' are mutually exclusive modes and that only the id mode persists state. It does not restate the per-check semantics, which is fine since the schema carries them.

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 ('Check expectations from outside now, with fresh reads') and immediately enumerates the two modes: re-check a stored set by id, or run a one-off domain+checks pass. It names the sibling it complements (set_expectations) and makes clear this tool observes rather than stores.

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 an explicit when-to-use ('right after a change, to see whether it is visible from outside yet — DNS and CDN changes can take minutes to hours to show') and routes between the two input modes ('when there is no stored set'), referencing set_expectations as the counterpart. An agent can pick the right mode without 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?

Beyond the annotations (read-only, idempotent, open-world), the description adds crucial behavioral context: rate-limited, no API key required, the address is not stored, the OFAC list is refreshed daily, and caveats about what a listed/not-listed result means. These details are not available in the structured annotations and materially affect interpretation.

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 checks and then adds caveats, alternatives, and operational traits in a logical order. It is dense but every sentence carries useful information; minor improvement could come from breaking the long first sentence into a clearer list.

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 that an output schema exists, the description need not explain return values. It thoroughly covers what is and is not checked, interpretation caveats, privacy, rate limits, authentication (no API key), and the relevant alternative tool. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% and the single address parameter is fully documented with example formats (0x…, T…, bc1…/1…/3…, Solana). The description adds little about the parameter itself beyond noting that chain detection comes from the format alone, which is more output semantics than input guidance. Baseline 3 is appropriate when 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 uses a specific verb and resource ('Check one crypto wallet address') and enumerates the exact checks performed: chain inference, checksum validation, OFAC SDN lookup, and phishing-page count. It clearly distinguishes this tool from closely related siblings like crypto_check_before_sign.

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 explicitly names an alternative ('Use crypto_check_before_sign to judge an address together with the page that asked and the wallet request'), states what this tool does not cover ('Balances, transaction history and the owner are not looked at'), and provides important interpretation guidance for sanctions hits and misses. This gives clear when-to-use and 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?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, but the description adds real value beyond them: no account/email/PII required, a public unguessable history URL that can be shared, and a rate limit ('a few watches per minute'). The idempotency explanation ('watching an already-watched domain returns the existing watch') restates the annotation but with useful concrete behavior. It stops short of describing failure modes or what the watch record itself contains, keeping it from 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?

Front-loaded with the core action, then layered with the use case, the follow-on tool, and the operational facts (no PII, shareable URL, rate limit). Dense but every sentence adds a distinct, actionable fact 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?

An output schema exists, so return values need no explanation, and the description covers the remaining gaps for a mutating, open-world tool: idempotency, no auth/PII, shareability, and rate limits. An agent has everything needed to decide to call it and how to set expectations.

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 both parameters (domain, tools) are fully documented in the schema, including enum meanings and the default set. The description reinforces which checks are tracked but largely mirrors the schema's enum documentation rather than adding invocation syntax or format detail, so it sits at the high end of the schema-does-the-work 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?

States a specific verb and resource ('Start (or reuse) a daily DechoNet watch on a domain') and enumerates exactly what is tracked over time (SSL grade/issuer/expiry, DNS, HTTP headers, registration, optional OWASP/impersonation). It distinguishes itself from one-off siblings ('beyond a one-off check') and names domain_changes as the downstream consumer, so an agent can separate it from ssl_check, dns_lookup, etc.

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 an explicit condition ('Use this once when the user cares about a domain beyond a one-off check') with concrete scenarios (own domain, client, vendor, target under investigation), and identifies the alternative workflow (one-off checks) plus the follow-on tool (domain_changes). Nothing about when-to-use 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.

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new operational context: RDAP with WHOIS fallback, no API key required, and rate limiting, plus it flags risk states like clientHold and pendingDelete. It stops short of describing pagination or failure modes when a domain is unregistered.

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 retrieval mechanism and payload, then usage guidance and alternatives. The closing sentence ('Returns registrar, key dates, nameservers, and status flags') restates the opening enumeration, a minor redundancy given an output schema already exists.

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 with a full output schema and comprehensive annotations, the description covers purpose, alternatives, fallback behavior, auth (no key), and rate limits. Nothing an agent needs to invoke 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 coverage is 100% and the sole parameter's schema description already documents the domain format and subdomain normalization. The description adds no parameter-level detail beyond what the schema provides, 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 ('Retrieve domain registration data via RDAP') and enumerates the concrete data returned: registrar, dates, nameservers, EPP status flags. It also names the siblings it is not (dns_lookup, reverse_dns, asn_lookup), so an agent can differentiate without opening other schemas.

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 scopes usage ('ownership, lifecycle, and expiry questions about a registered domain') and routes alternatives by condition ('Use dns_lookup instead for live DNS records, or reverse_dns/asn_lookup for IP-level ownership'). This is exactly the when/when-not/alternatives pattern.

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