Presend MCP Server

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 adds genuinely useful behavior: the sanctioned true/false meaning, the matching lists returned, and the critical edge case that Cosmos bech32 addresses return sanctioned: null (unchecked, not clean) when unlisted. With no output schema, this disclosure is valuable, though error/rate-limit behavior 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 action and coverage, then edge cases, then a scope caveat. Four sentences are dense but each carries weight; only minor redundancy exists between the description and the schema's address guidance.

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 1-param, read-only tool with no output schema, the description supplies the return semantics (true/false/null, matching lists) and chain coverage needed to interpret results correctly. It is nearly complete, missing only failure-mode handling.

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 address parameter, and the description largely restates the same format guidance (EVM/Bitcoin/bech32). Baseline 3 applies since the schema already documents the parameter; the description adds little beyond it here.

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 (screens) and resource (crypto address) plus the exact scope: every OFAC SDN digital currency address list. It names the covered address formats, so an agent can distinguish it from siblings like ip_reputation, url_reputation, or security_scan without opening the schema.

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

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

The closing sentence 'A sanctions signal only, not a full risk score' clearly bounds usage and warns against over-trusting the result. It lacks explicit routing to named alternatives (e.g. url_reputation for URLs), but the scope boundary is well 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 already establish readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: the fetch source (https://<domain>/robots.txt), wildcard rule inclusion, and the crucial caveat that server-side blocking is NOT reflected — an interpretation limit 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?

Two dense sentences: the first states what is fetched and reported, the second immediately qualifies the scope. Nothing is wasted and the most important constraint is front-loaded in a compact package.

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

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

With no output schema, the description carries the burden of describing results, and it does so by naming the crawler set and allowed/blocked status plus wildcard handling. Slightly thin on response shape (e.g. per-crawler structure), but sufficient for an agent to call and interpret it.

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

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

Single parameter with 100% schema description coverage; the schema already documents the domain format and fetch URL. The description adds no syntax or validation detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (fetches robots.txt) and resource (a domain's AI crawler rules), and enumerates exactly what it reports — GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot and wildcard rules. An agent can distinguish this from generic siblings like dns_lookup or security_headers without opening either schema.

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

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

The boundary statement 'Reflects robots.txt only, not server-side blocking' usefully scopes when the result is trustworthy, but no alternatives are named and no when-to-use trigger is given. Usage is implied by the narrow scope rather than 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 already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered externally. The description adds no behavioral context beyond that (no error handling for invalid Base64, no notes on charset or padding), but it does not contradict the annotations either.

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

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

A single sentence that front-loads the operation and embeds the mode values, with zero redundant or filler text. Nothing needs trimming.

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, deterministic, annotation-covered utility with no output schema, the description is essentially complete. It could mention error behavior for malformed Base64 input, but nothing required 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 description coverage is 100%, so both parameters are already documented in the schema. The description restates the action values and the dual meaning of 'text' but adds no syntax, charset, or padding detail beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb and resource ('Encodes text to Base64 or decodes a Base64 string back to text') and explicitly names the two operating modes. No sibling tool performs Base64 conversion, so no sibling differentiation is required, and the purpose is unambiguous.

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

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

The description implies usage via the '(action = encode or decode)' clause, which maps directly to the required action parameter. It gives no when-to-use context, prerequisites, or alternatives, but for a self-contained utility with no competing sibling the implied usage is sufficient.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the input constraint, but it does not contradict annotations either.

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

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

Two sentences, front-loaded with the purpose, and the second sentence delivers the critical input constraint. No wasted words.

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 converter with rich annotations and full schema coverage, the description is adequate but omits what the tool returns (e.g., the converted color formats). With no output schema, this gap is noticeable, though minor.

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 each parameter already includes examples and the 'exactly one' rule. The description merely repeats that constraint, adding no new semantic detail.

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 ('Converts') and resource ('a color') with the three supported formats (hex, RGB, HSL). No sibling tool overlaps, so differentiation is unnecessary.

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 an input constraint ('Provide exactly one of hex, rgb or hsl'), which is useful, but does not explicitly state when to use this tool versus alternatives or in what contexts. Usage is only implied by the purpose.

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, idempotentHint=true, destructiveHint=false. The description adds substantive operational context beyond them: the 500,000-character limit, the requirement for a header row and at least one data row, the single-column fallback for semicolon/tab input, and 'union of keys becomes header with missing values empty'. It does not, however, describe error behavior or how the limit is enforced (truncation vs rejection).

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 that are front-loaded with purpose and direction values, then constraints, then return shape, then limit. No filler; each clause carries actionable information.

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

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

For a 2-param, read-only, no-output-schema tool, the description is nearly sufficient for correct invocation: it covers input syntax, direction, limits, and even the return fields. The only missing element is failure behavior (malformed JSON, oversized input), which keeps it from a 5.

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 baseline is 3. The description goes beyond it by specifying the exact permitted direction values and the data-format constraints that the schema does not (comma-separated, header row, min one data row, quoted fields, array-of-objects requirement). This is genuine added semantic value.

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 bidirectional verb+resource: 'Converts CSV text to JSON or JSON to CSV'. It enumerates the allowed direction values and is clearly distinguishable from all siblings, none of which perform format conversion.

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

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

The description clearly scopes the tool to inline data ('for data passed inline') and names the direction values that select each mode. There is no explicit statement of when NOT to use it or an alternative tool for file-based conversion, 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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuine context beyond that: it names the external data source (OSV.dev) and the shape of the returned intelligence (summary, CVSS, affected package versions, references), which matters since there is no output schema. It does not mention failure behavior for unknown IDs or rate limits, so it is not a full 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?

Two sentences, zero filler: the first delivers capability and return shape, the second delivers the routing decision. The capability statement is front-loaded and the alternative is placed last where it is easy to act on.

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, idempotent read tool with full annotation coverage and no output schema, the description supplies everything an agent needs: the identifier space, the data source, the returned fields, and the decision rule against the nearest sibling. Nothing material 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%: the single 'id' parameter is already documented in the schema with the same CVE/GHSA/OSV framing the description gives. The description adds no format restrictions (exact prefix syntax, case sensitivity, accepted aliases) 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 (looks up) and resource (a vulnerability by OSV identifier) and enumerates what is returned: summary, CVSS severity, affected packages and versions, references. It also names the sibling it is not (vulnerability_check), 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?

Explicit routing rule: 'Use when you already have an ID; use vulnerability_check when you have a package name instead.' This gives both the when-to-use condition and the named alternative with the condition that selects it, leaving nothing to inference among 40 siblings.

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 and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond that: the data source (Cloudflare DoH) and the batching behavior (all six records in one call, or one type via 'type'). It omits error behavior and any rate-limit caveats, 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?

Two tight sentences with zero filler. The capability statement comes first and the sibling routing follows, which is the right front-loading for a selection decision.

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

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

With no output schema, the description usefully states what comes back (the six record types), which is the main thing absent from structured data. Nothing critical for invoking it is missing, though response shape for the single-type case is left implicit.

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 both parameters are fully documented in the schema, and the schema description for 'type' already states 'Omit to get all 6 at once.' The description's mention of single-vs-all types largely repeats 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 and resource ('Returns DNS records for a domain'), enumerates the six record types returned, and names the underlying mechanism (Cloudflare DNS-over-HTTPS). It explicitly distinguishes itself from whois_lookup and email_security, so an agent can route 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 alternatives with the conditions that select them: registration data -> whois_lookup, SPF/DMARC/DKIM analysis -> email_security. This is textbook when-to-use guidance tied to sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that the check is against a known domain list (i.e., a lookup, not heuristic analysis), but discloses nothing about return format or limits, which is acceptable given the annotation coverage.

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

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

Two tight sentences with no filler; the scope limitation is front-loaded and the alternative routing follows immediately.

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-argument boolean-style check with full annotation coverage and no output schema, the description supplies everything needed to select and call it correctly. Only the return shape is left implicit, a minor gap for such a simple tool.

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

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

Only one parameter, and schema description coverage is 100%, so the schema already fully documents the email argument. The description adds no syntax or format guidance beyond it, making the baseline 3 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 narrow resource scope: checking only whether an address uses a known disposable/temporary domain. It explicitly contrasts with the sibling email_verify, 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 an explicit when-to-use (single disposable/domain check) and names the alternative (email_verify) plus the condition that selects it (syntax, MX, disposable and role checks in one call). 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, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond them by disclosing the best-effort DKIM limitation and warning that a missing match is not proof of absence — a meaningful false-negative caveat. It stops short of describing rate limits or return shape.

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

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

Three tight sentences, front-loaded with the scope of the audit and ending with the disambiguating constraint. No filler or repetition of the title.

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

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

For a read-only check tool with no output schema, the description covers what is examined and the key DKIM caveat. It does not sketch the response format (e.g. per-record verdicts), which would be the remaining useful addition.

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 already documented with an example ('example.com'). The description adds no format or syntax detail beyond the schema, 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 ('Audits') and resource ('a domain's email anti-spoofing setup'), then enumerates the exact checks performed (SPF strength, DMARC policy, DKIM lookup). This clearly separates it from address-level siblings like email_validate and email_verify.

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

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

The closing line 'Checks a domain, not a single address' gives clear context for when this tool applies versus address-level siblings. It does not name an alternative explicitly or state exclusions, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the meaningful behavioral limit: it performs only syntax and MX resolution and explicitly does NOT detect disposable/role addresses. It omits return shape and any rate/network-failure behavior, but that is a minor gap given 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?

Two tight sentences, zero filler. The capability and its boundary are front-loaded before the alternative-tool pointer.

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 validator with no output schema, the description covers what is checked and what is excluded, which is sufficient for correct invocation. It does not describe the return value, which is the one small gap since no output schema exists.

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

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

Only one parameter with 100% schema coverage, so the baseline is 4 and the schema already defines it fully. The description restates the check semantics ('correct syntax and a resolvable domain') but adds nothing beyond what the schema wording provides.

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

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

States a specific verb and resource (email check) and immediately narrows the scope to syntax plus MX-record resolution. It explicitly differentiates itself from the sibling email_verify, so an agent can choose between them without reading either schema.

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

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

Explicitly gives the when-not case ('Does not detect disposable or role addresses') and names the alternative tool for the fuller check ('use email_verify for the combined check'). Routing guidance 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 cover read-only, idempotent, open-world, and non-destructive behavior, so the bar is lower. The description adds critical operational context beyond annotations: it does not probe the mailbox, and valid is null when MX lookup is incomplete, with retry guidance instead of treating the address as invalid.

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 purpose, then alternatives, then the key failure mode. Every sentence earns its place with no redundancy.

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

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

For a single-parameter, read-only, open-world tool with no output schema, the description covers purpose, alternatives, scope limitation (no mailbox probe), and the crucial null-valid edge case. Nothing an agent needs to select or correctly interpret the call is missing.

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

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

Schema description coverage is 100%, so the single email parameter is already fully documented in the schema. The description restates that email is run through the checks but adds no syntax or format meaning beyond what the schema provides, matching the baseline for high coverage.

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

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

States a specific combined action (syntax, MX, disposable, role/generic checks) and explicitly names the sibling tools it supersedes. An agent can distinguish it from email_validate and email_disposable without opening either schema.

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

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

Explicitly says to prefer this over email_validate and email_disposable unless a single signal is needed, and adds that it does not probe the mailbox. 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial behavior beyond them: the declared-vs-default source distinction, the possibility of a data: URI, the fallback to /favicon.ico, and the explicit note that existence is never verified. This is exactly the extra 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?

Dense but front-loaded: it leads with the return value, then the mechanism, then the fallback, then the usage caveat. 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?

With no output schema, the description fully compensates by describing the return shape (URL plus source: declared/default and a note) and the failure mode. Nothing an agent needs to call and interpret it 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 (domain) with 100% schema description coverage, so the schema already documents it. The description adds no syntax or format detail beyond the example already in 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+resource: returns the favicon URL a website declares, and explains the resolution mechanism (fetch homepage, take first <link rel='icon'> href). An agent immediately understands it differs from link_metadata or url_clean siblings.

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 it to display a site icon; it does not download or validate the image' gives a clear intended purpose and an explicit exclusion (no download/validation). It doesn't name a sibling alternative when one might overlap, but the when-to-use context 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 readOnlyHint/idempotentHint/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuine value beyond that: it is offline, uses a specific checksum algorithm plus country length rules, and explicitly limits the guarantee to well-formedness. Auth and rate-limit concerns are irrelevant here, so this is nearly complete.

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

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

Two tightly written sentences, front-loaded with the core verb and scope. Every clause earns its place, including the disambiguating 'not that the account 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 validation tool with full annotation coverage and 100% schema description coverage, the description supplies everything an agent needs: method, offline nature, and the limit of what a pass means.

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 'iban' parameter already documents that spaces are ignored. The description adds no format or normalization 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 and resource ('Validates an IBAN') and pins down the mechanism (ISO 7064 mod-97 checksum, country-specific length). The closing clause carves out the boundary between format validation and account-existence checks, so an agent knows exactly what this tool does and does not confirm.

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

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

The description gives clear context for when the tool applies ('well-formed' checks, 'offline') and implicitly excludes account-verification use cases ('not that the account exists'). It stops short of naming any sibling (e.g., vat_validate) or explicitly stating a when-not condition, so it is clear but not fully routeable.

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, non-destructive, open-world behavior, so the bar is lower. The description adds real behavioral context beyond them: the signal is a 'narrow list-based' lookup with inherent false-negative risk, IPv4-mapped IPv6 is routed to the IPv4 list, and responses carry list date and attribution.

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

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

Three sentences, front-loaded with the core action and scope, then the caveat about the signal's limits. The IPv4-mapped IPv6 parenthetical duplicates the schema text and is the only mildly wasteful element in an otherwise dense, well-ordered 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?

The tool is simple (one required param, no nested objects) and the annotations cover the safety profile, so the description needs little more. It partially compensates for the absent output schema by noting that list date and attribution are included, though it does not say what a positive match actually returns (categories, matched netblock, etc.).

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

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

With a single parameter at 100% schema description coverage, the schema already carries the full semantics, and the description largely restates it (including the same IPv4-mapped IPv6 parenthetical). It adds no new syntax, normalization, 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?

Specific verb ('Checks') plus resource ('IPv4 or IPv6 address') and the exact nature of the data source ('curated list of netblocks known to be hijacked or run by spam/cyber-crime operations'). It is far more precise than a tautology, but it never names or contrasts the close sibling 'address_risk' or 'url_reputation', so an agent still has to guess which reputation tool is the right one.

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

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

Usage is implied by the resource type, and the description usefully warns that 'a clean result is not a safety guarantee', which shapes interpretation of results. However, it gives no explicit when-to-use condition, no prerequisites, and does not route the agent to or away from alternatives such as address_risk for related address-risk questions.

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, and non-destructive, so the description is right not to repeat safety metadata. It adds genuinely valuable context beyond annotations: that the signature is unverified and claims must not be trusted on this basis, which is the key behavioral caveat for a security-adjacent tool.

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

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

Two front-loaded sentences with zero filler; the security caveat and the routing alternative each earn their place.

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

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

For a single-input decoding tool with no output schema and annotations covering the safety profile, the description supplies the essential caveat and the redirect to jwt_verify. It could say a touch more about the decoded shape (header/payload only), though it already implies this.

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 'token' parameter is fully documented in the schema, which even repeats the no-verification caveat. The description adds no format or syntax detail beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb (decodes) and resource (JWT's header and payload) and immediately distinguishes itself from jwt_verify by scoping what it does NOT do. An agent can pick it apart from jwt_verify without inspecting 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 names the alternative (jwt_verify) and the condition selecting it ('to check authenticity'). The when-to-use/when-not-to-use split is fully enumerated in two sentences.

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, so the safety profile is covered; the description adds genuinely new behavior by disclosing that exp/nbf claims are validated in addition to the signature, and that key material selection depends on the algorithm family. It stops short of saying what a failure looks like (expired vs bad signature vs unknown kid), which is the one remaining gap for a verification tool with no output schema.

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

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

Two dense sentences: capability and algorithm coverage first, credential requirements second, sibling routing last. No filler, and the most decision-relevant information is front-loaded.

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

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

For a four-parameter, nested-object tool with no output schema, the description covers algorithms, credentials, claim checks and sibling routing, which is nearly everything needed to invoke it correctly. The missing piece is the shape of the result (valid/invalid plus failure reason), which is not derivable from any structured field.

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 baseline is 3, but the description adds the conditional selection logic across the four parameters ('secret for HS*, JWK or JWKS URL for RS/PS/ES'), grouping jwk and jwks_url as alternatives that the schema documents separately. That is real added meaning beyond the per-field text.

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 (cryptographically verifies), resource (JWT signature), the exact algorithm families supported (HS/RS/PS/ES 256/384/512), and the additional exp/nbf claim check. It explicitly names the sibling jwt_decode as the thing it is not, so an agent can separate 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 an explicit routing rule: 'Use instead of jwt_decode whenever authenticity matters,' which names the alternative and the condition that selects it. It also states the credential-selection rule (secret for HS*, JWK or JWKS URL for RS/PS/ES), removing the main ambiguity in how to invoke it.

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

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

Annotations already declare readOnly/openWorld/idempotent, so the safety profile is covered. The description adds real behavior beyond that: it follows redirects, returns final_url, and explains favicon_source (declared vs /favicon.ico guess) — meaningful disclosure the 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?

Three tight sentences, front-loaded with the core action and its outputs, then the redirect behavior, then the alternative tool. No filler.

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

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

With no output schema, the description helpfully names key return fields (final_url, favicon_source). It stops short of describing failure behavior (non-HTML pages, unreachable hosts) or output shape, but for a single-param read tool this is largely sufficient.

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

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

Single url parameter with 100% schema description coverage, so the schema already documents it. The description adds only marginal framing (what gets extracted from that URL); baseline 3 is appropriate when the schema carries the load.

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 (fetches/extracts) and resource (web page metadata), enumerating exactly which fields are pulled (title, description, canonical URL, OG/Twitter tags, favicon). It distinguishes itself from sibling redirect_trace by naming it directly.

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

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

Explicitly routes the agent to redirect_trace when per-hop redirect data is wanted, which is clear alternative guidance. It does not address other plausible neighbors (url_reputation, security_headers), but the primary competing use case is 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?

Substantially exceeds the annotations (readOnly/idempotent/openWorld/non-destructive). It discloses what is flagged (unseen human publisher after 180+ days inactivity in last 365 days), what is reported but explicitly not flagged (trusted OIDC publishing, pre-release, established handover), and a known blind spot (hijacked existing accounts). This is unusually rich behavioral 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?

Dense but mostly earned: every clause informs detection scope or output meaning, which matters with no output schema. One minor inefficiency is leading with the ecosystem caveat before stating the core purpose, but overall it is tight for the amount of behavior conveyed.

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

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

With no output schema, the description carries return-value explanation (found, first_published, package_age_days, new_package threshold) and detection caveats thoroughly. An agent has enough to call it correctly and interpret results for either ecosystem.

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 described there, including the npm-vs-pypi split. The description largely restates the ecosystem semantics (npm full analysis, PyPI existence and age only) rather than adding syntax or format details 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?

The description names a specific analysis (publisher-change detection) and states precisely what is reported (found, first_published, package_age_days, new_package), plus the ecosystem scope. It is clearly distinguishable from siblings like typosquat_check or vulnerability_check by focusing on maintainer handover patterns.

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

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

It gives clear context: npm-only for publisher analysis, PyPI limited to existence/age, and explicitly frames output as 'a heuristic for review, not proof.' It does not say which sibling to call instead when you need vulnerability or reputation data, so it stops short of full 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 readOnlyHint, destructiveHint=false, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds only that output is random and that ambiguous characters can be excluded; it says nothing about output format, entropy guarantees, or whether defaults are safe. Adequate but thin beyond 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?

Two sentences, no filler, with the core action front-loaded and the sibling routing placed second. Every clause earns its place.

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

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

For a zero-required-param generator with full schema coverage and no output schema, the description covers purpose, options, and the main alternative. It could note the default length or the return shape, but nothing critical 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 description coverage is 100% and each parameter already documents its meaning and the 1/0 convention. The description's option list mirrors the schema without adding format or default details, 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 ('Generates a random password') and enumerates the configurable dimensions. It also explicitly distinguishes itself from the sibling password_check, so an agent can route between them without opening either schema.

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

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

Names the alternative tool and the condition that selects it ('To evaluate an existing password, use password_check'). It does not cover when not to use this tool or any prerequisites, but the primary routing decision is made 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful context beyond that: k-anonymity via a 5-character SHA-1 prefix and the warning that the password travels in the request URL. It stops short of stating rate limits or exact return shape ('how many times' is only implied).

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

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

Two dense sentences, zero filler, with the breach-only constraint and the alternative front-loaded. Every clause earns its place.

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

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

For a single-parameter read tool with full schema coverage, the description supplies what the structured fields cannot: the privacy model, the URL exposure risk, and the sibling relationship. The implied 'how many times' return signal is a minor gap with no output schema 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 coverage is 100% and the schema description already documents the k-anonymity mechanism and the URL/POST tradeoff, so the description largely restates it. Baseline 3 is appropriate when the schema carries the parameter burden.

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 ('checks whether a password appears in known data breaches') plus the scope ('breach check only') and names the sibling it differs from. An agent can distinguish this from password and password_check 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 routes the agent: password_check adds strength scoring and sends the password in a POST body, while this tool is breach-only. The schema repeats the conditional ('for real passwords, prefer password_check'), leaving no inference required.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so safety is covered. The description adds genuinely new behavioral context beyond them: the k-anonymity mechanism (only a hash prefix is sent), the rule that a breached password is always rated very_weak, and the transport guarantee that the password goes in a POST body and never a URL. This is strong, non-obvious disclosure; it stops short of only omitting the exact return shape.

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

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

Every clause earns its place: the scoring factors, the optional breach behavior with its privacy mechanism, the routing to siblings, and the transport note. It is front-loaded with what the tool does before moving to alternatives and security caveats, with no filler sentences.

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, no-output-schema scoring tool, the description covers purpose, the breach side-effect, privacy, and routing. The main gap is that it does not describe the shape of the result (e.g., the strength bucket vocabulary such as very_weak, or whether entropy is returned numerically), which an agent may need to interpret output.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the consequence of check_breach=true (a Have I Been Pwned lookup via k-anonymity) and the override behavior where a breach forces a very_weak rating, which the schema's one-line parameter description does not convey.

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 (scores) and resource (password strength) and enumerates the factors used: length, character variety, entropy as an upper bound, repeated patterns, and per-word passphrase estimation. It also names the exact siblings it must not be confused with (password_breach, password), so an agent can disambiguate 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 gives the when: 'Use it to evaluate a password someone is choosing', and names the alternatives with their selecting conditions: password_breach 'when you only need the breach count' and password 'to generate a new one'. This is textbook when/when-not/alternatives 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond them: that the end user's country cannot be inferred over MCP, which explains why 'country' may be demanded. No output format or rate-limit detail, but the bar is lower with annotations present.

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

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

Two tight sentences, no filler. The primary purpose and its return values are front-loaded, with the parameter constraint following as supporting detail.

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

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

For a 2-parameter, read-only tool with no output schema, the description enumerates the return fields the agent can expect and covers the one conditional input rule. 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%, so the baseline is 3. The description goes slightly beyond the schema by explaining the rationale for the conditional 'country' requirement (no country inference over MCP), reinforcing why the parameter matters rather than merely restating it.

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 (validates and formats) and resource (phone number), then enumerates exactly what is returned: validity, country, line type, and E.164/international/national formats. It is unmistakably distinct from siblings like email_validate or iban_validate.

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?

Clearly states the condition that governs the second parameter: numbers without a leading + require 'country'. It gives no explicit alternatives or when-not guidance, but this is a single-purpose tool with no near-identical sibling, so the context is sufficient.

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, and non-destructive, so safety is covered. The description adds meaningful behavior beyond that: the 15-hop cap, per-hop status codes, and the cross-domain indicator, which shape how an agent interprets results.

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

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

Two tightly packed sentences, front-loaded with what the tool does, followed by the routing advice. Every clause carries 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?

There is no output schema, and the description compensates by describing what is returned (each hop, status codes, cross-domain flag) plus the hop limit. Given the single-parameter simplicity, this is nearly complete, though it could note error behavior for unreachable URLs.

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 'url' parameter, so the schema already documents it fully. The description confirms the hop-by-hop intent but adds no format or syntax 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 (follows) and resource (redirect chain) with scope details (up to 15 hops, per-hop status codes, cross-domain flag). It clearly distinguishes itself from siblings like url_reputation and link_metadata by describing the hop-by-hop traversal.

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 characterizes the use case ('short or tracking link') and names a follow-up alternative ('check the final URL with url_reputation'). It does not state when NOT to use it, but the intended context 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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: GitHub-only scope and the failure mode that missing or private repositories return found: 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?

Three tight sentences: purpose and output signals first, routing guidance second, scope and error behavior last. The field enumeration is informative rather than padding, and nothing is repeated across sentences.

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

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

With no output schema, the description appropriately discloses what comes back (the signal list) and how failures surface (found: false). Combined with annotations covering safety, an agent has everything needed to call and interpret this tool.

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

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

Only one parameter, and schema description coverage is 100% (owner/name format with an example). The description restates 'owner/name' 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+resource (maintenance signals for a GitHub repository) and enumerates the concrete signals returned: stars, forks, open issues, license, archived/fork flags, dates, topics. It is immediately distinguishable from siblings like vulnerability_check and typosquat_check.

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

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

Explicitly states the decision it supports ('judge whether a dependency looks maintained or abandoned') and names the alternative: for npm/PyPI packages without a known repo, use supply_chain_check. It also scopes the tool to GitHub only.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds substantive context beyond that: it lists what is actually probed and clarifies that unsafe methods are never invoked, with exposure inferred from the route listing rather than by exercising them — a meaningful disclosure about how results are derived.

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

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

Two dense sentences, no filler. The purpose and scope are front-loaded, and the safety caveat about never calling unsafe methods follows immediately where it matters.

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 audit tool with full schema coverage and annotations carrying the safety profile, the description covers what will be examined. Since there is no output schema, a brief hint at the report shape would have closed the last gap, but nothing needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 100% and the single 'url' parameter is already documented with an example format in the schema. The description adds only the qualifier that the endpoint should be public, which is context rather than new parameter syntax. 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 ('Read-only audit of a public CometBFT (Cosmos SDK) RPC endpoint') and enumerates the exact checks: node status, health, peers, and unsafe admin method exposure. No sibling tool overlaps with this domain, so it is unambiguous within the toolset.

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

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

The description makes clear the context in which this applies (auditing a public CometBFT RPC endpoint) and even the safety constraint under which it operates. It does not name when to prefer an alternative or when not to use it, but no sibling provides comparable coverage, so the omission is minor.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing the return shape: per-header findings plus fix advice, a score and a letter grade. It does not mention failure modes (unreachable hosts, non-HTTP schemes) or rate limits, which keeps 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?

Two tight sentences: the first states what the tool does and what it returns, the second handles routing. No filler, and the scope ('one URL') is front-loaded before the alternative is mentioned.

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

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

With no output schema, the description carries the burden of explaining returns and does so adequately (findings, fix advice, score, grade). For a single-URL read-only audit the coverage is nearly complete, though it omits error/edge-case behavior for invalid or non-responsive URLs.

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 a single required parameter and schema coverage is 100%, so the schema already documents the url field adequately. The description only reiterates 'one URL' without adding format, scheme or scope constraints 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?

The description opens with a specific verb and resource ('Audits the HTTP security headers of one URL') and enumerates the header families covered (CSP, HSTS, X-Frame-Options, Permissions-Policy, cross-origin policies). It also explicitly distinguishes itself from the sibling security_scan, so an agent can pick between them without reading 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?

It gives a direct usage condition ('Use it when you need header hardening advice') and names the alternative tool plus the reason to prefer it ('security_scan runs this audit together with URL reputation and subdomain discovery in one call'). This is explicit when-to-use and when-to-use-something-else 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real behavioral context beyond them: the checks run in parallel, and the result is an overall score plus verdict rather than raw signals. It omits rate limits, latency expectations, and what happens on partial failures.

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

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

Two short sentences with no filler; the scope of the combined scan is front-loaded and the routing hint follows. Every clause carries information an agent can act on.

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 scan with no output schema, the description covers what is checked and what kind of result comes back (score and verdict), which is the important missing piece. It stops short of explaining how the score is composed or how partial failures are surfaced, but nothing critical to invocation is absent.

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 description already documents it at 100% coverage. The description adds nothing about URL format, protocol requirements, or accepted input shapes beyond what the schema states, so this sits at the documented 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 ('combined website check') and enumerates exactly which signals it aggregates: security headers, URL reputation, and passive subdomain discovery. This lets an agent distinguish it from the overlapping siblings security_headers, url_reputation, and subdomains 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?

Provides a clear routing rule: use this combined call for a full posture check, use 'the individual tools when you need a single signal.' The when-not condition is explicit, though the alternative tools are referenced generically rather than by name, so the agent must still map 'individual tools' to the siblings.

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 the safety profile (readOnly, idempotent, openWorld). The description adds real value beyond them: it discloses the passive nature of the lookup and warns that crt.sh is 'occasionally slow or unavailable', which sets latency/availability expectations 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?

Two tight sentences with the core purpose front-loaded and the caveat appended. No wasted words.

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 full annotation coverage and no output schema, the description is nearly complete: it explains the source, scope, and reliability caveat. It stops short of describing the shape of the returned hostname list, but that is a minor gap.

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

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

Schema description coverage is 100% for the single 'domain' parameter, so the schema already documents it fully. The description adds no format or syntax detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('Passive subdomain discovery') and immediately names the data source (crt.sh / Certificate Transparency logs). Crucially it distinguishes itself from the sibling dns_lookup by clarifying it finds hosts from public TLS certificates, 'not every DNS record'.

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 scope statement ('hostnames that appeared in public TLS certificates, not every DNS record') effectively tells the agent when this tool is appropriate versus a general DNS tool. It does not explicitly name dns_lookup as the alternative, so it falls just 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 read-only/idempotent/non-destructive/open-world, and the description adds substantial context beyond that: the package_not_found verdict, the 30-day new_package rule and review_recommended, the rule that failed checks become 'incomplete' rather than 'no_signals_found', and deprecated/yanked flagging. This is exactly the behavioral disclosure the annotations can't carry.

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 actionable instruction is front-loaded and every clause adds a distinct behavior (not_found verdict, new-package threshold, unavailable_checks semantics). It is long and dense, but almost no sentence is filler; slightly heavy for 3 parameters.

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?

Though there is no output schema, the description explains the return semantics (overall_risk values, flags, version_checked, unavailable_checks) in enough detail that an agent can interpret the result. Nothing needed to call or act on the tool 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?

With 100% schema coverage the baseline is 3, but the description adds real semantic value: vulnerabilities are checked against the given version or the latest published one (version_checked/version_source), and it restates that maintainer_change_check is npm-only. Minor duplication of the schema rather than new meaning for 'package'.

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 precise verb+resource ("One-call risk check") and enumerates exactly what it aggregates — vulnerability_check, typosquat_check, maintainer_change_check, repo_health_check — into a single verdict. It also distinguishes itself from the siblings by saying to use the individual tools to investigate one signal.

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 ("Call this before installing or adding a package ... especially one whose name you recalled or that a model suggested") and an explicit alternative (the individual per-signal tools). The conditions that select this tool are 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 read-only, idempotent, non-destructive, and closed-world. The description adds behavior beyond that: the 64-bit SimHash algorithm, word shingles, and the crucial calibration that unrelated texts score around 50%, not 0%.

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

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

Two sentences, no waste. Front-loads the algorithm and core use case, then adds the essential score interpretation.

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

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

No output schema exists, but the description explains what each input mode returns (a hash for one text, a comparison score for two) and how to interpret that score. That is complete for a single-parameter pure function.

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 already documents the sole parameter at 100% coverage, including the 1-vs-2 text modes and 200k char limit. The description repeats the input modes without adding syntax beyond what the schema provides.

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

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

Name and description together state a precise operation: near-duplicate detection via 64-bit SimHash over word shingles. It clearly distinguishes this from every sibling (none of which compute text similarity) and explains the two input modes.

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

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

The description gives clear context for when to use it (near-duplicate detection, paraphrased or lightly edited copies) and how to invoke each mode (1 text for hash, 2 for compare). It does not state explicit exclusions or alternatives, but given no sibling overlaps, the guidance is adequate.

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=false, so the safety profile is covered. The description adds the current-time fallback but not the output format for the date-to-unix direction or error behavior, so it adds modest value.

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

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

A single tight sentence with the core behavior front-loaded and the parameter rule second. Nothing is wasted.

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

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

With no output schema, the description should ideally state return formats; it names ISO dates for one direction but leaves the timestamp output format implicit. For a two-parameter, zero-required utility this is nearly complete.

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

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

Schema description coverage is 100% and both parameters already document their direction and mutual exclusivity. The description restates the same exclusivity rule without adding format or parsing details, 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 resource and two concrete behaviors: returning the current time and converting between Unix timestamps and ISO dates. An agent can immediately tell this apart from unrelated siblings like uuid or color.

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 provide unix or date, or neither for the current time, which tells the agent the valid invocation modes. It lacks guidance on what happens with ambiguous or malformed input, but for a simple utility this is clear 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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely useful decode-coverage behavior: bank, staking, gov, and authz messages are fully decoded while others degrade to type URL plus raw hex.

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

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

Two tight sentences, front-loaded with the core action and format, followed by the output/coverage caveat. No filler.

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

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

With no output schema, the description explains the return shape (messages, fee, gas, signers, signatures) and the partial-decode caveat, which is exactly what an agent needs to interpret results. Complete for a single-param read tool.

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

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

Schema coverage is 100% and the schema already describes the base64 TxRaw bytes and CometBFT RPC origin. The description largely echoes that (adding only the data.txs location), so it doesn't add much beyond the schema 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 (decodes), resource (raw signed Cosmos SDK transaction), and input format (base64 TxRaw bytes from a CometBFT block). This clearly distinguishes it from adjacent siblings like jwt_decode and base64.

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

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

The description implies the use case (decoding a CometBFT-sourced raw tx) but never states when to reach for this tool versus alternatives, nor any prerequisites or exclusions. Usage is inferable from context rather than 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses the edit-distance threshold scales with name length, that names of 3 characters or fewer are not fuzzy-matched, that matching is against a curated popular-name list, and the important caveat that a clean result does not prove safety. These are exactly the behavioral limits an agent needs to interpret a negative result correctly.

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 short sentences, action guidance front-loaded, then mechanism, then limitations. Every sentence carries distinct information with no repetition of the name or title.

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

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

No output schema exists, so the description should ideally say what a positive/negative result looks like (matched name, distance, confidence). It covers meaning of a clean result and the non-existence gap, making it nearly complete, but the return shape is left implicit.

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

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

Schema coverage is 100%, so the schema already documents both parameters, and the description adds no new per-parameter detail (format, casing, validation rules). The phrase 'whose name you typed or recalled' frames intent but does not enrich the parameter semantics. 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 ('checks whether an npm or PyPI package name is a near-miss of a well-known package (typosquatting)') and explicitly contrasts itself with the sibling supply_chain_check. An agent can distinguish it from the four other check tools 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 trigger ('Call before installing a package whose name you typed or recalled') plus an explicit exclusion and alternative ('It does not check that the package exists: supply_chain_check does'). This is textbook when-to-use / when-not-to-use 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds genuine behavioral context beyond that – the redirect non-behavior and the fact that a clean URL is returned – which helps an agent trust the output shape.

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

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

Two tight sentences with zero filler; the core action is front-loaded and the routing hint follows. Every clause earns its place.

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

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

For a deterministic single-input transform with no output schema, the description supplies everything needed: the transformation, the parameter classes handled, and the boundary condition with a sibling pointer.

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

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

Only one parameter, and schema coverage is 100%, so the schema already documents the url field fully. The description restates the same examples (utm_*, fbclid, gclid) without adding format or syntax detail, 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 (removes), resource (60+ tracking parameters from a URL), and the outcome (returns the clean URL). It is immediately distinguishable from siblings like redirect_trace and link_metadata.

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

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

Explicitly bounds the tool's scope ('Does not follow redirects') and names the alternative for that case ('for that, use redirect_trace'). This is the when/when-not pattern in miniature.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it identifies the external public database queried and honestly discloses the false-negative limitation that a clean result only means 'not listed,' not safe.

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

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

Two tight sentences with zero filler; the source and the scope are front-loaded and the caveat follows immediately. Every sentence earns its place.

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

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

For a single-parameter lookup with rich annotations and no output schema, the definition covers source, scope, and the key interpretation caveat. It does not describe the shape of the returned verdict or any rate-limit behavior, which would round it out.

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 description coverage is 100%, so the schema already documents it fully. The description adds no format, encoding, or example guidance for the URL input, 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 (checks) and resource (URL) and names the exact data source, URLhaus/abuse.ch, scoped to malware distribution URLs. That source detail implicitly separates it from ip_reputation and address_risk, though it never names a sibling explicitly.

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

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

The usage context is implied by naming the malware URL database, so an agent can infer 'use this to check if a URL is a known malware host.' But there is no explicit when-to-use framing and no routing guidance toward alternatives like typosquat_check, link_metadata, or redirect_trace.

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, so the safety profile is covered. The description usefully discloses the shape of the result (browser, OS, device type, bot flag), which matters because there is no output schema, but it says nothing about behavior on malformed or unparseable input strings.

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

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

A single front-loaded sentence with zero filler; every clause names a distinct output field.

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 pure-function tool with no output schema, naming the returned fields is the key missing piece and it is present. The only residual gap is error/edge-case behavior for malformed UA strings.

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

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

One parameter with 100% schema description coverage, so the baseline is 3. The description adds no format, syntax, or example detail beyond what the schema already documents.

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 (parses) and resource (User-Agent string) and enumerates exactly what is extracted: browser+version, OS+version, device type, bot likelihood. No sibling tool overlaps, so differentiation is not needed and none is required.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The only contextual hint lives in the input schema's own description (the server cannot see the caller's UA), not in the tool description.

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, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added behavioral fact is the 1-100 output range, which is genuinely useful but modest. Note that 'random' results sit in mild tension with the idempotent hint, though this is standard MCP semantics for side-effect-free reads rather than a real contradiction.

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

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

A single sentence with zero filler, and the key constraint (the 1-100 range) is front-loaded. Nothing could be removed without losing information.

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

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

For a one-parameter, side-effect-free generator, the description plus annotations plus schema cover everything needed to invoke it correctly. No output schema is needed because the return value is fully implied by the tool's name and description.

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

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

Schema coverage is 100% and the schema itself states the default of 1, so the baseline is met by structured data alone. The description adds the upper bound (100) that the schema does not mention, which is real constraint information an agent would otherwise have to guess.

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

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

The description names a specific verb and resource ('Generates ... random UUID v4 values'), so the agent knows exactly what it produces. No sibling tool produces UUIDs, so differentiation is unnecessary, but the description makes no comparative statement and remains a bare one-liner.

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

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

Usage is implied by the tool's self-evidently narrow scope, and no sibling overlaps with it, so the omission of explicit when-to-use guidance is low risk. Still, there is no statement of context or prerequisites, only the operation itself.

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 real value beyond that: it discloses the real-time external dependency, the successful-return payload, and the availability caveat for certain member states.

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

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

Two tight sentences: the core behavior and return value come first, and the availability caveat follows. No redundant restatement of the title or 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?

With no output schema, the description carries the return-value burden and does state the success payload. It omits the invalid-number response shape and the failure behavior when VIES is unavailable, which is a minor but real gap.

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

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

Schema description coverage is 100%, so both parameters (vat, country) are already documented, including the country-prefix handling and the EL/XI codes. The description adds nothing about parameter format or interaction, 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 (checks/validates) and resource (EU VAT number) and names the exact external authority (European Commission's VIES). It also states the useful outcome (registered company name and address), so an agent can distinguish it from nearby siblings like iban_validate.

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

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

Usage is implied by the name and the mention of VIES, but there is no explicit when-to-use statement, no guidance versus alternatives such as iban_validate, and no note about what to do when VIES is down beyond the caveat that it is occasionally unavailable.

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, open-world and non-destructive semantics, so the description only needs to add beyond that. It does: the npm/PyPI not-found behavior (found: false, vulnerable: null, never a clean result) is a genuinely useful edge case that prevents a false-negative read. No return-shape or rate-limit detail, 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?

Three sentences, front-loaded with the core action and scope, then the edge case, then the sibling routing. Every sentence carries load and nothing is padded.

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

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

With no output schema, the description does explain the key return fields (found, vulnerable) for the negative case, which is the highest-risk ambiguity. It stops short of describing the general response shape or severity fields, but the critical semantics are covered.

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

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

Schema description coverage is 100%, so the schema already documents package, version and ecosystem. The description's 'optionally a specific version' and ecosystem list duplicate what the schema states rather than adding format or syntax 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 (checks) and resource (a package, optionally a version) and names the exact data source (OSV.dev) plus the eight supported ecosystems. It is clearly distinguishable from the sibling check tools 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 routes the agent: use cve_lookup when a CVE/GHSA ID is already known, and supply_chain_check for a combined verdict. It also gives a when-not condition via the nonexistent-package behavior for npm/PyPI, so the agent knows not to read a null result as clean.

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, open-world, and non-destructive semantics, so the description focuses on substance: it discloses the data source (RDAP) and the returned fields. It does not mention rate limits, auth needs, or behavior for unregistered/privacy-protected domains, so it stops short of fully rich behavioral context.

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

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

Two sentences, front-loaded with the resource and return contents, then the routing pointer. Every clause earns its place with no redundancy.

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

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

With no output schema, the description usefully enumerates the key returned fields, and annotations carry the safety profile. It omits edge-case behavior (unregistered domains, WHOIS privacy redaction), which keeps it from being fully complete.

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

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

Only one parameter (domain) and schema coverage is 100%, so the schema already documents it fully with an example. The description adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb+resource (domain registration data via RDAP) and enumerates exactly what it returns (registrar, creation/expiration dates, domain age, nameservers). It even clarifies the RDAP-vs-legacy-WHOIS distinction and names the sibling dns_lookup as the contrasting tool.

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

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

Explicitly routes the agent: 'For DNS records, use dns_lookup.' That is a concrete when-not condition naming the alternative, leaving no inference required.

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