Server Quality Checklist

Tool Scores

• base64_encodeA
  4.3/5.0
  Behavior5/5

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

  No annotations are provided, so the description fully carries the burden. It explicitly states 'Pure local encoding with no network calls' and 'Always succeeds for valid UTF-8 input', covering safety and reliability. The encoding alphabet and return format are also specified, leaving no ambiguity about behavior.

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

  Conciseness4/5

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

  The description is a single, coherent paragraph that front-loads the core action, then provides usage guidance and behavioral details. Every sentence contributes value, but it could be slightly tighter by combining the usage and warning sentences.

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

  Completeness4/5

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

  The description covers return value and success condition, but lacks mention of error handling for non-UTF-8 input. Given no output schema and the simplicity of the tool, this is a minor gap. Overall, it is fairly complete.

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

  Parameters3/5

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

  The input schema already has 100% coverage with a clear description of the required 'input' parameter. The description adds little beyond restating that it is a UTF-8 string, which is already in the schema. Therefore, 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.

  Purpose5/5

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

  The description clearly states the action ('encode a UTF-8 plaintext string'), the resource ('string'), and specifies the standard (RFC 4648 §4, +/= alphabet). It also distinguishes from sibling tools like url_encode and base64_decode by focusing on Base64 encoding, and even contrasts with URL-safe Base64.

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

  Usage Guidelines4/5

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

  The description provides explicit use cases: 'use when you need to embed binary-safe text in HTTP headers, data URIs, or JSON payloads'. It also includes a note about when this tool is not suitable (if URL-safe Base64 needed), but does not name a specific sibling tool for that purpose, so it misses the highest score.

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

• url_decodeA
  4.3/5.0
  Behavior4/5

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

  Without annotations, the description fully covers behavior: pure local decode via decodeURIComponent, no network calls, success returns decoded string, failure returns error message. It also clarifies handling of both encoding formats. This is sufficient transparency.

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

  Conciseness5/5

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

  The description is four sentences, each serving a purpose: action, use cases, implementation detail, and failure mode. It is front-loaded with the primary action and wastes no words.

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

  Completeness5/5

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

  For a simple tool with one parameter, no output schema, and no annotations, the description covers all necessary context: what it does, when to use, how it works, and what happens on failure. It is complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both schema and tool description provide examples and guidance (e.g., 'Pass only the encoded component, not a full URL'). The tool description adds a small extra nuance beyond the schema, but not significantly.

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

  Purpose5/5

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

  The description clearly states the verb 'Decode' and specific resource 'percent-encoded URL component', with examples of use cases (query parameters, path segments, form-encoded values). It is distinct from siblings like url_encode, base64_decode, and jwt_decode.

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

  Usage Guidelines4/5

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

  The description explicitly says when to use this tool: to read query parameters, path segments, or form-encoded values. It also notes that it accepts both + and %20 encodings. However, it does not mention alternatives or when not to use it, but the sibling list provides implicit distinction.

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

• dossier_dkimA
  4.4/5.0
  Behavior4/5

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

  Without annotations, the description fully discloses behavior: parallel Cloudflare DoH TXT queries per selector, 5 s timeout, and the output structure (CheckResult). It does not explicitly declare read-only status, but the nature of probing implies non-destructiveness. The description adds valuable behavioral context beyond what annotations would provide.

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

  Conciseness5/5

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

  The description is concise at three sentences, each serving a distinct purpose: action/query pattern, usage guidelines, technical details/output. No redundant information; every sentence earns its place.

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

  Completeness4/5

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

  Given the lack of output schema, the description adequately explains the return value (CheckResult with fields). It covers domain validation, default selectors, parallel query behavior, and timeout. For a tool with 2 parameters, this is complete; however, it could mention potential errors (e.g., domain not resolvable) more explicitly.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description adds significant meaning: explaining that selectors are optional with a default set, and adding domain validation rules ('Must be resolvable on the public internet; IPs, ports, etc. rejected'). It also lists the default selectors, which is not in the schema.

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

  Purpose5/5

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

  The description clearly specifies the action ('Probe a domain's DKIM public keys'), the resource (domain), and the method (querying <selector>._domainkey.<domain>). It distinguishes from siblings like dossier_spf and dossier_dmarc, and explicitly states the use case ('verify signing configuration or discover active selectors').

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

  Usage Guidelines4/5

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

  The description provides clear guidance on when to supply selectors vs omit, and explains the default selectors. It also includes prerequisites (domain must be a public FQDN). However, it does not explicitly state when not to use this tool or mention alternatives among siblings.

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

• dossier_dmarcA
  4.4/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses key behavioral traits: queries via Cloudflare DoH with 5s timeout, parses tag=value pairs, and specifies return format (CheckResult with success/error). This is fairly transparent for a read-only tool.

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

  Conciseness5/5

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

  Three focused sentences: purpose, usage context, technical details. No redundant words; front-loaded with the core function. Every sentence earns its place.

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

  Completeness4/5

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

  The tool is simple (one param, no output schema). The description covers what, how, and return format. Could mention potential errors or rate limits, but the 5s timeout and error reason in response partially mitigate. Complete enough for effective use.

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

  Parameters3/5

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

  The schema description already covers the one parameter well (public FQDN, restrictions). The description adds minor value by reiterating the constraint but does not significantly expand beyond schema. With 100% schema coverage, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Retrieve and parse') and distinctly identifies the resource (DMARC policy from _dmarc.<domain> TXT record). It also distinguishes from sibling tools by explicitly mentioning pairing with dossier_spf and dossier_dkim.

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

  Usage Guidelines5/5

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

  Provides explicit use cases: 'audit email authentication policy, verify p and rua settings, confirm alignment mode.' Suggests pairing with sibling tools for complete coverage, guiding the agent on when to use this tool versus alternatives.

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

• base64_decodeA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully covers behavior: it is a pure local decode with no network calls, validates UTF-8, and returns either decoded string or error message on failure (invalid Base64 or non-UTF-8 bytes).

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

  Conciseness5/5

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

  Three sentences that first state purpose, then usage and format details, then behavior and error handling. No wasted words, well front-loaded.

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

  Completeness5/5

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

  For a simple tool with one parameter and no output schema, the description is comprehensive. It covers input format, decoding process, validation, output type, and error cases.

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

  Parameters3/5

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

  The schema already provides a complete description of the 'input' parameter (100% coverage), including acceptable alphabets and optional padding. The description does not add new parameter-specific details beyond what the schema offers.

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

  Purpose5/5

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

  The description clearly states the action ('Decode a Base64 or Base64url string'), the resource, and the output ('original UTF-8 plaintext'). It distinguishes itself from the sibling 'base64_encode' by being the inverse operation.

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

  Usage Guidelines4/5

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

  Provides explicit use cases ('inspect encoded payloads, credentials, or embedded data') and mentions acceptance of both alphabets and padding. However, it does not explicitly mention when not to use it or alternatives beyond the reverse operation.

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

• dossier_corsA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool performs a single OPTIONS request via fetch with a 5-second timeout, returns a CheckResult with status and reason on failure. It also explains defaults when origin/method are omitted. However, it does not mention potential side effects (none expected) or error handling beyond the generic reason field.

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

  Conciseness5/5

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

  The description is concise: two sentences, no redundant wording. It front-loads the core action ('Send a CORS preflight...') and then provides usage guidance and behavioral details efficiently.

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

  Completeness5/5

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

  Given the tool's simplicity (3 parameters, no nested objects, no output schema), the description adequately covers purpose, parameters, behavior, and output format. It also mentions the specific HTTP method and timeout, leaving no major unknowns.

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

  Parameters4/5

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

  The input schema already has 100% description coverage. The description adds value by specifying that domain must be a public FQDN and rejecting IPs, ports, etc., and by explaining the defaults for origin and method. This provides clarity beyond the schema's basic descriptions.

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

  Purpose5/5

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

  The description clearly states it sends a CORS preflight OPTIONS request and returns access-control-* headers, using specific verbs ('Send', 'verify', 'check'). It distinguishes itself from sibling tools like dossier_dns or dossier_tls by focusing exclusively on CORS policy verification.

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

  Usage Guidelines4/5

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

  The description explicitly indicates when to use the tool: 'verify CORS policy' or 'check whether a domain allows cross-origin requests'. It also explains how to customize the preflight by providing origin and method, or omitting them for defaults. While it doesn't list explicit alternatives, the sibling tools are clearly in different domains (DNS, headers, etc.), so the context is sufficiently clear.

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

• dossier_mxA
  4.5/5.0
  Behavior4/5

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

  Without annotations, the description discloses key behaviors: queries Cloudflare DoH, follows CNAME aliases, 5s timeout, and return format (discriminated union with success/error). Could additionally mention any rate limiting or idempotency, but overall strong.

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

  Conciseness5/5

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

  Three sentences with no redundancy. Purpose, usage guidance, and technical details are efficiently front-loaded and each sentence earns its place.

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

  Completeness5/5

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

  For a simple tool with one parameter and no output schema, the description covers everything needed: purpose, behavior, return structure, and usage context. No gaps given the complexity.

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

  Parameters3/5

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

  Schema description coverage is 100% for the only parameter (domain), and the tool description repeats this. The schema explains the domain format thoroughly, so the description adds little beyond the already complete schema.

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

  Purpose5/5

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

  The description clearly states the tool's action (look up MX records) and result (sorted by priority). It distinguishes from sibling tools like dns_lookup and other dossier_* tools by specifying that this returns a ranked view, not raw DNS.

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

  Usage Guidelines5/5

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

  Explicitly states when to use (verifying inbound-mail routing, precursor to SPF/DMARC) and when not (prefer dns_lookup for raw answer). Provides an alternative sibling tool, which is exemplary.

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

• dossier_redirectsA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: follows Location headers with fetch (no auto-redirect), 5s per hop, and stops at 10 hops to prevent infinite loops. It also details the return format (CheckResult with success/error).

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

  Conciseness5/5

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

  Three sentences, each serving a distinct purpose: what it does, when to use, and how it behaves. No redundant words; information is front-loaded.

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

  Completeness5/5

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

  For a single-parameter tool with no output schema, the description covers functionality, use cases, behavioral limits, and return structure. It is self-contained and sufficient for agent invocation.

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

  Parameters3/5

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

  Schema coverage is 100% with a clear description for 'domain'. The description adds 'starting from https://<domain>/' which might imply protocol handling, but this slightly conflicts with schema stating protocol prefixes are rejected. No significant added value beyond schema.

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

  Purpose5/5

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

  The description clearly states it 'Trace the full HTTP redirect chain starting from https://<domain>/', specifying the verb and resource. It distinguishes itself from sibling tools (e.g., dns_lookup, dossier_headers) by focusing on redirect chains.

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

  Usage Guidelines4/5

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

  Explicitly lists use cases: 'debug redirect loops, verify HTTP→HTTPS upgrades, or audit link shorteners'. It mentions the 10-hop limit but does not specify when not to use or compare with specific siblings.

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

• dossier_spfA
  4.5/5.0
  Behavior4/5

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

  Discloses key behavioral details: fetches via Cloudflare DoH, 5s timeout, locates v=spf1 record, parses mechanisms, and return format. No annotations exist, so the description carries full burden; it covers most aspects, though it could mention that the operation is read-only.

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

  Conciseness5/5

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

  The description is concise and front-loaded, with each sentence adding value. No redundant information.

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

  Completeness5/5

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

  Covers purpose, usage, behavior, parameter, and return format. References sibling tools appropriately. No output schema, but the description fully describes the structure of the result.

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

  Parameters3/5

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

  The single parameter 'domain' is well-described in the input schema (100% coverage) with constraints. The description adds no further parameter-specific detail beyond restating context, so score is at baseline given high schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool's action ('retrieve and parse a domain's SPF record') and resource, and distinguishes it from siblings like dns_lookup for raw records and dossier_dmarc for full email-auth coverage.

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

  Usage Guidelines5/5

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

  Explicitly provides usage scenarios (verify policy, debug failures, check lookup limit) and when to use alternatives (pair with dossier_dmarc for full coverage, use dns_lookup for raw record).

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

• dossier_tlsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behaviors: connects to port 443, performs a TLS handshake with a 5-second timeout, extracts the leaf certificate, and returns structured CheckResult. Slight ambiguity on 'server edge' but overall sufficient.

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

  Conciseness5/5

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

  The description is concise—two sentences covering purpose, usage, behavior, and return format. Every sentence adds value with no redundancy.

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

  Completeness5/5

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

  Given the simplicity of the tool (single parameter, no output schema), the description fully covers what the tool does, how it works, and what it returns. It includes example output fields and error handling, making it complete.

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

  Parameters3/5

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

  Schema coverage is 100% with a detailed parameter description. The tool description does not add new semantic information beyond confirming the parameter is a domain, so baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool fetches and inspects TLS certificates for a domain on port 443, which is distinct from sibling tools like dns_lookup or dossier_headers. It provides a specific verb-resource pair and explicitly lists use cases.

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

  Usage Guidelines5/5

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

  The description offers explicit guidance on when to use the tool (verify certificate expiry, issuer, SANs, detect mismatched/self-signed certs) and what it is not (full cipher-suite scanner). This helps the agent choose between siblings.

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

• user_agent_parseA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavioral traits: it runs synchronously, uses the ua-parser-js library, makes no external calls, and returns specific fields with empty strings for unknowns. This is comprehensive and leaves no ambiguity.

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

  Conciseness5/5

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

  The description is brief (four sentences) but packs all necessary information front-loaded. No redundant words; every sentence adds value.

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

  Completeness5/5

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

  Despite having no output schema, the description enumerates the return fields (browser.name, etc.) and explains behavior for unknown values. It covers input, processing, output, and constraints, making it fully self-contained for a simple parsing tool.

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

  Parameters3/5

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

  The schema already provides a description for the 'ua' parameter with an example. The tool-level description adds context on the output structure but does not significantly enhance understanding of the parameter beyond what the schema provides. Schema coverage is 100%, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function: parsing a User-Agent header into structured components (browser, OS, device, engine). It uses a specific verb ('Parse') and resource, and distinguishes itself from sibling tools which are either network or encoding utilities.

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

  Usage Guidelines4/5

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

  The description provides a clear use case (analyzing server logs or request headers) and explicitly states that it performs no network lookups, which sets user expectations. However, it does not explicitly mention when not to use it or provide alternative tools, though no clear alternative exists among siblings.

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

• dns_lookupA
  4.6/5.0
  Behavior5/5

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

  No annotations provided, so the description fully discloses key behaviors: uses Cloudflare DoH over HTTPS, follows CNAME chains, has a 5-second timeout, returns a JSON array of answer objects with name/type/data, and on error returns a string. This covers expected operational details.

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

  Conciseness5/5

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

  The description is a single paragraph that front-loads purpose, provides usage guidance, and then technical details. Every sentence adds value with no redundancy.

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

  Completeness4/5

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

  Explains return format (JSON array with name/type/data) and error handling despite no output schema. Covers core aspects well, but lacks detail on CNAME chaining behavior or limits. Adequate for a simple tool.

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

  Parameters3/5

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

  The description adds helpful clarification for 'name' (FQDN preferred, relative labels accepted) and lists common record types for 'type'. However, it lists additional types (SOA, CAA, SRV) not present in the schema enum, creating inconsistency and potential confusion. Schema coverage is 100% but description partly misaligns.

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

  Purpose5/5

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

  The description clearly states the tool resolves a single DNS record type and returns raw answers. It distinguishes from sibling tools like dossier_dns (multi-type audit) and dossier_full (complete health check) by specifying its targeted, single-record focus.

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

  Usage Guidelines5/5

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

  Explicitly says when to use ('quick, targeted lookups of one record type') and when to prefer alternatives ('prefer dossier_dns for a full multi-type DNS audit... dossier_full for a complete domain health check'). Provides clear context for agent decision-making.

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

• dossier_fullA
  4.7/5.0
  Behavior5/5

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

  Despite no annotations, description discloses parallel execution, Cloudflare DoH/direct HTTPS, 5s timeout, paywall count, and return format with discriminated union, fully covering behavioral traits.

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

  Conciseness5/5

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

  Four focused sentences with clear progression: purpose, usage, billing, technical details, and return format. No redundancy or waste.

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

  Completeness5/5

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

  Given single parameter and no output schema, description provides sufficient context: purpose, usage, behavior, and return structure. Agent can fully understand tool's capabilities and limitations.

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

  Parameters3/5

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

  Schema covers parameter fully (100% coverage) with detailed description; description adds no further semantics beyond implicit reference, so baseline 3 applies.

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

  Purpose5/5

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

  Explicitly states it runs all 10 Domain Dossier checks in parallel and returns all results, distinguishing it from individual dossier_* tools via specific verb-resource pairing and sibling mention.

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

  Usage Guidelines5/5

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

  Clearly states when to use (comprehensive domain health snapshot) and when to prefer alternatives (individual tools for single checks), with explicit latency consideration.

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

• dossier_headersA
  4.7/5.0
  Behavior5/5

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

  Discloses HTTP GET, 5s timeout, capturing headers before redirects, and the CheckResult output format. No annotations provided, so description fully handles transparency.

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

  Conciseness5/5

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

  Three sentences with no wasted words: purpose, usage guidelines, then technical details. Front-loaded and efficient.

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

  Completeness5/5

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

  Despite no output schema, the description fully explains the return structure and covers all relevant aspects for a single-parameter tool.

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

  Parameters3/5

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

  Schema coverage is 100%, and description adds no extra parameter info beyond schema, so baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool fetches HTTP headers and provides a security audit, distinguishing it from the sibling dossier_redirects.

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

  Usage Guidelines5/5

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

  Explicitly says when to use (to review specific security headers) and when not to (for redirect tracing, use dossier_redirects instead), providing clear alternative.

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

• dossier_web_surfaceA
  4.8/5.0
  Behavior5/5

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

  Despite no annotations, the description fully discloses behavior: concurrent HTTPS fetches with 5s timeouts, lightweight HTML parser, and return structure. It covers error handling with the composite CheckResult format.

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

  Conciseness4/5

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

  The description is well-structured with a clear flow: purpose, usage, behavior, return. While each sentence adds value, it is slightly verbose but still efficient. Could be trimmed slightly for conciseness.

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

  Completeness5/5

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

  Given the tool's moderate complexity (fetching multiple resources, concurrency, parsing) and lack of output schema, the description covers all essential aspects: what is fetched, how, and what is returned. It is complete for an agent to understand and invoke the tool correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds constraints beyond the schema: 'must be resolvable on the public internet; IPs, ports, paths, and protocol prefixes are rejected.' This provides valuable validation guidance.

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

  Purpose5/5

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

  The description clearly states 'Snapshot a domain's public web surface' and lists specific resources fetched (robots.txt, sitemap.xml, home-page <head> metadata). It distinguishes from siblings by naming dossier_headers and dossier_redirects for different use cases.

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

  Usage Guidelines5/5

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

  Explicitly tells when to use this tool ('SEO audits, content discovery, or verifying metadata before sharing') and when not to ('for HTTP headers use dossier_headers, for redirect behavior use dossier_redirects'). Provides clear context.

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

• ip_lookupA
  4.9/5.0
  Behavior5/5

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

  No annotations provided, so description fully covers behavior: queries ipinfo.io with server-side token (not exposed), returns JSON with specific fields, and returns error string on failure.

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

  Conciseness5/5

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

  Three sentences, front-loaded with action and purpose, then usage guidance, then return details. Every sentence is essential and well-structured.

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

  Completeness5/5

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

  Tool is simple (1 param, no output schema), but description covers input constraints, return fields, and error handling completely. No gaps.

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

  Parameters4/5

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

  Schema already describes ip parameter with examples and hostname exclusion. Description adds context but does not significantly exceed schema; due to 100% coverage, baseline 3, but examples add value.

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

  Purpose5/5

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

  Clear verb 'resolve' and resource 'IPv4 or IPv6 address', specifies geolocation, ASN, org, city/country. Distinguishes from sibling tools dns_lookup and dossier_dns which handle hostnames.

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

  Usage Guidelines5/5

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

  Explicitly states when to use (network/location context for raw IP) and when to use alternatives (hostname resolution via dns_lookup or dossier_dns).

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

• url_encodeA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: it is a pure local transform with no network calls, always succeeds, uses encodeURIComponent semantics (so / is encoded), and returns plain text. This covers safety, side effects, and success guarantee.

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

  Conciseness5/5

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

  Three sentences with no wasted words. The first sentence states purpose, the second adds usage guidelines and semantics, the third addresses side effects and output. Front-loaded and efficient.

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

  Completeness5/5

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

  For a single-parameter tool with no output schema, the description covers everything: purpose, input constraints, encoding details, side effects, and return type. No gaps remain.

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

  Parameters4/5

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

  Schema coverage is 100% with a good description. The tool description adds extra examples (e.g., 'hello world', 'a=b&c=d') and reiterates to pass only the component, which adds value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: percent-encode a string for safe URL embedding. It uses a specific verb and resource ('Percent-encode an arbitrary string') and distinguishes it from url_decode by focusing on encoding.

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

  Usage Guidelines5/5

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

  Explicitly tells when to use (escape characters like &, =, #) and what not to do (do not pass a full URL, only the component). Mentions the encoding semantics (encodeURIComponent) and that it's a local transform, helping the agent decide when to invoke.

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

• dossier_dnsA
  5/5.0
  Behavior5/5

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

  No annotations provided, but the description fully discloses behavior: 'Fires six Cloudflare DoH (1.1.1.1) queries concurrently, each with a 5 s timeout' and describes the return format as a CheckResult discriminated union with success and error cases.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose, then usage guidance, then behavioral details. Every sentence adds value; no wasted words.

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

  Completeness5/5

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

  For a complex parallel DNS lookup tool with 6 record types and no output schema, the description covers purpose, usage, alternatives, concurrency behavior, timeout, and return format. The explanation of the CheckResult union compensates for the lack of output schema.

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

  Parameters5/5

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

  Only one parameter (domain) with 100% schema coverage. The description adds context: 'Public FQDN, e.g. example.com. Must be resolvable on the public internet; IPs, ports, paths, and protocol prefixes are rejected.' This goes beyond the schema's basic description.

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

  Purpose5/5

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

  The description clearly states 'Fetch a domain's full DNS profile' and lists specific record types (A, AAAA, NS, SOA, CAA, TXT). It distinguishes itself from sibling tools like dns_lookup (single record type) and dossier_full (all 10 checks).

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

  Usage Guidelines5/5

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

  Explicitly says 'Use as the first step of a domain audit or when you need a comprehensive DNS snapshot' and provides alternatives: 'prefer dns_lookup for a single record type, or dossier_full for all 10 dossier checks at once.'

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

• json_formatA
  5/5.0
  Behavior5/5

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

  Describes the internal operation (JSON.parse + JSON.stringify), states it makes no network calls, and explains both success and failure outcomes, fully compensating for missing annotations.

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

  Conciseness5/5

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

  Concise, front-loaded with main purpose, followed by usage guidance and technical details. Every sentence adds value with no redundancy.

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

  Completeness5/5

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

  Covers input requirements, parameter options, behavior, error handling, and return values despite no output schema. Complete for a validation/formatting tool.

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

  Parameters5/5

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

  Adds meaningful context beyond schema: for input, mentions minified/pretty-printed state; for indent, specifies defaults and accepted values. Schema coverage is 100% so baseline 3, but description adds extra clarity.

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

  Purpose5/5

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

  The description clearly states the tool validates and pretty-prints JSON strings at configurable indent, distinguishing it from sibling tools that handle encoding, decoding, or lookups.

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

  Usage Guidelines5/5

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

  Explicitly says to use for parse error detection or normalizing JSON, and advises using own logic for schema validation or transformation, providing clear when-to-use and alternatives.

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

• jwt_decodeA
  5/5.0
  Behavior5/5

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

  Discloses splitting on '.', base64url-decoding, JSON-parsing, no network calls, no key lookup, returns error on malformed input. No annotations provided, so description fully covers behavioral traits.

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

  Conciseness5/5

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

  Five focused sentences with no redundancy. Front-loaded with main purpose; each sentence adds value.

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

  Completeness5/5

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

  For a single-param tool with no output schema, description fully covers purpose, usage, behavior, and output format (header, payload, signature fields).

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

  Parameters5/5

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

  Schema coverage is 100% but description adds meaning: explains token format (three segments separated by dots) and requirement to remove Bearer prefix, which are not in schema.

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

  Purpose5/5

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

  Clearly states it decodes JWT into header, payload, raw signature without verification. Distinguishes from sibling base64_decode by specifying JWT-specific behavior.

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

  Usage Guidelines5/5

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

  Explicitly says to use for inspecting claims or debugging auth flows, and warns not to use decoded claims for access-control decisions because signature is not validated.

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

• uuid_generateA
  5/5.0
  Behavior5/5

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

  Details implementation (Node.js crypto.randomUUID for v4, spec-compliant for v7), confirms no network calls, and specifies output format (canonical xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). With no annotations, description fully covers behavioral traits.

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

  Conciseness5/5

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

  Four sentences with logical flow: purpose, usage guidance, implementation details, output format. Every sentence adds value, no redundancy.

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

  Completeness5/5

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

  For a simple single-param tool with no output schema and no annotations, description covers all essential aspects: what it does, which version to pick, how it works internally, and what to expect. No gaps.

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

  Parameters5/5

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

  Schema covers version parameter with enum and description. Description adds semantic distinction: v4 random vs v7 time-ordered with Unix-ms prefix for sorting. This enhances understanding beyond schema.

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

  Purpose5/5

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

  Description clearly states 'Generate a single UUID' with specific versions (v4/v7). Verb 'generate' and noun 'UUID' are precise. Sibling tools are unrelated, so no differentiation needed.

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

  Usage Guidelines5/5

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

  Explicitly advises when to use v4 vs v7: 'Use v4 for general-purpose; use v7 when UUIDs must sort chronologically.' Also notes no network calls, helping agents choose based on requirements.

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