Server Quality Checklist

Tool Scores

• check_reverse_dnsA
  4.3/5.0
  Behavior4/5

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

  Discloses additional behavioral traits beyond annotations: describes the two-step resolution process, possible verdicts, and warns against misinterpreting bare PTRs. 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.

  Conciseness5/5

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

  Three concise sentences with front-loaded purpose, clear verdict explanation, and practical guidance. No superfluous text.

  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 rich annotations, the description covers all necessary context: input constraints, process, output meaning, and proper usage. Complete and self-contained.

  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 the parameter description in the schema already explains the public address requirement well. The description repeats this but does not add new semantic information 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?

  Description clearly states the tool checks forward-confirmed reverse DNS for one sending IP, explaining the process and distinguishing it from siblings like check_dkim_selector or check_record which focus on other aspects.

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

  Usage Guidelines4/5

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

  Provides clear when-to-use context: pass a public IP, never report bare PTR, fix by IP owner. However, it does not explicitly mention alternatives or when not to use this tool.

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

• check_propagationA
  4.4/5.0
  Behavior5/5

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

  Goes well beyond readOnlyHint: says 'Observation only: no record is ever composed here', defines 'unavailable' as NOT a negative result, and explains the unknown verdict threshold (fewer than three vantage points). These are non-obvious semantics an agent must know. 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.

  Conciseness4/5

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

  Dense, front-loaded purpose with all critical caveats included. Minor redundancy in 'you have ONE network vantage point... still be missing elsewhere' but it reinforces the usage timing; no wasted words overall.

  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?

  No output schema exists, yet the description tells an agent what comes back (grid plus deterministic verdict), how to interpret non-answers (unavailable), and how to report partial coverage (vantage_reached of vantage_total). This is sufficient for correct invocation and result interpretation.

  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 the description largely restates schema details ('www. is not stripped', 'SPF and DMARC records are TXT'). It adds the match/mismatch behavior of expected_value, but this too is in the schema, so no significant incremental meaning.

  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?

  States a specific verb and resource: 'Check whether a DNS change has propagated GLOBALLY' with a defined six-vantage-point methodology. It also contrasts with the agent's single network vantage point, distinguishing it from local DNS checks such as sibling check_record.

  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 says 'Call it after the human publishes a record' and explains why (one vantage point can mask propagation failures). Does not name sibling alternatives or list when-not 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.

• check_recordA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds valuable context: it reads from authoritative and caching resolvers, reports agreement/disagreement, and explains output interpretations (empty values mean genuine absence; max_wait_seconds is remaining TTL). This enhances transparency 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.

  Conciseness4/5

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

  The description is a single dense paragraph that covers purpose, parameter details, and output interpretation. It is relatively concise but could be more structured (e.g., bullet points or separate sections) to improve scanability. No wasted sentences.

  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 there is no output schema, the description adequately explains return values: 'Empty values mean the record is genuinely absent. When in_sync is false, max_wait_seconds is the largest remaining cached TTL — the wait before those resolvers refresh.' This, combined with parameter details and annotations, makes the tool self-contained.

  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% (all three parameters documented), but the description significantly enriches meaning. For 'kind', it explains the derived query logic for spf/dmarc; for 'host', it clarifies which record types it applies to; for 'domain', it specifies formatting and Unicode handling. This goes well beyond schema basics.

  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: 'Check whether a DNS change has landed: reads the record from the domain's OWN nameservers (cache-free) and from two public caching resolvers, and reports whether they agree.' This specific verb-resource pair distinguishes it from sibling tools like check_dkim_selector or validate_dmarc_record, which cover different DNS checks.

  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 explains what the tool does and provides usage context (e.g., for checking DNS propagation after a change). It includes a caveat: 'This samples two resolvers, so never describe it as worldwide or as propagation coverage.' However, it does not explicitly state when not to use it or name alternative tools, leaving some ambiguity for the agent.

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

• audit_spf_includesA
  4.6/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, idempotent, openWorld), the description discloses critical behavioral constraints: unverified domains are always reported as unverified, never as available, and registry_confirmed: false means DNS-only inference with limitations. It also states that no SPF fix record exists, preventing misuse, which is substantial disclosure beyond annotations.

  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 front-loaded with the purpose sentence and then provides essential details in a structured list. It is longer than the calibration's ideal but every sentence carries information; minor repetition of 'never as available' could be tightened, but overall the density is justified by the tool's complexity.

  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 there is no output schema, the description compensates by fully enumerating the return elements (resolved tree, lookup attribution, IPv4 count, all five finding types) and explaining edge cases like registry_confirmed and unverified domains. It also covers the alternative tool, making it contextually 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 schema already documents the domain parameter with 100% coverage, including normalization and allowed forms. The description adds only contextual references to 'the audited domain's OWN record' but no new format or syntax rules, 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.

  Purpose5/5

  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: 'Audit a domain's SPF supply chain' and explicitly differentiates from sibling count_spf_lookups by mentioning it as the alternative for 10-lookup questions. It also enumerates the main outputs (resolved tree, findings, IPv4 count), which further clarifies scope.

  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?

  It explicitly names count_spf_lookups as the alternative when only the 10-lookup limit matters, which provides a clear when-to-use/not-use boundary. The cautions about not treating findings as instructions and relaying to the domain owner are additional usage guardrails.

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

• count_spf_lookupsA
  4.6/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds concrete behavioral details: what return fields are provided (record_valid, findings, has_pass_all, etc.), the lookup counting logic, and the explicit statement that no SPF fix record is returned. This goes well beyond annotations.

  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 concise but thorough, front-loading the purpose and return values. Every sentence adds useful information without redundancy. It could be slightly more structured, but it is efficient and clear.

  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 complexity of SPF validation and the fact that there is no output schema, the description thoroughly covers all aspects: what the tool does, the two usage modes, the specific return fields, and important constraints (diagnose-only, no fix). It is complete for an agent to correctly invoke the tool.

  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 the schema already documents both parameters. The description adds meaningful context: domain resolves the published record and counts recursively through nested includes, while record parses a pasted record counting only its own terms. This adds value beyond the schema 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 starts with 'Validate an SPF record and count what it costs,' clearly stating the verb and resource. It lists specific return fields and explicitly distinguishes this tool from siblings by noting 'This is the SPF validator — there is no separate one.' This makes it highly specific and differentiated.

  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 guidance: 'Pass EXACTLY ONE of domain or record,' explaining when to use each. It also clarifies that this tool is 'diagnose-only' and why it does not return a fix record. While it doesn't list specific alternative tools, 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.

• check_dkim_selectorA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and idempotentHint annotations, the description specifies the return values (verdict, explanation, key record), explicitly states that no fix record is returned, and explains why, providing full behavioral 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?

  Four sentences, front-loaded with purpose, no unnecessary 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?

  Given the simple input schema (2 params) and no output schema, the description fully covers what the tool does, what it returns, and why it doesn't return a fix record, making it contextually complete.

  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, but the description adds context: it explains that the selector is the exact one from the sending platform and provides examples, enhancing agent understanding 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 checks a specific DKIM selector, distinguishes from a full scan's common-selector sweep, and contrasts with sibling tools like scan_domain that do broader scanning.

  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 explains when to use this tool (when the exact selector is known, which a full scan might miss) and notes that the selector is not guessable, but does not explicitly mention alternatives or when not to use it.

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

• parse_dmarc_reportA
  4.7/5.0
  Behavior5/5

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

  The description discloses key traits beyond annotations: the tool is stateless ('nothing is stored, parsed and discarded'), idempotent, and read-only (matching annotations). It also specifies input size limits (2 MiB decoded) and format support, which annotations do not cover, adding significant 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.

  Conciseness5/5

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

  The description is three sentences, each earning its place: purpose, required input format, and stateless nature. It is front-loaded with the core action and efficiently conveys all necessary details without 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?

  The description adequately covers input, constraints, and effect. It hints at output ('readable per-source aggregates') but does not detail the exact structure. Given no output schema, a brief mention of the output format would improve completeness, but the core information is sufficient for correct invocation.

  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?

  The description adds meaningful context beyond the input schema. For 'content_base64', it clarifies to encode file bytes, not paste raw XML. For 'filename', it notes the filename is only for logging and does not affect parsing. This helps the agent avoid common mistakes.

  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 parses a single DMARC aggregate (RUA) report into per-source aggregates, specifying what information is extracted (sender, volume, SPF/DKIM alignment). This is distinct from sibling tools which handle building, checking, or generating DNS records, so the purpose is unambiguous.

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

  Usage Guidelines4/5

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

  The description provides explicit instructions on how to invoke the tool: pass base64-encoded file bytes, optionally with a filename. It states the file can be XML, .gz, or .zip up to 2 MiB. While it does not contrast with siblings, the context of parsing vs. fetching (get_report) or checking DNS records is clear enough for an agent to decide.

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

• scan_domainA
  4.7/5.0
  Behavior5/5

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

  The annotations only declare non-read-only, non-idempotent, non-destructive behavior. The description adds critical behavioral detail beyond that: cache-first explanations, a ~minute dedup window, reuse of stored reports, and the scanned_at caveat. This gives the agent an accurate mental model of what actually happens on repeat calls.

  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 front-loaded with the core action and output, then layers the cache caveat and usage routing in later sentences. Every sentence earns its place: output shape, behavioral nuance, and tool selection are each covered without 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?

  With no output schema present, the description compensates by specifying the checks, status values, observed record, and fix_record structure. It also covers the non-obvious caching behavior that could otherwise lead an agent to misreport state. For a single-parameter tool, this 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?

  The input schema already covers the single parameter at 100% with rich details about accepted formats, subdomains, and punycode normalization. The tool description itself does not add much parameter-level meaning beyond naming the domain as the scan target, so the high-coverage baseline of 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?

  The description opens with a specific verb and resource ('Force a fresh scan of a domain') and enumerates the seven deterministic checks and the per-check output fields. It clearly distinguishes itself from the sibling get_report by contrasting fresh scans with cached answers.

  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 this tool ('when you need current state') and when to prefer an alternative ('use get_report when a recent cached answer will do'). It also warns about the dedup window and advises checking scanned_at after DNS edits, giving actionable selection and timing guidance.

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

• start_monitoring_signupA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnly and idempotent annotations, the description explains that nothing is created, no email is sent, the signup_url opens an external page, the domain is transferred only after owner sign-in, and monitoring starts only after TXT ownership proof. This is rich behavioral disclosure with 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.

  Conciseness5/5

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

  Front-loaded purpose, followed by necessary workflow details and a concrete output instruction. Every sentence earns its place; no filler.

  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?

  Without an output schema, the description still names both return values (signup_url and message), explains the asynchronous side effects, and instructs exact formatting. An agent has everything needed to invoke and present the result 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 the schema already documents domain format. The description adds meaning by explaining what happens to the domain value: it is carried over to the owner's dashboard and pre-filled after sign-in, which is useful behavioral context beyond validation.

  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?

  States a specific verb and resource: 'Return a sign-up link to give to the HUMAN who owns a domain,' which clearly distinguishes it from the sibling DNS/email monitoring tools. The purpose is immediately evident from the first sentence.

  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?

  Gives clear context: this is for handing off monitoring to the domain owner themselves, and explicitly says 'never sign in on their behalf.' It does not name sibling alternatives explicitly, but the intended use case is unmistakable.

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

• build_dmarc_upgradeA
  4.8/5.0
  Behavior5/5

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

  Annotations are sparse (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries the burden. It goes into depth: alignment signals are derived server-side and cannot be asserted by the caller; null record semantics; np=reject behavior; and the human-approval requirement. This exceeds what annotations alone could provide.

  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 long and contains a very long parenthetical enumerating null-record cases, which tests readability. However, every piece of content earns its place: null handling, policy limits, np behavior, and human approval are all essential. It is dense but not wasteful.

  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 one-parameter tool with no output schema and minimal annotations, this description covers everything an agent needs: what the tool returns, when it returns null, how to handle null, what tags appear in the record, and the required human approval step. There is no meaningful gap.

  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 schema already documents the single `domain` parameter thoroughly, including punycode normalization, so the description doesn't need to repeat it. However, the description adds useful context about what the caller can influence (essentially only the domain) and what is server-side derived. Since schema coverage is 100%, the baseline is 3, and the added context earns a 4.

  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 opens with a specific verb and resource: 'Return a validated DMARC enforcement-upgrade record for a domain.' It clearly differentiates from siblings like generate_dmarc_record and validate_dmarc_record by describing what this tool does differently. The scope is unambiguous.

  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 explicitly states when to use this tool versus alternatives: a scan can justify p=quarantine at most, while p=reject requires monitoring evidence. It also explains that a null record is an answer, not a fault, and instructs the caller to relay rationale and never compose a record. This is strong, actionable usage guidance.

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

• get_reportA
  4.8/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false, idempotentHint=true. The description explains that scanning occurs only once if no report exists, and lists the report contents including scanned_at for staleness judgment. This adds valuable context beyond annotations without contradiction.

  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 tightly written with no wasted words, front-loading the core purpose and usage guidance. Two sentences cover purpose, behavior, and alternatives 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?

  For a domain check tool with one parameter and no output schema, the description comprehensively covers what the report contains (seven checks), when to use the alternative, and how to judge staleness. It is fully adequate for agent decision-making.

  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 has full coverage for the single domain parameter. The description adds extra meaning: 'Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode.' This significantly enhances understanding.

  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 returns a stored report for a domain, scanning only if none exists, and distinguishes it from scan_domain which re-reads state. The verb 'Return' and resource 'stored report' are specific.

  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 'the right default for a first look' and advises to 'Prefer scan_domain when you specifically need state re-read right now — for example after a DNS change.' This provides clear when-to-use and when-not-to-use guidance.

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

• validate_dmarc_recordA
  4.8/5.0
  Behavior5/5

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

  Annotations already indicate readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: it performs no DNS lookup, accepts only a pasted record string, reports parsed tags and findings, and explains the alignment-evidence limitation. The upgrade_record policy explanation also clarifies an important boundary. 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.

  Conciseness4/5

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

  The description is front-loaded with the core purpose and remaining sentences add useful routing and policy context. The upgrade_record/p=reject explanation is somewhat lengthy for a validation tool, but it earns its place by preventing misuse.

  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?

  With a single parameter, no output schema, and annotations covering safety, the description provides enough detail: what it validates, what it returns at a high level, what it does not do, and how it relates to upgrade paths. The agent can call it correctly without additional context.

  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 schema already provides strong coverage (100%) with an example and the 'record value only' clarification. The description reinforces this by saying 'pass the record string itself' and explicitly excluding DNS lookup, adding slight 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 opens with a specific verb and resource: 'Validate a pasted DMARC record', then lists concrete outputs (parsed tags, level'd findings, validity). It clearly distinguishes itself from DNS-lookup and record-generation siblings by explicitly stating 'No DNS lookup' and by contrasting with upgrade_record.

  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?

  It explicitly states when to use the tool ('pass the record string itself') and when not to use a scan-based alternative, explaining why upgrade_record is capped at p=quarantine and that p=reject requires aggregate-report evidence. This gives the agent actionable selection criteria.

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

• build_parked_domain_recordsA
  4.9/5.0
  Behavior5/5

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

  Despite readOnlyHint=true, the description adds critical runtime behavior: the server independently re-checks DNS (existence, MX, SPF, DKIM selectors), returns null with rationale if mail is found, reports lookup failures as failures, and never auto-publishes ('Publishing is the human's decision'). 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.

  Conciseness5/5

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

  Every sentence earns its place: purpose, domain exclusion, human-confirmation protocol, server re-check behavior, and publishing handoff. It is a dense but structured single paragraph, front-loaded with the main action.

  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?

  With no output schema, the description compensates fully by explaining return shape (three records, or null with rationale, or failure), ordering constraint, and the human approval step. Combined with a complete parameter schema, an agent can invoke this tool correctly and interpret results.

  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 covers 100% of parameters; the description adds nuance for confirm_no_mail beyond the schema by framing it as a human-only decision that 'unlocks the question, not the answer' and instructing to ask before setting. It doesn't discuss rua_email or domain, but the schema already fully documents those, so the baseline for high coverage is met with a slight bonus for the confirm_no_mail 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 opens with a specific verb and resource: 'Build the three-record hardening pack' for a NON-SENDING domain, naming the exact records (Null MX, hard-fail SPF, p=reject DMARC). It clearly scopes to parked/redirect/brand-defensive domains, distinguishing it from sibling tools like generate_dmarc_record or build_dmarc_upgrade.

  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?

  Explicit when-to-use and when-not-to-use: 'For parked, redirect and brand-defensive domains only — NEVER for a domain that sends any mail.' It also instructs the agent to ask the human owner before setting confirm_no_mail, and to relay rationale rather than retry, providing concrete decision rules.

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

• generate_dmarc_recordA
  4.9/5.0
  Behavior5/5

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

  Annotations indicate readOnlyHint and idempotentHint, and the description adds valuable behavioral context: the generated record always includes np=reject regardless of p=, it is re-validated before return, and human approval is required. These details go well beyond the annotations by explaining internal validation logic and output guarantees.

  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 compact (four sentences) and front-loaded with the primary purpose. Every sentence delivers critical information: what it does, key parameters, the np=reject behavior, re-validation, and human approval requirement. 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 generation tool with no output schema, the description fully covers what the output looks like (a DMARC record), important constraints (np=reject), validation behavior (re-validated), and usage steps (present verbatim, human approval). It gives an agent everything needed to 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 parameter-related clarity by noting that the `policy` parameter does not influence np=reject ('independently of the p= you choose'), which is not obvious from the schema. However, most parameter semantics are already well documented in the schema 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 the tool's function: 'Build a DMARC record from scratch for a domain that has none, using a validating engine.' It distinguishes itself from siblings by emphasizing 'from scratch' and 'never compose one yourself,' differentiating from validate_dmarc_record and build_dmarc_upgrade.

  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?

  It explicitly states when to use: 'for a domain that has none,' and when not to: 'never compose one yourself.' It also provides a clear constraint: 'Present it verbatim; a human must approve before publishing.' This gives strong contextual guidance on when and how to use the tool.

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

• get_readinessA
  4.9/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and idempotentHint annotations, the description adds critical behavioral context: the null next_record is a valid answer, the agent must relay blockers and never compose a stronger record, and any returned record must be presented verbatim for human approval. It also mentions API token requirements and return semantics.

  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 front-loaded with a clear purpose, then delivers return semantics, safety guardrails, and usage guidance. Every sentence carries essential information—none are filler—and the structure logically progresses from what it does to how to handle its outputs.

  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?

  With no output schema, the description fully explains the return values (readiness, blockers, window, next_record) and the null semantics, which is crucial for correct agent behavior. It also covers the human-approval requirement and the tool's role in the enforcement workflow, making it complete for a tool of this complexity.

  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 covers the domain parameter well (verified, monitored, ownership not disclosed). The description adds meaning by emphasizing that the domain is specifically the one whose RUA report window the verdict is computed from, and that it must be a single domain from the caller's account, reinforcing the scope.

  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 opens with a specific verb+resource statement: 'Read the DMARC enforcement-readiness verdict for ONE domain the caller's account monitors.' It clearly defines the tool's scope and distinguishes it from sibling tools like scan_domain by framing it as the evidence-based readiness check.

  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?

  It explicitly states when to use the tool: 'Use this before proposing enforcement.' It also contrasts with scan_domain, noting that a scan shows current policy but only this evidence window can determine if tightening would reject real mail, providing effective guidance on alternatives.

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

• get_alertsA
  5/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint=true and destructiveHint=false, but the description adds depth: it explains the deliberate read-only design ('acknowledging an alert is the human's own triage'), details the delivery_class semantics ('dashboard_only' rows excluded from digest mail), and the inclusive-since behavior that causes row repetition. This is valuable contextual information 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.

  Conciseness5/5

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

  The description is dense but every sentence earns its place: purpose, paging rule, inclusive-since semantics, read-only rationale, and row field enumeration. It is front-loaded with the core action and progressively provides necessary detail without fluff or 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 there is no output schema, the description compensates by naming all returned row fields (id, domain, type, check, summary, etc.) and explaining the delivery_class meaning. It covers authentication (API token), paging, filters, and behavioral constraints, making it complete for an agent to use the tool correctly.

  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?

  Although the schema already describes each parameter (100% coverage), the description adds critical operational meaning: `since` is an INCLUSIVE floor (so de-duplicate on id), `before` is an opaque cursor that must be relayed verbatim, and invalid `type`/`domain` values are rejected rather than silently ignored. This clarifies usage subtleties that raw schema descriptions omit.

  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 opens with 'Read the monitoring alert log for the domains the caller's account monitors, newest first', which clearly states the action (read), resource (monitoring alert log), and scope (caller's domains, newest first). This distinguishes it from sibling tools focused on DNS/DMARC operations, making the purpose unmistakable.

  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 provides explicit procedural guidance: 'PAGE DOWN BEFORE ADVANCING `since`' and warns that ignoring it drops rows. It also states when not to use mutation-like operations ('there is no ack and no delete here') and clarifies the read-only intent. This goes beyond simple context to give definitive usage rules.

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