Presend MCP Server

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

Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description discloses return states (sanctioned true/false/null), coverage asymmetry, and the fact that null means 'unchecked, not clean.' This is valuable behavioral context that could not be inferred from the schema or annotations alone.

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

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

Four sentences with no filler: the primary action comes first, followed by format coverage, the edge case, and the scope caveat. Each sentence earns its place and is appropriately compact for a single-parameter lookup tool.

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-address read-only lookup with no output schema, the description fully equips the agent: input formats, output semantics, coverage limitations, and the caveat that this is not a comprehensive risk score. 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 coverage is 100%, so the baseline is 3, but the description adds meaning by explaining what 'covered' means for each address format and what outcomes result. It connects the address parameter to the tool's behavioral output more clearly than the schema's pattern descriptions alone.

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 ('Screens') and resource ('crypto address against every OFAC SDN digital currency address list'), and explicitly scopes the output as a sanctions signal rather than a full risk score. This is clearly distinct from the sibling tools by domain and purpose.

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 what the tool is for and when its coverage is authoritative (EVM and Bitcoin) versus partial (other chains). It also sets expectations for Cosmos bech32 addresses, though it does not explicitly name alternative sibling tools for deeper or broader risk assessments.

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

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

The annotations already cover readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations by specifying that the check is based only on the fetched robots.txt and explicitly excluding server-side blocking. No contradiction with 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, front-loaded with the action and the result, then followed by a useful caveat. Every sentence earns its place, and the crawler list is compact but specific.

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, idempotent tool, the description is complete enough to invoke correctly: it defines the input, the output type, the URL behavior, and a key limitation. No output schema is present, but the allowed/blocked report is adequately described.

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

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

The single parameter `domain` is fully documented in the schema with an example and the exact URL pattern `https://<domain>/robots.txt`. Since schema coverage is 100%, the description does not need to add more parameter detail, and it does not meaningfully go beyond what the schema already states.

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 operation (fetches a domain's robots.txt) and a specific output (reports which known AI crawlers are allowed or blocked), listing concrete crawler examples. This makes the tool's purpose clear and distinct from the other unrelated sibling tools.

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

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

It provides a clear boundary: the result reflects robots.txt only, not server-side blocking, so an agent knows not to use it for actual access checks. It does not name a sibling alternative or state explicit when-to-use conditions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool performs a pure transformation but does not disclose edge cases like invalid Base64 input or whitespace handling. This is acceptable 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?

A single front-loaded sentence with zero filler. The parenthetical reinforces the action parameter's allowed values without repeating the schema verbosely.

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

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

For a simple two-parameter pure transformation with full schema coverage and a safe annotation profile, the description is nearly complete. It does not mention error behavior for invalid Base64, but the expected output is easily inferable.

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 fully documents both parameters. The description paraphrases the same meanings without adding format details or constraints 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?

States a clear verb-and-resource pair ('Encodes text to Base64 or decodes a Base64 string back to text') and names the action parameter. It is unambiguous and distinguishable from sibling tools by its core function.

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 encode/decode choice is implied by the action parameter, but the description does not explicitly state when to use this tool vs alternatives or provide exclusions. For a unique utility, the context is adequate but left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds minimal behavioral context beyond that, only implying a conversion operation. It does not specify the return format or any edge cases, so the burden on the description is low given annotations, but it does not add rich 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 with no filler. The primary action is front-loaded, and the critical usage constraint is stated immediately. Every word earns its place.

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

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

For a simple three-parameter tool with no output schema, the description covers the essential purpose and the exclusivity rule. However, it does not describe the output format (e.g., what the converted values look like), which is a minor gap. Given the tool's simplicity, 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%, with each parameter already documenting its format and the exclusivity rule. The tool description merely restates the exclusivity constraint, adding no new semantic information beyond the schema. Baseline of 3 is appropriate when the schema fully documents parameters.

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'), a resource ('color'), and the exact formats involved (hex, RGB, HSL). This clearly distinguishes it from all sibling tools, which are unrelated utilities. No ambiguity about the tool's function.

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

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

The description explicitly instructs the caller to 'Provide exactly one of hex, rgb or hsl', which is clear usage guidance. It does not mention alternatives because none exist among siblings, but the exclusivity constraint is stated both in the description and schema, making the usage rule 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?

The description goes well beyond the annotations by disclosing parser limitations (semicolon/tab input is not detected), required CSV structure, JSON-to-CSV key union behavior, missing-value handling, the returned fields, and the 500,000-character limit. This is rich, actionable 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?

The description is compact and front-loaded with the primary purpose, followed by necessary format constraints and return information. Every sentence adds value, and there is no redundant repetition of the schema.

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

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

For a two-parameter conversion tool with no output schema, the description covers input requirements, both conversion directions, parsing edge cases, return values, and size limits. An agent has everything needed to select and invoke the tool correctly.

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

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

The schema already covers both parameters at 100%, so the baseline is 3. The description adds meaningful constraints and format details for both 'direction' values and for the 'data' parameter, such as the need for a header row and the array-of-objects requirement for JSON.

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 the exact operation ('Converts CSV text to JSON or JSON to CSV'), the direction parameter values, and the inline-data scope. This is specific enough for an agent to know exactly what the tool does and to distinguish it from unrelated sibling utilities.

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

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

The description clearly states that data must be passed inline and defines the accepted CSV and JSON shapes. It does not explicitly name alternative tools, but it provides enough context about when to use this tool and what input formats are 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond that: it mentions the lookup happens on OSV.dev, which is consistent with openWorldHint, but does not disclose rate limits, failure modes, or other runtime behaviors. Since the annotations cover most of the burden, a 3 is appropriate.

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

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

Two sentences with no filler. The first sentence front-loads the action and expected output; the second gives precise routing guidance. Every word earns its place.

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

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

For a single-parameter read-only lookup with no output schema, the description fully covers what the tool does, what it returns, and when to prefer a sibling tool. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema with type, description, and example. The tool description repeats the accepted ID formats (CVE, GHSA, or other OSV ID) but adds no meaning beyond the schema, so baseline 3 is correct.

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

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

The description states a specific verb ('Looks up'), a specific resource ('a vulnerability by identifier'), a data source ('OSV.dev'), and the key output fields (summary, CVSS severity, affected packages, references). It also implicitly distinguishes itself from vulnerability_check by framing this as ID-based lookup.

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

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

The description explicitly says 'Use when you already have an ID; use vulnerability_check when you have a package name instead.' This gives both a clear precondition and an alternative tool, leaving no ambiguity for an agent.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is handled structurally. The description adds useful behavior beyond that: it names the upstream service (Cloudflare DNS-over-HTTPS) and explains the all-in-one vs. single-type response behavior. It does not cover rate limits or error cases, but these are less critical given the read-only 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?

The description is two sentences with no filler. The first sentence packs the action, resource, record types, and optional mode; the second efficiently routes to alternatives.

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

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

For a two-parameter, read-only lookup tool, the description covers what the tool does, how to narrow it, which alternatives to use, and where the data comes from. The schema documents both parameters fully, and no output schema exists, but the explicit record-type list gives the agent enough context about expected results.

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

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

Schema coverage is 100%, with clear descriptions for both 'domain' and 'type'. The description adds meaning by listing the concrete DNS record types returned and confirming that omitting 'type' yields all six, which goes beyond the schema's generic wording.

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

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

The description opens with a specific action and resource: 'Returns DNS records for a domain via Cloudflare DNS-over-HTTPS' and explicitly enumerates the record types covered (A, AAAA, CNAME, MX, TXT, NS). It also differentiates itself from related siblings by naming whois_lookup and email_security for registration and email-security needs.

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 explicit routing guidance: 'For registration data use whois_lookup; for SPF/DMARC/DKIM analysis use email_security.' It also clarifies the two usage modes: return all six record types in one call or narrow to a single type via the 'type' parameter.

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, covering the safety profile. The description adds the specific behavioral scope (checks against a known list) and explicitly limits it to only disposable domains, which is useful beyond annotations. No contradiction with 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, front-loaded with the core purpose, and the alternative is mentioned in the second sentence. No filler or redundancy. Every word earns its place.

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

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

For a single-parameter tool with comprehensive annotations and a clear alternative routing, the description is complete. It explains what the tool does, what it does not do, and when to use the sibling. No output schema is needed for such a simple boolean-style check, and nothing critical is missing.

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

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

Schema description coverage is 100% and the parameter description already explains the email address is checked against disposable domains. The tool description does not add additional parameter semantics beyond what the schema provides, but that is acceptable given full coverage. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Checks') and resource ('email address') and clearly scopes it to disposable/temporary email domains. It distinguishes itself from the sibling email_verify by naming what it does NOT do, making the purpose unambiguous even without opening the schema.

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

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

Explicitly states when to use this tool versus the alternative: 'For syntax, MX, disposable and role-account checks in one call, use email_verify.' This provides clear routing logic, telling the agent exactly when to choose this tool (only disposable check needed) and when to choose the sibling.

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, open-world, idempotent, and non-destructive behavior. The description adds valuable context about the DKIM lookup being 'best-effort' and the caveat that a missing DKIM match does not prove absence, which is important for interpreting results. This goes 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?

The description is two sentences, with the core action and scope front-loaded, followed by an important caveat and a clarifying note. No wasted words; every sentence adds value.

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

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

For a single-parameter tool with full schema coverage and no output schema, the description provides a clear picture of what the tool does, its limitations, and its scope. It could potentially mention the output format or expected return values, but given the simplicity and annotations covering safety, it is nearly complete.

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

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

Schema description coverage is 100%, so the parameter 'domain' is already well-documented. The description reinforces that it's a domain (not an address) and gives an example, but doesn't add significant new semantic meaning beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: auditing a domain's email anti-spoofing setup, explicitly listing SPF, DMARC, and DKIM. It differentiates itself from sibling tools like email_validate or email_verify by emphasizing it checks a domain, not a single address, and focuses on anti-spoofing rather than address deliverability.

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

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

While it doesn't name specific sibling tools, it provides clear context on when to use it (domain-level anti-spoofing audit) and implicitly excludes single-address checks. The clarification 'Checks a domain, not a single address' effectively guides agents away from using it for individual email validation, though it could be more explicit about alternatives.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds scoping context (syntax + MX only) and explicitly notes it does not detect disposable or role addresses, which is valuable beyond the annotations. It does not mention output format, but that is a minor gap for such a simple 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 sentences with no redundancy. The core purpose is stated first, and the exclusions/alternative are given in the second sentence. Every word contributes value.

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 annotations covering safety and schema covering the parameter, the description is nearly complete. It lacks an explicit statement about the return format (e.g., boolean or result object), but the simplicity of the operation makes this a minor omission. The tool is fully usable as described.

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

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

The schema description for the 'email' parameter already covers 'correct syntax and a resolvable domain' (100% coverage). The description adds the specific detail of an MX record check, which slightly enhances clarity but does not fundamentally change parameter understanding. Baseline 3 is appropriate.

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

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

The description explicitly states the tool performs a lightweight email check covering syntax and MX record presence, and clearly delineates what it does not do (disposable/role addresses), distinguishing it from sibling tools like email_disposable 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?

It provides explicit guidance by naming the alternative tool (email_verify) for a combined check, and states exclusions (disposable/role) that signal when this tool is insufficient. This is direct routing to the correct sibling.

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 mark read-only, open-world, idempotent, and non-destructive behavior. The description adds important traits annotations cannot express: that it does not probe the mailbox, and that valid is null rather than false when MX lookup cannot complete, which prevents misinterpreting the result.

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

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

Four tight sentences, front-loaded with the tool's main value and followed by routing, behavioral, and null-handling details. Every sentence adds actionable information and none is filler.

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

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

For a one-parameter, read-only lookup with rich annotations and no output schema, the description supplies the routing context, scope, and null-result interpretation an agent needs. Nothing material is missing for correct selection or 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?

There is one required parameter with 100% schema description coverage, so the schema already documents it adequately. The description restates the checks but adds no parameter syntax, format, or constraints beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific resource and enumerates the exact checks performed: syntax, MX record, disposable-domain detection, and role/generic account detection. It also names the sibling tools it supersedes, making the tool's distinct scope clear without opening any schema.

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

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

Gives explicit routing guidance: prefer this over email_validate and email_disposable unless only a single signal is needed. It also tells the agent how to treat a null valid result, including a retry-later instruction, so the usage boundary is fully specified.

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, but the description adds substantial behavioral detail: it fetches the homepage, takes the first <link rel='icon'> or 'shortcut icon' href, resolves to absolute URL, may return a data: URI, falls back to default favicon.ico without checking existence, and returns a source field with declared/default values. No contradiction with 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?

The description is two sentences, with the primary behavior front-loaded, followed by the fallback behavior and a usage note. Every sentence adds value, and there is no redundancy or fluff.

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

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

The tool has a single parameter and no output schema, so the description carries the full burden of explaining the return behavior. It covers edge cases (no icon, homepage not fetchable), the source field, and the note, making it complete for an agent to call correctly.

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

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

The schema already provides 100% coverage with a clear description of the 'domain' parameter. The description does not add new parameter-level meaning beyond confirming that the domain is the site to fetch from. Baseline 3 is appropriate because the schema carries the semantic 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?

The description clearly states the tool's purpose: it returns the favicon URL a website declares. It specifies the resource (favicon URL), the verb (returns), and explains the fetching logic and fallback. This distinguishes it from the many lookup/check tools in the sibling list, which are all security or data lookups.

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 a clear use case ('Use it to display a site icon') and explicitly states what it does not do ('does not download or validate the image'), which implies when not to use it. However, it does not name any specific alternative tool or exclusion condition, so it falls 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 the operation read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those annotations by specifying the offline nature, the exact checksum algorithm, and the boundary of what 'validates' means here. This helps the agent set correct expectations about the tool's 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 short sentences deliver the key facts with no filler. The primary action and offline scope appear first, followed by the validation criteria and the important caveat about account existence. 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, read-only validation tool, the description is complete: it states the algorithm, the offline nature, and the limitation regarding account existence. The absence of an output schema is not a gap because the behavior of a boolean-style validation result is sufficiently implied by 'validates' and 'confirms'.

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

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

The input schema already documents the single parameter with 100% coverage, including that spaces are ignored. The description does not add further parameter-level meaning beyond the overall validation behavior, so a baseline score of 3 is appropriate.

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

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

The description starts with a specific verb and resource ('Validates an IBAN'), then defines the exact validation performed: ISO 7064 mod-97 checksum and country-specific length. It also explicitly distinguishes what the tool does not do ('not that the account exists'), making its purpose unambiguous relative to potential verification tools.

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

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

The description clearly establishes when to use this tool: for offline, format-level IBAN validation. The phrase 'Confirms the number is well-formed, not that the account exists' provides an important limitation, effectively telling an agent not to use this tool for account-existence checks, though it does not name an alternative tool for that 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?

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: it emphasizes that the tool uses a narrow list-based signal, includes the list date and attribution, and clarifies the IPv4-mapped IPv6 handling. This supplements the annotations with useful limitations and output details without contradicting them.

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

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

The description is two sentences long, with the primary action and scope stated first. It efficiently communicates the essential purpose and caveats without any filler. The IPv4-mapped clarification is relevant and front-loaded, and the overall structure is clean and easy to scan.

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

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

For a simple check tool with one parameter, the description is largely complete. It mentions that the response includes the list date and attribution, giving a hint of the output content. It does not detail the exact response structure, but given the absence of an output schema, the description provides enough context for an agent to understand what to expect. The annotations cover the operational safety profile, so nothing critical is missing.

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

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

The schema description coverage is 100% for the single 'ip' parameter, and the schema already explains the IPv4-mapped IPv6 behavior. The tool description repeats this and adds context about the list, but it does not introduce any new parameter semantics beyond what the schema provides. Since the schema fully covers the parameter, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: it checks an IP address against a curated list of known hijacked or cyber-crime-controlled netblocks. It also specifies the IPv4-mapped IPv6 behavior, which distinguishes it from generic IP tools. The purpose is unambiguous and distinct from sibling tools like url_reputation (which handles URLs) and address_risk (likely broader risk assessment).

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 provides a caveat that a clean result is not a safety guarantee, which implies it should not be used as a sole safety check. However, it does not explicitly state when to use this tool versus alternatives or name any specific sibling tool for comprehensive checks. The usage context is implied but not explicitly directed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction. The description adds valuable context beyond annotations: it explicitly warns that the signature is NOT verified, which is a critical behavioral trait for security-sensitive operations. This warning is essential for agents to avoid misusing the decoded claims. The description does not repeat annotation info but adds the non-verification caveat, which is significant.

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

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

The description is two sentences with zero wasted words. The primary purpose and critical caveat (non-verification) are front-loaded, and the alternative is named concisely. Every sentence serves a purpose.

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

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

Given the tool's simplicity (single parameter, no output schema, no nested objects), the description is complete. It covers purpose, usage guidance, and the key warning about signature verification. There is no missing information that an agent would need to call this tool correctly.

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

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

Schema coverage is 100% and the sole parameter `token` is adequately described in the schema (including the warning about non-verification). The description adds minimal extra meaning about the parameter beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the specific verb 'Decodes' and the exact resource ('a JWT's header and payload'), and immediately distinguishes itself from jwt_verify by emphasizing it does NOT verify the signature. This clearly differentiates it from the sibling tool jwt_verify, and the mention of 'header and payload' specifies the scope.

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

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

The description explicitly states when to use this tool (for decoding without verification) and when not to trust its output ('claims must not be trusted on this basis alone'). It names the alternative tool jwt_verify for checking authenticity, giving clear guidance on when to use the sibling instead.

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, covering the safety profile. The description adds that it checks exp/nbf claims and that the key format depends on algorithm, which is useful context. However, it does not disclose failure behavior (e.g., invalid signature or expired token) or what the tool returns, which would be expected for a verification 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 sentences carry all essential information: purpose with algorithm list, claim checks, parameter selection, and the alternative tool. The most important usage constraint is front-loaded, and there is no filler or redundant text.

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 verification tool with no output schema, the description should explain what result the agent can expect (e.g., boolean, error, or success indication). It also does not mention edge cases like exp/nbf failure handling. While the usage guidance is strong, the absence of return behavior and error semantics leaves a gap for correct invocation and interpretation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes further by explaining the relationship between algorithms and parameters (HS* needs secret, RS/PS/ES need JWK or JWKS URL), and the token schema description already echoes the alternative to jwt_decode. This adds value beyond the schema's individual field descriptions.

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 ('verifies') and resource ('JWT signature'), enumerates supported algorithms and claim checks, and explicitly distinguishes from jwt_decode by stating it is for when authenticity matters. This makes its purpose unmistakable and differentiates it from the sibling decode tool.

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

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

The description explicitly names jwt_decode as the alternative and conditions the choice on whether authenticity matters. It also gives concrete parameter selection guidance: 'Provide a secret for HS*, or a JWK or JWKS URL for RS/PS/ES.' This leaves no ambiguity about when and how to invoke the tool.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavior beyond that: it follows redirects, returns final_url, and explains that favicon_source distinguishes a page-declared icon from the /favicon.ico guess.

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 what is extracted, then redirect behavior, then the sibling routing hint. 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 correctly compensates by naming the return fields (final_url, favicon_source) and the redirect-following behavior. For a one-parameter read tool with rich annotations, an agent has everything needed to call it correctly.

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

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

There is a single parameter and schema description coverage is 100%, so the schema already documents the url param fully; the description's phrasing mirrors the schema text rather than adding format/validation detail. Baseline 3 is appropriate when the schema does the work.

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 gives a specific verb (fetches/extracts) and a concrete resource list (title, description, canonical URL, Open Graph/Twitter Card tags, favicon) and frames it as 'the data behind link previews', which immediately separates it from the sibling favicon tool that deals only with icons.

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

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

It explicitly routes the agent to redirect_trace when per-hop redirect detail is needed, which is a clear when-to-use-this-instead signal. It does not similarly differentiate from favicon or security_headers, so the guidance is solid but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it explains the heuristic nature ('a heuristic for review, not proof'), the specific time windows (180+ days, 365 days), and the exclusions. It also discloses a limitation (does not detect hijacked existing accounts). This is strong behavioral disclosure for a heuristic 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?

The description is dense but every sentence earns its place: scope, trigger condition, exclusions, and limitations are all covered in three sentences. The most important scoping constraint ('npm only') is front-loaded, and the heuristic caveat is placed at the end where it belongs.

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 heuristic tool with two fully documented parameters and no output schema, the description is complete. It tells the agent what triggers a flag, what is excluded, what the tool cannot do, and how to interpret results ('heuristic for review, not proof'). Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the 'npm only' constraint, which reinforces the ecosystem parameter's meaning, but it doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb ('flags'), a precise resource (a previously unseen human publisher taking over a package after 180+ days of inactivity within the last 365 days), and names the exact attack pattern (event-stream). It clearly distinguishes itself from generic supply-chain checks by naming the specific heuristic and its scope ('npm only').

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

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

The description explicitly states when to use this tool ('npm only') and what it does not do ('Does not detect hijacked existing accounts'). It also names exclusions from flagging (trusted publishing, pre-release, handovers to a publisher who already maintains another widely used package). This gives an agent clear routing guidance relative to siblings like supply_chain_check and typosquat_check.

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

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

The description says the tool generates a 'random' password, which contradicts the provided idempotentHint=true annotation because repeated calls with the same parameters will not produce the same password. This is an Annotation Contradiction. Aside from that, the description mostly restates the schema options and does not disclose return format or other behavioral details.

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

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

The description is two short sentences with no filler. The primary behavior is front-loaded, and the alternative tool is mentioned in a separate concise sentence that adds clear value.

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 tool with no required parameters and full schema coverage, the description is mostly sufficient. The main gaps are that it never states the return format (presumably the generated password string) and uses the vague phrase 'reasonable secure length' instead of a concrete default.

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 input schema already documents all five parameters. The description only lists the option names without adding types, defaults, or value formats beyond what the schema provides, so it meets the baseline but nothing more.

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

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

The description states a specific action and resource: 'Generates a random password'. It also names the option categories (length, symbols, uppercase, numbers, ambiguous characters) and explicitly differentiates the tool from password_check by noting that the latter evaluates existing passwords.

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

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

The second sentence gives an explicit routing rule: use password_check when evaluating an existing password, implying the current tool is for generation. This clearly tells an agent when to choose this tool versus the most relevant sibling.

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?

Description discloses the k-anonymity mechanism, that only a 5-character SHA-1 prefix is sent, and that the full password still travels in the URL. This adds valuable behavioral and privacy context beyond the annotations, which already declare read-only, idempotent, and non-destructive. No 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?

Two tight sentences with the core behavior front-loaded and the sibling distinction second. No filler; each sentence earns its place.

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

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

The agent gets everything needed to select and call the tool: purpose, privacy caveat, alternative tool guidance, and sufficient output meaning (existence and count). Annotations cover the safety profile, and the single parameter is fully documented.

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

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

Schema fully documents the single parameter, including transmission mechanics and the warning to prefer password_check for real passwords. The description reinforces this with concrete terms like 'only a 5-character SHA-1 hash prefix' and 'k-anonymity', going beyond a bare type declaration.

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

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

States a specific action (checks breach appearance and count) against a named resource (HIBP). Explicitly distinguishes itself from password_check as breach-only. An agent can identify its function 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?

Directly names password_check as the alternative and gives the deciding factor: password_check adds strength scoring and uses POST. Also warns that real passwords should not be sent in the URL, telling the agent when to prefer the sibling.

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 useful behavior beyond that: breach lookup uses k-anonymity with only a hash prefix transmitted, the password travels in a POST body rather than a URL, and any breached password is deterministically rated very_weak regardless of other factors. It stops short of describing the scoring scale or return shape, 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?

The core function is front-loaded in the first clause, and the routing/privacy sentences follow. The single paragraph is dense with no filler; it runs slightly long, but every clause carries information an agent would otherwise have to infer.

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 tool with no output schema, this covers purpose, alternatives, privacy/transport, and the deterministic breach rule — enough to invoke and interpret it correctly. The only gap is that it never characterizes the returned score (numeric range, label set) or the breach count, which the agent will have to discover from the response.

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, but the description adds real meaning beyond the schema: check_breach isn't just 'check against breach corpora' — it specifies the k-anonymity mechanism and the hard rule that a breach hit forces a very_weak rating. That materially changes how an agent should interpret the result.

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 ('Scores a password's strength') and enumerates the factors used (length, character variety, entropy as an upper bound, repeated patterns, per-word passphrase estimation). It also differentiates itself from the adjacent siblings password_breach and password, so an agent can select it without opening any schema.

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

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

Explicit routing: 'Use it to evaluate a password someone is choosing; use password_breach when you only need the breach count, and password to generate a new one.' This names both alternatives plus the condition that selects each, which is exactly the when-to-use guidance an agent needs.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context: it enumerates what verification returns and explains why 'country' cannot be inferred in the MCP environment, which goes beyond the structured fields.

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

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

Two compact sentences, with the core action and outputs front-loaded and the important conditional requirement stated immediately. Every sentence earns its place; there is no filler.

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

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

Despite the absence of an output schema, the description lists the expected result categories, and the input schema covers both parameters. The main gap is error behavior for invalid numbers, but for a read-only verification tool with full parameter coverage, the definition 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 coverage is 100%, so the schema already documents both parameters. The description essentially restates the conditional requirement for 'country' rather than adding new semantic detail, matching the baseline of 3.

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

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

The description uses a specific verb ('Validates and formats') plus a precise resource ('a phone number') and enumerates concrete outputs: validity, country, line type, E.164, international and national formats. Even among many sibling validation tools, the phone-specific scope makes it 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 makes the main usage condition explicit: numbers without a leading '+' require the 'country' parameter, because the end user's country cannot be inferred over MCP. It does not name alternatives or exclusions, but the tool's purpose and conditional prerequisite are clear enough for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context: the 15-hop limit and the specific return data (each hop's status code and domain-crossing flag). It doesn't mention network side effects, but for a read-only tool that's acceptable. No contradictions.

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

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

Two sentences with no wasted words. The first sentence front-loads the core functionality and constraints (15 hops, status codes, domain crossing), and the second gives a practical use case plus a pointer to a sibling tool. Efficient and well-structured.

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

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

Given there is no output schema, the description adequately describes what the tool returns (every hop with status code and domain-crossing flag). It also mentions the hop limit and a use case. It doesn't detail error handling or the exact response structure, but for a one-parameter read-only tool, this is sufficient. A 4 is fair because it covers the essentials without being exhaustive.

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 URL parameter is fully described ('URL to follow the full redirect chain for, hop by hop'). The description adds the hop limit and output details, but these are behavioral facts, not parameter semantics. Since the schema already documents the only parameter, the description doesn't need to compensate, and a baseline 3 is appropriate.

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

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

The description states a precise action ('follows a URL's full redirect chain') with a clear resource (URL) and limits (up to 15 hops). It also distinguishes itself from siblings like url_reputation and url_clean by explicitly mentioning the output (each hop's status code and domain crossing) and its intended use case (seeing where short or tracking links lead).

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

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

It provides a concrete use case ('use it to see where a short or tracking link really leads') and a complementary follow-up ('check the final URL with url_reputation'), which implies when this tool is appropriate versus alternatives. However, it doesn't explicitly state when not to use it or name direct alternatives beyond the reputation check, so it misses some exclusionary 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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details beyond annotations: it lists the exact signals returned and states that missing or private repositories return found:false, which is not inferable from the annotations. No 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?

Three compact sentences, each earning its place: the first enumerates outputs, the second states the intended use case, and the third handles scope and edge behavior. No filler or redundant phrasing; the most important information is front-loaded.

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

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

For a simple read-only tool with a single well-documented parameter and no output schema, the description adequately substitutes for return-format documentation by naming all returned signals and the found:false edge case. The annotations cover safety, and the description covers behavior and usage completely.

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

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

The schema already fully documents the single param 'repo' as a GitHub repository in owner/name format with the lodash/lodash example. The description merely repeats this format and adds no new semantic meaning beyond the schema, so the baseline of 3 for 100% schema coverage is appropriate.

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

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

The description states a specific verb and resource: it returns maintenance signals for a GitHub repository, enumerating exact data points such as stars, forks, open issues, license, flags, dates, and topics. It also differentiates itself from supply_chain_check by scope, making it clear this is the GitHub-only variant.

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

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

It explicitly says when to use the tool: to judge whether a dependency looks maintained or abandoned. It names the alternative supply_chain_check for npm/PyPI packages with unknown repos, and clarifies the GitHub-only constraint and the found:false result for missing/private repos. This gives agents clear routing guidance.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds crucial context: it never calls unsafe methods and infers exposure from route listing. This is valuable beyond the annotations and reassures the agent about safety.

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

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

The description is two sentences, front-loaded with the core purpose (

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

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

Given the tool has one parameter with full schema documentation and output schema absence, the description provides sufficient context for an agent to understand what it does and how it operates. It covers the essential behavioral aspects (read-only, never calls unsafe methods) but does not detail the exact output format, which may be a minor gap but not critical given the simplicity.

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

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

The schema description for the 'url' parameter already explains what it is (base URL of CometBFT RPC endpoint) and provides an example. The description reinforces this and mentions the purpose, but does not add new semantic meaning beyond the schema. Since the schema coverage is 100%, baseline of 3 is appropriate.

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

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

The description explicitly states the tool performs a read-only audit of a CometBFT RPC endpoint, listing specific aspects (node status, health, peers, unsafe admin method exposure). It clearly distinguishes itself from sibling tools by focusing on a specific technical stack and audit purpose.

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 indicates the tool's purpose and scope, implying it should be used when auditing a CometBFT RPC endpoint. However, it does not explicitly state when not to use it or mention alternatives, but given the sibling tools are mostly unrelated, the usage context is clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds value by specifying the return structure (per-header findings, fix advice, score, grade), which is not covered by annotations or a schema. There is no contradiction and the description is consistent with the read-only, idempotent nature.

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

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

The description is two sentences with no redundancy. The first sentence immediately states the action, scope, and output; the second gives usage guidance and differentiates from a sibling. Every word earns its place, and key 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 single-parameter, read-only audit tool with no output schema, the description is complete. It explains what the tool does, what it returns (findings, advice, score, grade), and when to use it. There are no prerequisites or caveats that an agent would need to know. The lack of output schema is compensated by the description's mention of the output structure.

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

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

The schema description covers the url parameter fully (100% coverage), explaining it is the URL to audit for security headers. The tool description repeats the same header list but adds no new meaning or format guidance. Since schema already does the heavy lifting, the baseline of 3 is appropriate.

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

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

The description clearly states it audits HTTP security headers of a single URL, enumerates the header categories (CSP, HSTS, X-Frame-Options, etc.), and specifies the output: per-header findings with fix advice, a score, and a letter grade. This distinguishes it from the sibling security_scan by explicitly noting the scope difference, making the tool's purpose 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?

It provides explicit guidance: 'Use it when you need header hardening advice' and contrasts it with security_scan, which combines this audit with URL reputation and subdomain discovery. This tells the agent exactly when to choose this tool over an alternative.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds that the checks run in parallel and produce an overall score and verdict, providing useful functional context beyond the annotations. No contradiction found.

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

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

The description is two sentences: the first front-loads the core purpose and behavior, the second provides usage guidance. Every sentence earns its place with no redundancy or unnecessary 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?

With one parameter, full schema coverage, and strong annotations, the description adequately explains the tool's function, its parallel execution, and the output of an overall score and verdict. While it doesn't detail the exact response format, that's not required given the simplicity of the tool.

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

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

Schema description already covers the URL parameter and mentions 'combined security posture check (headers, reputation, and related signals)'. The tool description adds minimal extra detail beyond what the schema already provides, so it meets the baseline for 100% coverage without significantly enriching parameter meaning.

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

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

The description clearly states the tool performs a combined website check covering security headers, URL reputation, and passive subdomain discovery, with an overall score and verdict. It explicitly differentiates from siblings by directing use of individual tools for single signals, so an agent can easily distinguish it.

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 explicit usage guidance: use this combined tool for an overall security posture check, and use individual tools when only a single signal is needed. This directly tells the agent when to choose this tool versus the alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds valuable behavioral context beyond annotations: it explains the data source (crt.sh), the passive nature of the discovery, the limitation (only hostnames in public TLS certificates, not all DNS records), and the reliability caveat (crt.sh is occasionally slow or unavailable). This is meaningful additional 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 with zero waste. The core purpose is front-loaded, the limitation is stated immediately, and the reliability caveat is a single short sentence. Every word earns its place.

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

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

For a single-parameter, read-only, idempotent tool with no output schema, the description is nearly complete. It explains the data source, the scope of results, and the reliability caveat. The only minor gap is that it doesn't describe the output format, but with no output schema and a simple single-parameter tool, this is a minor omission.

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 fully documents the single 'domain' parameter. The description reinforces the parameter's meaning by giving an example ('example.com') and explaining what the domain is used for. However, it doesn't add significant new semantic detail beyond the schema, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('discovers'), a specific resource ('subdomains'), and a specific method ('from Certificate Transparency logs via crt.sh'). It also explicitly distinguishes itself from DNS record enumeration by noting it finds hostnames in public TLS certificates, not every DNS record. This clearly differentiates it from the sibling dns_lookup tool.

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

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

The description clearly implies when to use this tool: when passive subdomain discovery from certificate transparency is desired, and explicitly notes it is not a full DNS enumeration tool. It doesn't name alternative tools explicitly, but the contrast with 'not every DNS record' and the sibling dns_lookup provides clear context. It also warns about crt.sh availability, which helps an agent decide whether to use 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?

With readOnlyHint/idempotentHint already covering the safety profile, the description still adds substantial behavior: it enumerates the possible overall_risk outcomes (package_not_found, review_recommended, incomplete, no_signals_found), the 30-day new_package threshold, the PyPI oldest-release nuance, and version_checked/version_source semantics for when a check could not run. It leaks some of its own vocabulary, but the agent gains a clear picture of failure modes and verdicts.

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

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

Well front-loaded: the call-to-action ('call this before installing...') opens the description. The prose is dense with load-bearing detail rather than filler, though the parenthetical on PyPI age and the 'being new does not make it malicious' caveat stretch the length beyond the essential triggers.

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, yet the description documents the return contract in enough detail for an agent to act on it: what package_not_found implies (do not install), what new_package/review_recommended mean, and how a partial run surfaces as incomplete. Nothing needed to call or interpret 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining how version is resolved (version_checked, version_source, latest fallback) and that maintainer_change_check only runs for npm. That is more than the schema's bare field descriptions offer.

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 ('risk check') and resource (package supply chain) and explicitly defines itself as an aggregate of four named sibling tools (vulnerability_check, typosquat_check, maintainer_change_check, repo_health_check). An agent can distinguish it from the individual signal 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?

States the trigger condition precisely ('before installing or adding a package... especially one whose name you recalled or that a model suggested') and names the alternative path ('Use the individual tools to investigate one signal'). It routes the agent between aggregate and per-signal usage without inference.

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

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

Annotations already declare read-only and idempotent behavior. The description adds meaningful behavioral detail: the algorithm type, the one-text vs two-text behavior, detection of paraphrased/edited copies, and the expected baseline score for unrelated texts. No contradiction with 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 dense sentences with no filler. The core algorithm and usage modes are front-loaded, and every clause contributes useful information.

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

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

For a one-parameter tool with no output schema, the description covers both invocation modes and the expected score behavior. It stops short of specifying exact output formatting (e.g., hash encoding or score range), but is sufficient for correct invocation.

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

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

Schema coverage is 100%, and the description largely restates the schema's guidance about 1 or 2 texts and the 200,000-character limit. It adds algorithmic context but no additional parameter-specific meaning beyond what the schema already provides.

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

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

The description names a specific operation ('near-duplicate detection') and a concrete mechanism (64-bit SimHash over word shingles), then defines the two call modes. This clearly distinguishes it from the unrelated sibling utilities.

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

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

The description clearly states when to use the tool: send one text for a hash or two texts for comparison. It does not explicitly name alternatives or exclusions, but the sibling tools are all unrelated, so the intended context is clear.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond the schema by explaining the default behavior when neither parameter is provided (returns current time) and the conversion direction. It doesn't cover edge cases like invalid input, but that's a minor gap for a simple utility.

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 primary purpose and then gives parameter guidance. Every word earns its place; there is no redundancy or filler.

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

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

For a simple, read-only utility with full schema coverage and safety annotations, the description is complete. It explains both modes of operation and the default behavior, which is all an agent needs to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the 'or neither' default behavior, but doesn't provide additional syntax or format details beyond what the schema states. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: returns the current time, or converts between Unix timestamp and ISO date. It clearly distinguishes the tool's dual function and is unambiguous among the sibling tools, none of which handle time 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 gives clear invocation context: provide unix, date, or neither. It doesn't explicitly mention alternatives or exclusions, but no similar sibling exists, so the guidance is sufficient for an agent to know when to use 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 readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is handled. The description adds valuable behavioral context beyond annotations: it discloses that Bank, staking, gov, and authz messages are fully decoded while other types are returned as type URL plus raw hex, which is crucial for interpreting output.

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

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

The description is two sentences with zero waste. The main action is front-loaded, and the second sentence provides necessary nuance about partial decoding. 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?

There is no output schema, so the description carries the burden of explaining return values. It specifies the JSON fields (messages, fee, gas, signers, signatures) and the partial decoding behavior for different message types. For a single-parameter read-only tool, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents the 'tx' parameter as base64-encoded Cosmos SDK TxRaw protobuf bytes from CometBFT RPC endpoints. The description adds minimal extra meaning by mentioning the source as 'CometBFT block's data.txs,' which is similar to the schema text. Baseline 3 applies since the schema carries the semantic 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 'Decodes' and a resource 'raw signed Cosmos SDK transaction' and specifies the output 'JSON: messages, fee, gas, signers and signatures.' It is clearly distinct from sibling tools like jwt_decode or base64, so an agent can tell it apart without needing to open 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?

The description implies usage by specifying the exact input format (base64 TxRaw bytes from CometBFT) but does not explicitly state when to use this tool vs alternatives or when not to use it. Since no sibling tool performs a similar function, explicit alternatives are not needed, but the wording leaves usage guidance implied 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 read-only, idempotent, non-destructive behavior, so the bar is lower, yet the description still adds substantive behavior: an edit-distance threshold scaled to name length, a >=3-character matching cutoff, and a curated-list limitation warning that a clean result does not prove safety. It also discloses a negative scope (does not verify existence), which is exactly the kind of boundary 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?

Three sentences, each earning its place: the first is the call trigger, the second the mechanism, the third the caveat plus the hand-off to supply_chain_check. Front-loaded with the action, no filler.

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

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

For a two-parameter, read-only lookup with no output schema, the description supplies everything an agent needs: when to call, how the check works, its precision limits, and where to go for the complementary existence check. Return-value semantics are implied ('a clean result does not prove a package is safe').

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 both parameters, so the baseline is 3; the description earns a step above by naming the concrete ecosystems ('npm or PyPI') and framing the package parameter as the name to be fuzzy-matched in that ecosystem, which reinforces the pairing between the two required params.

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 package name is a near-miss of a well-known package, i.e. typosquatting) and scopes it to npm or PyPI. It also explicitly demarcates itself from the sibling supply_chain_check, so an agent can route without opening either schema.

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

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

Gives an explicit trigger ('Call before installing a package whose name you typed or recalled'), a when-not edge case (names of 3 characters or fewer are not fuzzy-matched), and names the alternative tool for the adjacent question (existence) via supply_chain_check. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the non-redirect behavior, which is a meaningful behavioral trait not in the annotations. It aligns with the annotations, so no 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?

Two sentences with zero redundancy. The core action is front-loaded, and the alternative is mentioned in the second sentence. Every word earns its place.

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

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

For a simple, single-parameter transformation tool, the description fully covers what an agent needs: the operation, the specific parameters removed, and the redirect caveat. No output schema exists, but the behavior is simple enough that an agent can predict the result.

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

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

Schema coverage for the single parameter is 100%; the schema description already states the parameter's purpose and examples. The tool description adds no additional semantic detail beyond what the schema provides, so a baseline 3 is appropriate.

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

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

The description states a precise verb and resource ('Removes 60+ known tracking parameters from a URL and returns the clean URL') and immediately differentiates from a sibling by naming redirect_trace as the alternative for following redirects. An agent can distinguish it from the large sibling list without opening 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?

It explicitly says 'Does not follow redirects; for that, use redirect_trace,' which provides a clear when-not-to-use condition and names the alternative. This is above the bar for usage 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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and side effects. The description adds meaningful behavioral context beyond annotations by explicitly stating that a clean result does not imply safety, reinforcing the open-world nature and preventing over-reliance on a negative result.

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

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

Two sentences with no filler. The action is front-loaded in the first sentence, and the second sentence adds an essential caveat. Every word earns its place.

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

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

For a simple, single-parameter, read-only lookup with comprehensive annotations, the description is nearly complete. It lacks explicit return format details, but the absence of an output schema is not a major gap given the simplicity and the clear caveat about result interpretation.

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, which is described as 'URL to check against known phishing/malware URL databases.' The description adds the specific database (URLhaus) but does not introduce new semantics beyond what the schema conveys. 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?

Description clearly states a specific verb ('checks'), resource ('URL'), and target database ('URLhaus (abuse.ch)'), immediately distinguishing it from siblings like ip_reputation or vulnerability_check. The caveat about clean results reinforces the specific scope.

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: an agent can infer when to use this tool (when a URL reputation check against URLhaus is needed), but there is no explicit guidance on when to prefer this over alternatives like security_scan or url_clean, nor exclusions. The description does state the interpretive caveat, but it is not about tool selection.

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

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds a useful nuance by saying the bot result is based on appearance ('looks like a bot'), but it doesn't disclose other operational details such as fallback behavior for unparseable inputs or 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?

The entire description is one front-loaded sentence with no filler. It packs the action, input, and output categories without repeating the parameter schema.

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

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

For a single-parameter, read-only parser, the description covers the invocation purpose and the main output categories despite the lack of an output schema. It could be slightly more complete by addressing unknown/unparseable values, but nothing essential is missing for calling the tool.

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

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

Schema description coverage is 100%, so the input parameter is already fully documented; the description adds no separate parameter semantics. The schema's note about the server not seeing the end user's User-Agent is strong, but it comes from the schema, not the tool description.

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

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

The description uses a precise verb ('Parses') and names both the resource (User-Agent string) and the concrete outputs (browser/version, OS/version, device type, bot-like flag). It does not explicitly distinguish itself from sibling tools such as ai_crawler_check, but the parse-focused resource makes the purpose 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 purpose implies the main use case: pass a User-Agent string to get parsed details, and the schema adds the necessary 'server cannot see UA' note. However, there is no explicit statement of when to prefer this over sibling tools or when not to use it for bot classification.

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

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

The description discloses that outputs are random, but the annotations include idempotentHint=true, implying repeated calls with the same parameters should produce the same result. Random UUID generation contradicts that, so the description conflicts with structured metadata.

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

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

One clean sentence with no filler. The verb and the core behavior are front-loaded, and every word contributes meaning.

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

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

For a zero-required-parameter utility, the description covers purpose, output type, and count range. It does not explicitly describe the return shape for multi-UUID calls, but the output is fairly self-evident; with no output schema, slightly more return detail would be helpful but is not critical.

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

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

Schema coverage is 100%, so the schema already documents the count parameter and its default. The description adds the valid range 1-100, which is useful and not in the schema, but it does not clarify that the parameter is typed as a string or describe any formatting expectations beyond that.

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

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

The description uses a specific verb ('Generates') and resource ('random UUID v4 values') and even states the supported count range (1 to 100). It is immediately clear what the tool does and it stands apart from sibling utilities like base64 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?

No explicit when-to-use or alternative tool is mentioned, but for a simple standalone UUID generator the use case is obvious. The description does not provide exclusions or sibling comparisons, so it stops at implied usage.

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, indicating a safe, read-only operation. The description adds valuable context: the real-time nature, reliance on VIES, occasional unavailability for some member states, and that it returns company name and address when valid. This goes beyond annotations and helps set expectations about availability and output.

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

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

The description is two sentences, with no filler. The core action and output are front-loaded, and the note about VIES availability is a concise, useful addition. 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?

Given there is no output schema, the description correctly explains the success return (company name and address). It also notes potential service unavailability. However, it does not mention what happens on invalid VAT numbers or when VIES is unavailable (e.g., error messages, fallback behavior). These are minor gaps, but for a real-time external service, a bit more detail would be helpful.

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 explains both 'vat' and 'country' parameters. The description does not add extra semantic detail beyond the schema; it only repeats that the VAT number can include a prefix and country is optional. According to the rubric, when schema coverage is high, the description need not duplicate parameter info, 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?

The description clearly states the tool's function: checking an EU VAT number against the VIES service and returning company details. It uses a specific verb ('Checks') and identifies the resource (EU VAT number) and service (VIES). This distinguishes it from validation siblings like iban_validate or email_validate, which operate on different data types.

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 indicates when to use this tool: for EU VAT number validation against VIES. It does not explicitly state when not to use it or mention alternative tools, but the purpose is unambiguous. The context signals list many validation tools, but none are direct competitors, so the absence of explicit exclusions is acceptable.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by naming the external data source (OSV.dev) and clarifying that it checks for known vulnerabilities, which sets expectations about external dependency and scope. It does not mention return format or rate limits, but that is not critical 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?

The description is two sentences with zero filler. The first sentence front-loads the core function and scope, and the second sentence provides routing to alternatives. Every word earns its place.

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

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

For a read-only query tool with three well-documented parameters and safety annotations, the description is nearly complete. It covers purpose, supported ecosystems, optional version behavior, and alternatives. The only minor gap is that it does not hint at the return value shape (e.g., list of CVEs or severity), but that is not essential 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%, so the input schema already documents all three parameters (package, version, ecosystem) with clear descriptions. The description adds minimal extra meaning beyond the schema, mostly restating the optional version behavior and listing ecosystem examples. Baseline 3 is appropriate because the schema carries the semantic 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?

The description states a specific verb ('Checks'), a clear resource ('a package against OSV.dev'), and the exact scope ('known vulnerabilities') with an explicit list of supported ecosystems. It also names sibling tools (cve_lookup, supply_chain_check) to distinguish itself, so an agent can tell them apart immediately.

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

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

The description explicitly tells the agent when to use this tool versus alternatives: 'Use cve_lookup when you already have a CVE/GHSA ID, or supply_chain_check for a combined verdict.' This is direct routing guidance with no ambiguity.

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 carry readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the description adds value by naming the RDAP source and expected fields. It does not discuss potential rate limits, failures, or formatting nuances, but with rich annotations the burden is lower.

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: the first front-loads the purpose and output fields, the second provides a clear sibling alternative. 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 one-parameter read-only tool with no output schema, the description gives enough field-level expectations for an agent to interpret the result and names the correct sibling. It stops short of describing edge cases like missing domains or RDAP availability, but those are minor given the annotations.

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

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

The schema already fully documents the single domain parameter (100% coverage). The description reinforces that it is a domain for registration details and gives an example, but adds no new syntax or format semantics beyond the schema.

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

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

States a specific action (look up) and resource (domain registration data via RDAP), and enumerates concrete data points (registrar, dates, age, nameservers). It also distinguishes itself from the sibling dns_lookup by clarifying it covers registration data rather than DNS records.

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 agents to dns_lookup when DNS records are needed, and clearly implies this tool is for registration details. This is an explicit alternative with a condition, leaving no ambiguity about when to choose it over the closest sibling.

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