Server Quality Checklist

Tool Scores

• build_dmarc_upgradeA
  4.3/5.0
  Behavior5/5

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

  The description goes beyond the annotations by disclosing key behaviors: the alignment gate is server-side and cannot be asserted by the caller; the full set of null-record conditions (domain not found, NXDOMAIN, temp-fail, already strong policy); the np=reject behavior unless an existing np tag is preserved; and the instruction to present the record verbatim and require human approval. This provides rich behavioral context that the annotations (readOnlyHint, openWorldHint, idempotentHint) do not cover, 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.

  Conciseness4/5

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

  The description is a single dense paragraph, but every sentence carries critical information: purpose, server-side derivation, null conditions, np tag handling, and human approval. It is front-loaded with the main purpose. While not broken into bullets, it is concise for the complexity and avoids unnecessary filler.

  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 tool has only one parameter and no output schema, the description does a good job explaining return behavior: when 'record' is null versus present, what the 'rationale' is for, and the returned record's np tag. It mentions the need to 'relay rationale' and 'present a returned record verbatim,' which describes the expected output without an explicit output schema. It does not fully specify the response structure (e.g., whether the response is a JSON object with both 'record' and 'rationale'), but the guidance is sufficient for a high-level understanding.

  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 provides 100% coverage for the single 'domain' parameter, including normalization to punycode and acceptable formats. The description itself does not add additional parameter-level details beyond what the schema already states. With high schema coverage, a 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 states a specific action and resource: 'Return a validated DMARC enforcement-upgrade record for a domain.' This clearly distinguishes it from sibling tools like generate_dmarc_record (which likely creates a fresh record) and validate_dmarc_record (which validates existing records). The focus on 'enforcement-upgrade' and 'derived server-side from a scan' makes the purpose precise.

  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 clearly implies when the tool is appropriate: for proposing a DMARC enforcement upgrade based on a server-side scan. It details the null record conditions, which tells the caller when no upgrade is available. However, it does not explicitly name alternatives or contrast with sibling tools, such as 'use generate_dmarc_record for a new record from scratch.' This is a clear usage context but lacks explicit exclusions.

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

• 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.

• validate_dmarc_recordA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate read-only, idempotent, non-destructive. The description adds that no DNS lookup is performed and to 'Present any returned record verbatim'. This provides useful behavioral context 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.

  Conciseness5/5

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

  Three sentences, front-loaded with purpose, no redundancy. Every sentence adds value: validation outcome, absence of DNS lookup, and guidance on alternatives.

  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?

  With good annotations and full schema coverage, the description adequately covers purpose, usage, and behavior. It does not detail the output format, but mentions 'parsed tags, level'd findings, and validity' which is sufficient for a read-only validation 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% with a clear description for the 'record' parameter. The description repeats the constraint about not including the hostname, which is already in the schema. An example value is provided, adding minor 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?

  The description clearly specifies the verb 'validate', the resource 'DMARC record', and the outcomes: 'parsed tags, level'd findings, and whether it is valid'. It distinguishes from siblings like 'upgrade_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?

  Explicitly states 'No DNS lookup' and when to use alternatives: 'upgrade_record previews a stronger policy' and 'p=reject needs a full scan (use build_dmarc_upgrade)'. This provides clear context and exclusions.

  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.

• 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.

• 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.

• start_monitoring_signupA
  4.9/5.0
  Behavior5/5

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

  The description fully discloses the tool's read-only behavior, aligning with annotations (readOnlyHint, idempotentHint). It details the sequence: returned URL leads to sign-in page, domain is carried over after sign-in, monitoring starts after TXT proof. 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 well-structured and front-loaded with the tool's purpose. While it is somewhat lengthy due to the step-by-step explanation, every sentence serves a purpose and no content is redundant.

  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 (1 parameter, no output schema, clear annotations), the description is complete. It covers the return value (signup_url and message), the process, and important caveats, leaving no ambiguity for an AI agent.

  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 valuable context to the 'domain' parameter beyond the schema: it shows examples, explains accepted forms (bare registrable names and subdomains), and explicitly excludes scheme, path, or port. It also mentions Unicode normalization.

  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 sign-up link for a domain owner to start monitoring, distinguishing it from siblings that perform scanning or record checks. It specifies 'Nothing is created and no email is sent', clarifying it initiates a human-led process.

  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 instructs the agent to hand the URL and relay the message to the human, and warns 'never sign in on their behalf'. It explains the flow after the URL is used, providing clear when-to-use context.

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

• 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.

• scan_domainA
  5/5.0
  Behavior5/5

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

  The annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds significant behavioral context: it forces a fresh scan, caches results for one minute, returns statuses per check, and includes fix records. No contradictions 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?

  The description is concise (3 sentences) yet comprehensive. It front-loads the core action and then details the checks, caching behavior, and usage guidance. Every sentence adds value 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?

  Given the tool's complexity (seven checks, caching, fix records, no output schema), the description fully covers what the tool does, how it behaves, what parameters to provide, and when to use it. It addresses potential user needs for understanding the return structure and caching semantics.

  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?

  Even though schema description coverage is 100%, the description adds valuable semantics: examples (example.com), accepted formats (bare registrable names, subdomains), exclusions (scheme, path, port), and Unicode normalization to punycode. This goes well beyond the schema's minimal 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 the tool forces a fresh scan of a domain and returns a full report with seven specific checks. It uses specific verbs ('force', 'scan', 'return') and resource ('domain'). The purpose is distinct from sibling tools like get_report, which is explicitly mentioned as an alternative for cached results.

  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 guidance: 'Use this when you need current state; use get_report when a recent cached answer will do.' It also explains the caching behavior for repeat scans within a minute, offering clear context for when to invoke 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.