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

The description goes well beyond the annotations. It explains the idempotent behavior explicitly ('Re-adding a domain they already monitor returns that domain rather than an error'), emphasizes exact record reproduction, and discloses that no DNS changes are performed. It also reveals privacy/security behavior: unverified or foreign domains are refused as not found and ownership is never disclosed.

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

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

The description is efficient and every sentence earns its place: first the action and outputs, then idempotency, then the exactness constraint, and finally the human-approval requirement. No fluff or redundancy exists, and key operational constraints are front-loaded.

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

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

There is no output schema, so the description carries the burden of explaining return values and still covers TXT record, DNS hosting location, guide link, and optional apply URL. It also explains idempotent behavior, domain verification requirements (via schema and text), and the mandatory human-approval step. An agent has everything it needs to invoke this tool correctly.

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

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

The input schema already provides 100% coverage of the 'domain' parameter, including constraints and refusal behavior. The description adds the 'signed-in user's' scoping and the purpose of the domain in the monitoring workflow, but it does not need to repeat parameter mechanics; a baseline of 3 is appropriate when the schema carries the heavy lifting.

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

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

The description states a specific verb 'Add' with a precise resource: 'a domain to the signed-in user's DNS Doctor monitoring.' It also enumerates the concrete outputs (ownership-check TXT record, DNS host, provider guide link, one-click apply URL), which clearly distinguishes it from sibling tools that check propagation or validate records.

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

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

The description gives clear operational context: when adding a domain to monitoring, what the tool will return, and that a human must publish the record. It doesn't explicitly name alternative tools or state when not to use it, but the context is clear and the required workflow is unambiguous.

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

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

Annotations already mark the tool read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: unverified domains are never reported as available, registration is a live fact that may change on re-run, and the tool returns risk analysis only with no SPF fix. No contradiction with annotations.

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

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

The description is longer than average and repeats include_registrable in the caveat section, but it is front-loaded with the use case and the detailed findings enumeration is justified given there is no output schema. Most sentences earn their place by supporting tool selection or safe interpretation.

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

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

For a complex tool with no output schema and one parameter, the description is unusually complete: it explains all typed findings, the unverified policy, the live nature of registration, the no-fix boundary, and the alternative tool for 10-lookup questions. An agent has enough context to call and interpret the tool correctly.

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

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

The schema fully documents the single domain parameter, including accepted formats, punycode normalization, and exclusions. The description adds no additional parameter-level meaning, so the baseline of 3 applies for high schema coverage.

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

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

The description opens with the exact user intent ('who can send email as their domain through SPF includes') and then states a specific behavior: walking every include/redirect and reporting transitive senders. It clearly differentiates itself from count_spf_lookups by name and scope.

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

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

It explicitly says 'Use this when the user asks...' and ends with 'Use count_spf_lookups instead when the question is only the 10-lookup limit.' It also warns that findings are risk analysis, not instructions, and that no fix is provided, setting clear boundaries.

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

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

Annotations indicate readOnlyHint=false (so it may write) and destructiveHint=false (no destruction), but the description goes further by explaining that the alignment signal is derived server-side and cannot be asserted by the caller, and that p=reject requires aggregate-report evidence over a full window. It also explains the trait of returning null as a valid answer, and that np=reject is included unless already present. This adds significant behavioral context beyond annotations, though some details (like the exact validation process) are not covered.

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

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

The description is quite lengthy (a single long paragraph) and front-loads usage context, but it is dense and discusses multiple conditions and nuanced behaviors. While it is structured with clear cause-effect statements, it could be broken into shorter sentences or bullet points for readability. It earns its length because of the complexity, but it is not concise.

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

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

Given the tool's complexity (conditional behavior, null return, server-side derivation, np tag handling), the description covers the essential trigger conditions, output semantics (including null as a valid answer), and constraints (e.g., reject requires monitoring). It also tells the agent to present records verbatim and get human approval. Although there's no output schema, the description fully explains what the return value represents and when it is null, so the agent has enough context to call it correctly.

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

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

Schema coverage is 100%, so the parameter 'domain' is fully described in the schema (including examples and normalization). The description does not add parameter-specific semantics beyond restating that it takes a domain, so a baseline 3 is appropriate since the schema carries the burden and the description adds little extra meaning for this single param.

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

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

The description clearly states the tool's purpose: it builds a DMARC enforcement-upgrade record when a user asks about moving from p=none, tightening DMARC, or next DMARC steps. It distinguishes from siblings like generate_dmarc_record (which likely generates a fresh record) by emphasizing the 'upgrade' and enforcement context, and by listing specific trigger conditions.

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

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

It explicitly says when to use ('when the user asks how to move DMARC on from p=none...' and 'after any report showing DMARC below enforcement') and when not to (e.g., when a scan can only justify quarantine at most, and reject requires monitoring evidence). It also states that a null record is the answer when no upgrade is honest, so agents know to relay rationale rather than fabricate a record.

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

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

Adds substantial context beyond the annotations: the server independently re-checks DNS and returns null-with-rationale on evidence of mail, lookup failures are reported as failures never as a pack, and publishing waits on human approval of each record. The readOnlyHint is consistent because the tool only generates records for review rather than publishing them.

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

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

Purpose and scope are front-loaded, and each subsequent sentence carries a distinct behavioral constraint: human confirmation, server re-check, failure semantics, and the approval flow. The repeated 'sends no email' phrasing reinforces a critical safety boundary rather than padding, so the length 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.

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

Despite having no output schema, the description fully specifies return semantics: the verbatim three-record pack, null with rationale when DNS evidence of mail exists, and failure on lookup failure. Combined with the schema's complete parameter coverage and the explicit human-approval flow, nothing an agent needs to invoke and handle the tool correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented thoroughly in the input schema; the description adds no new parameter-level detail or syntax. It does reinforce confirm_no_mail's meaning ('unlocks the question, not the answer'), but that mirrors the schema, keeping this at the baseline of 3.

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

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

States a specific verb and resource with named deliverables: 'Build the three-record hardening pack... a Null MX, a hard-fail SPF record, and a p=reject; np=reject DMARC record.' The scope ('For parked, redirect and brand-defensive domains only') clearly distinguishes it from the check/audit/validate siblings and from build_dmarc_upgrade, which serves sending domains.

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

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

Gives an explicit trigger ('Use this when the user asks how to protect a domain that sends no email from being spoofed') and a hard exclusion ('NEVER for a domain that sends any mail, including transactional or one legacy system'). It also states the precondition that only the human domain owner may set confirm_no_mail, so an agent knows to ask before invoking.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful behavioral context by stating exactly what is returned (verdict, explanation, published key record when present) and explicitly noting that no fix record is returned and why. This goes beyond the annotations without contradicting them.

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

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

The description is four sentences with no filler. It front-loads the usage trigger, defines the operational scope, states the return payload, and explains the absence of a fix record. Every sentence earns its place.

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

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

For a two-parameter tool with fully documented schema properties and non-destructive annotations, this description is complete. It covers when to use it, what the parameters mean in practice, what the response will contain, and what it will not contain. No important gap remains for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is strong. The description adds value by emphasizing that the selector must be the exact value the sending platform uses, that it is not guessable from the domain, and that the common-selector sweep in a full scan may miss it. This supplements the schema's examples and clarifies the key selection behavior.

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

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

The description states a specific verb and resource: checking one specific DKIM selector on a domain, and ties it directly to user intents like 'is DKIM set up' or 'does this selector exist.' It also differentiates itself from a full scan's common-selector sweep, making its scope clear relative to sibling tools.

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

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

The opening line explicitly says when to use this tool: when the user asks whether DKIM is set up, whether a specific selector exists, or why DKIM fails. It also explains the limitation of a full scan's common-selector sweep, giving the agent a concrete basis for choosing this tool over scan_domain.

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

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

The description goes well beyond the annotations. It discloses that a non-completing lookup is TRANSIENT and never a verdict about DNS, that on success the result carries the DMARC reporting record, and that nothing here is applied to anyone's DNS — a human publishes every record. It also instructs the agent to print records exactly as returned and get approval before using any DNS tool. This is rich behavioral context that annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) do not provide. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place: it covers the tool's purpose, the three possible outcomes, the transient nature of incomplete lookups, the DMARC record side-effect, the exact-printing rule, and the human-approval requirement. It is front-loaded with the core purpose and then adds critical behavioral constraints. Slightly long, but justified given the complexity of the tool's semantics.

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

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

For a single-parameter tool with no output schema, the description is remarkably complete. It tells the agent what the result means, how to interpret edge cases, what side effects occur, and what to do with the returned records. The only minor gap is that it doesn't explicitly describe the exact output structure, but the description's explanation of the result's meaning compensates for the lack of an output schema.

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

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

Schema coverage is 100%, so the schema already documents the single 'domain' parameter. The description adds meaning beyond the schema by explaining that the domain must be one of the token account's VERIFIED monitored domains, that other names are refused as not found, and that ownership is never disclosed. This is valuable semantic context that the schema's description only partially conveys.

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

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

The description states a specific verb ('Check'), a specific resource (ownership TXT record for a domain the user has added), and a specific outcome (mark it verified when visible). It also distinguishes the tool's purpose from siblings like check_propagation and check_record by focusing on ownership verification and the verification state transition.

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

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

The description explicitly explains when to use this tool (to check whether the ownership TXT record is visible yet and mark it verified) and what the result means, including how to distinguish 'not published yet' from 'published with the wrong value' from 'lookup did not complete'. It also gives a clear exclusion: the domain must be one of the token account's VERIFIED monitored domains, and any other name is refused. It does not name sibling alternatives, but the context is so specific that an agent can route correctly.

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

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

The description goes well beyond the readOnlyHint/openWorldHint annotations by explaining that 'unavailable' is not a negative result, the verdict downgrades to 'unknown' when fewer than three vantage points respond, and to report vantage_reached/vantage_total instead of claiming convergence. This rich behavioral detail is not present in the annotations.

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

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

The description is long but information-dense and well-structured: usage intent upfront, then operational behavior, then parameter clarifications, then edge-case handling. Some content duplicates the schema, but the extra caveats are meaningful for correct interpretation.

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

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

There is no output schema, yet the description explains what comes back: a grid, a verdict, per-cell match/mismatch behavior, unavailable handling, and unknown downgrade. It also explains how to avoid misreporting partial coverage. This fully compensates for the missing output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely paraphrases the schema: exact name handling, allowed record types, and expected_value turning cells into match/mismatch. It adds contextual framing but no significant new parameter-level meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Check whether a DNS change has propagated GLOBALLY,' with six vantage points and a deterministic verdict. It distinguishes itself from a single-vantage local lookup by explicitly saying the caller has 'ONE network vantage point,' making the tool's scope clear versus sibling tools like check_record.

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

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

It gives explicit when-to-use context: when the user asks about global propagation, why a record shows inconsistently, and after publishing a record. It also provides a when-not: 'Observation only: no record is ever composed here.' It does not explicitly name an alternative tool, but the 'ONE network vantage point' phrasing clearly contrasts with local lookup tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral context: it reads from two resolvers, explains the meaning of empty values, describes the in_sync and max_wait_seconds semantics, and cautions against overstating coverage. No contradiction with annotations.

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

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

The description is dense but not wasteful; it front-loads the usage scenario and packs technical details efficiently. It is slightly long but every sentence carries necessary information, so it earns a 4 rather than a 5.

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

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

For a tool with no output schema and a non-trivial parameter model, the description covers everything an agent needs: usage triggers, kind/host semantics, empty-value behavior, sync-wait details, and limitations. It is complete 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.

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

Schema covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds valuable clarification on how 'kind' maps to query names (e.g., dmarc → _dmarc.<domain>) and which kinds honor 'host'. This goes beyond the schema, raising the score to 4.

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

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

The description clearly states the tool's purpose: checking whether a DNS change has landed, looking up records, and verifying published records. It specifies the mechanism (reads from own nameservers and two caching resolvers) and differentiates from siblings by noting it is not worldwide propagation coverage.

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

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

It explicitly states when to use it ('Use this when the user asks whether a DNS change has landed...') and provides a when-not ('never describe it as worldwide or as propagation coverage'). It does not explicitly name an alternative tool like check_propagation, but the exclusion hints at it, so usage context is clear.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive, so the bar is lower, but the description adds substantial behavioral context: it discloses how the verdict is derived, defines the three possible verdict values, and warns that a bare PTR proves nothing because the IP owner controls the reverse zone. This goes well beyond the annotations.

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

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

The description is long but every sentence earns its place: usage trigger, mechanism, verdict definitions, the PTR caveat, the fix ownership note, and the parameter requirement. The most decision-relevant information is front-loaded in the first sentence.

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

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

There is no output schema, so the description carries the burden of explaining return values, and it does: the verdict field and its three possible values are defined with their semantics. It also covers the key operational caveat and where the fix is made, making the tool fully understandable without additional documentation.

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

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

Schema description coverage is 100%, so the schema already documents the ip parameter fully, including the requirement that it be a public IPv4 or IPv6 address. The description adds the phrase 'sending IP' and clarifies the parameter's role in FCrDNS, but this is marginal value over the schema.

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

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

The description names a specific verb and resource: 'Check one sending IP's forward-confirmed reverse DNS (FCrDNS).' It also explains the core behavior, reading the PTR record and resolving it back, which clearly distinguishes it from any sibling DMARC, SPF, or DKIM tools even without naming one.

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

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

The opening line explicitly states when to use the tool: when the user asks about reverse DNS, PTR records, or FCrDNS for a mail server IP. It does not explicitly name an alternative tool or state when not to use it, but the triggering conditions are clear enough to route an agent correctly.

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

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

The annotations already mark this as read-only/idempotent, and the description adds meaningful behavioral detail on top: the exact fields returned, the recursive counting behavior, the diagnose-only policy, and the safety rationale for not suggesting removals. It also calls out edge cases like '+all' and multiple 'all' mechanisms, going well beyond the annotations.

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

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

The description is long but every sentence earns its place: usage triggers, return fields, parameter constraints, and a behavioral caveat. It is front-loaded with the most important 'when to use' information, then proceeds logically through outputs and input rules. No filler or repetition exists.

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

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

With no output schema, the description fully enumerates the returned fields and their semantics (record_valid, findings, has_pass_all, multiple_all, terms, lookup count, over_limit/near_limit, offending_mechanisms). It also addresses input ambiguity, scope limits, and the non-fixing behavior, making the tool effectively self-contained for an agent to invoke correctly.

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

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

Schema coverage is 100% and both parameters are already described in the schema, so the baseline is 3. The description adds value by reinforcing the exclusive-or relationship ('Pass EXACTLY ONE'), clarifying the recursive vs own-terms distinction, and giving a concrete record example that maps to the 'record' parameter.

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

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

The description names a specific verb (validate, count) and resource (SPF record), and lists concrete triggers: 'too many lookups', '10-lookup limit', 'SPF PermError', or validity checks. It also declares itself 'the SPF validator — there is no separate one', which clearly distinguishes it from the sibling DNS/DMARC tools.

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

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

It explicitly says when to use the tool with user-intent examples and states the only two input modes ('domain' vs 'record'), including the exact-one constraint. It also tells the agent what the tool will not do — return a fix record — and explains why, which is an important usage boundary.

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

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

Discloses key behaviors beyond annotations: uses a validating engine, always adds np=reject, re-validates before returning, requires verbatim presentation, and mandates human approval before publishing. This adds substantial context that the readOnlyHint and idempotentHint annotations do not provide.

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

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

The description is information-dense and front-loaded with the usage trigger. The phrase 'for a domain that has none' appears twice and could be trimmed, but overall every sentence contributes meaningful guidance.

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

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

With no output schema, the description adequately conveys what the tool returns ('the generated record') and exactly what the agent should do with it ('present it verbatim'). Covers generation process, validation, special tag behavior, and the required human approval step, making the tool fully actionable.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description restates the parameter list and adds the useful fact about np=reject, but this relates to output behavior rather than parameter meaning. It does not materially enhance the schema's parameter descriptions.

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

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

States clearly that the tool creates/generates a DMARC record from scratch for a domain that has none, with a specific verb and resource. It distinguishes itself from validation and upgrade siblings by focusing on domains with no existing DMARC record.

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

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

Explicitly says to use when the user asks to create, generate, or write a DMARC record for a domain with none, which is a clear trigger condition. It does not explicitly name alternative tools, but the 'domain that has none' qualifier implies when not to use it and warns 'never compose one yourself.'

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

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

The annotations already declare readOnly, idempotent, non-destructive, and the description adds substantial behavioral detail beyond them: API token requirement, row shape with delivery_class semantics, the pagination trap where advancing `since` before paging can drop rows, the inclusive `since` floor causing duplicate rows, and the explicit design decision to avoid ack/delete. This gives the agent a rich, accurate model of tool behavior.

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

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

The description is long, but nearly every sentence carries operational value: usage trigger, row fields, delivery_class meaning, pagination warnings, inclusive-since behavior, and the read-only rationale. It is front-loaded with the when-to-use statement. It could be slightly tightened, but the length is justified by the pagination and de-duplication pitfalls.

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

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

For a read-only list/pagination tool with no output schema, the description covers everything an agent needs: when to call it, required auth, row field meanings, complete-vs-digest semantics, pagination mechanics, duplicate-row behavior, and what actions the agent should not take. There is no structural gap for a safe and correct invocation.

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

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

The schema already describes all five parameters with 100% coverage, so the baseline is 3. The description adds meaningful operational context beyond the schema: the critical ordering of `before` vs `since`, the need to de-duplicate on id, the 'unknown value is rejected' behavior on type, and the domain-ownership restriction. This elevates it above baseline.

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

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

The description opens with a specific use case — a signed-in operator asking what changed on a monitored domain or what monitoring flagged — and names the resource ('monitoring alert log') and ordering ('newest first'). It clearly distinguishes this from the domain-configuration and DMARC siblings by focusing on the alert log for monitored domains.

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

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

It explicitly states when to use the tool: when a signed-in operator asks what changed or what monitoring flagged. It also gives behavioral guardrails ('there is no ack and no delete here... let them clear it'). It does not name sibling tools as alternatives, but the trigger conditions are specific enough that an agent can select it without confusion.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, non-destructive), the description adds valuable behavioral context: records must be printed exactly as returned and never rewritten, and no DNS changes are applied by this tool. It also clarifies that a human publishes records and approval is required before proceeding, which is important operational behavior not visible from annotations.

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

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

The description is dense but every sentence earns its place: it front-loads the purpose, confirms read-only behavior, mandates exact output fidelity, and clearly explains the human-approval workflow. There is no fluff or repetition beyond the harmless restatement of 'Read-only'.

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

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

For a tool with one well-documented parameter and no output schema, the description is complete enough: it identifies exactly what records are returned, states the output fidelity requirement, and explains the surrounding workflow. An agent could select and invoke this tool correctly without any additional context.

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

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

The schema covers the single parameter 'domain' thoroughly, including what values are valid and refusal behavior. The description adds contextual framing ('the user monitors', 'still needs') but no additional parameter syntax or format details, so it neither improves nor harms what the schema already supplies.

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

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

The description states a specific verb ('Read') and a clearly scoped resource: the outstanding DNS records a monitored domain still needs. It further distinguishes the tool by naming the exact record types (ownership check, DMARC reporting record, observed status), which sets it apart from sibling tools like get_alerts or get_readiness.

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

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

The description clearly implies when to use the tool: when presenting what records still need to be published before taking DNS actions. It also gives strong workflow guidance about getting human approval before using any DNS tool. However, it never explicitly names alternatives or states when not to use this tool versus siblings like check_record or check_domain_verification.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, and the description adds substantial behavior beyond them: the API-token requirement, the null-as-answer semantics of next_record with an explicit prohibition on fabricating a stronger record, and the rule to present records verbatim pending human approval. Nothing contradicts the annotations.

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

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

Seven sentences, each carrying distinct load: trigger, purpose, auth requirement, return payload, null semantics, verbatim-output policy, and sibling contrast. Dense and front-loaded; the all-caps null warning is emphatic but earns its place given the real-mail-rejection stakes.

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

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

With no output schema, the description carries the full burden of characterizing the return payload (readiness verdict, blockers, evidence window, next_record with its null semantics) and discharges it completely. Auth, error behavior via the schema, when-to-use, and the human-approval workflow are all covered; nothing essential is missing for a one-parameter read.

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

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

Schema coverage is 100% and the schema already documents the parameter thoroughly, including ownership verification and the 'refused as not found; ownership is never disclosed' behavior. The description reinforces the single-domain scope but adds little parameter-specific meaning beyond the schema, 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.

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

States a specific verb and resource: reading the DMARC enforcement-readiness verdict for ONE monitored domain, computed from its aggregate RUA report window. This scope precisely distinguishes it from siblings like scan_domain (current policy, not readiness) and validate_dmarc_record.

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

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

Opens with the exact trigger condition ('signed-in operator asks whether a monitored domain is ready for the next DMARC step') and closes by naming the alternative: 'a scan can show a domain's current policy, but only this evidence window can say whether tightening it would start rejecting real mail.' When-to-use and the deciding contrast against scan_domain are both explicit.

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

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

Annotations already indicate idempotency and non-destructiveness, and the description complements them by disclosing the conditional one-time scan behavior and the inclusion of scanned_at for staleness assessment. This adds useful behavioral context beyond the structured hints without contradicting them.

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

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

The description is front-loaded with the key usage distinction, but it repeats the same get_report-versus-scan_domain guidance at the start and end. Phrases like 'cheap first look', 'cheap read', and 'right default' also overlap, adding mild redundancy without much new information.

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

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

With no output schema, the description does the necessary work of explaining the report structure: seven checks, each with status, observed record, and fix record, plus scanned_at. It also covers the conditional scan behavior, making the tool sufficiently described for reliable invocation.

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

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

The input schema already provides full parameter coverage with detailed domain format guidance including punycode normalization. The description adds no new parameter semantics beyond restating that the tool operates on a domain, so the schema carries the burden.

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

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

The description clearly states the tool returns a stored domain report and conditionally scans if none exists. It explicitly distinguishes get_report from scan_domain by naming both and describing their relationship, so an agent can select it correctly.

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

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

It gives explicit when-to-use guidance: use get_report when a recent report is enough and scan_domain when the state must be re-read now. It also names a concrete example, after a DNS change, where scan_domain is preferred, making the decision rule actionable.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description aligns by stating 'Observation only: no record is composed.' It then adds substantial context beyond the annotations: redacted:true is the normal post-GDPR outcome rather than a failure, unknown means the registry did not answer (not absence) with a reason field distinguishing rate-limit/timeout/error/no-RDAP-service, and the instruction to report rather than advise. No contradiction with annotations.

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

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

A single dense paragraph, but every clause earns its place: the front-loaded trigger, the RDAP field inventory, the redacted-normal caveat, and the critical guardrails about status semantics and buy-advice. It is long but information-dense with no filler; a slightly more structured layout would push it to a 5, but the density is justified for a decision-relevant lookup tool.

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

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

With no output schema, the description carries the full burden of explaining the return semantics, and it does so thoroughly: enumerates the returned fields (registrar with IANA id, dates, EPP status codes, nameservers, DNSSEC delegation, abuse contact), defines all three status values, and covers failure modes (rate limit, timeout, registry error, TLD without RDAP). Nothing an agent needs to interpret the response correctly is missing.

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

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

Schema coverage is 100% — the schema already documents the domain parameter thoroughly (format, bare names and subdomains accepted, punycode normalization, exclusion of scheme/path/port). The description adds no parameter-specific detail beyond what the schema provides; its extra information concerns response semantics (status values, reason), which belongs to behavioral transparency rather than parameter semantics. Baseline 3 is appropriate.

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

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

Opens with a precise trigger condition ('Use this when the user asks who owns a domain... the WHOIS question') and names the specific operation: read a domain's registration from the registry over RDAP. The verb+resource is unmistakable, and no sibling tool performs WHOIS/registration lookup, so it distinguishes itself clearly without needing to name an alternative.

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

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

Gives an explicit when-to-use with a concrete list of triggering questions (ownership, expiry, registrar, nameservers, registration status, transfer/delete locks). It also adds strong post-call behavioral guidance — never advise buying on pendingDelete, never claim a name is free unless status is exactly not_registered. It stops short of naming specific sibling alternatives or when-not conditions, which keeps it at a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description reinforces and extends this by stating 'Nothing is stored — the report is parsed and discarded.' It also discloses input format handling (XML, .gz, .zip), the 2 MiB limit, and content-based format detection, adding behavioral context beyond the annotations.

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

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

The description is a compact paragraph with no filler. The use condition is front-loaded, followed by what the tool does, how to pass the input, and a closing safety note. Every sentence contributes essential operational detail.

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

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

With no output schema, the description compensates by summarizing the return content: readable per-source aggregates covering sender, volume, and alignment share. It also covers input formats, size limits, storage behavior, and parameter semantics, making the tool fully invocable without further inference.

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

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

The schema already documents both parameters, but the description adds meaningful usage semantics: it instructs to base64-encode raw file bytes, warns against pasting raw XML, specifies 'exactly as received,' and clarifies that filename is only for logs and does not affect parsing. This materially helps an agent construct the correct invocation.

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

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

The description uses a specific verb and resource: 'Parse ONE DMARC aggregate (RUA) report' and clearly defines the output as per-source aggregates, including sending domains, volume, and SPF/DKIM alignment shares. This distinguishes it from sibling tools like validate_dmarc_record or get_report, which address different DMARC operations.

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

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

The opening line, 'Use this when the user uploads or pastes a DMARC aggregate (RUA) XML report and asks what it says,' provides a clear trigger condition. It does not explicitly name alternatives or exclusion criteria, but the context is specific enough to guide selection among the sibling tools.

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

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

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses cache-first behavior, the dedup window, that repeated scans reuse stored reports, and that SPF is diagnose-only while DMARC/DNS have fix_record generation. This adds substantial context beyond structured fields.

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

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

The description is long but well-structured: it leads with usage triggers, then explains the scan checks and caching behavior, and ends with differentiation from get_report. Every sentence carries useful information, though slightly dense.

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

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

For a tool with no output schema, the description explains the report contents (seven checks, status, observed record, fix_record) and the caching caveat. It covers all necessary behavioral aspects for correct invocation, including how to handle verification scenarios.

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

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

Schema coverage is 100% and the schema description already covers parameter nuances (bare names vs subdomains, no scheme/path/port, Unicode normalization). The tool description does not add further parameter semantics, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: scanning a domain for email/DNS issues, listing seven specific checks (SPF, DKIM, DMARC, MX, DNS hardening, expiry, blacklist). It differentiates from sibling get_report by stating when to use each, and lists the exact user intents that trigger it.

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

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

Explicitly tells when to use (when user asks to check/audit/diagnose/fix) and when not to (use get_report for cached answers). Also explains the dedup window and the need to check scanned_at after edits, giving clear guidance on usage timing.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false, and the description richly expands on this by stating that nothing is created, no email is sent, the domain is only carried over after the human signs in, and monitoring starts only after TXT ownership proof. It also clearly instructs how to relay signup_url and message, with no contradiction to annotations.

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

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

The description is long but front-loaded with clear usage conditions and each sentence carries important operational detail, especially the verbatim signup_url printing instruction. It could be tightened slightly, but the density is justified by the security-sensitive nature of handing off to a human.

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

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

For a one-parameter tool with rich annotations and no output schema, the description is fully sufficient: it states when to trigger it, what the call returns, what the call does not do, what the agent must relay, and the ownership-verification flow. No critical operational information is missing.

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

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

Schema coverage is 100% and the parameter description already explains domain format, punycode normalization, and that schemes/paths/ports are invalid. The tool description adds the fact that the domain is carried over to the dashboard later, but this is not needed to invoke the single parameter correctly.

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

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

The description names a precise set of user intents (DMARC monitoring, RUA report monitoring, new-sender monitoring, alerts, DNS monitoring, DNS Doctor trial) and states that the tool returns a sign-up link for a human domain owner. This clearly distinguishes it from sibling tools that scan, validate, or manage DNS records.

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

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

The description explicitly says when to use it: when the user wants monitoring or at the end of a scan that found issues on a user-owned domain. It also clarifies what the tool does not do (creates nothing, sends no email, does not sign in), but it does not name alternative sibling tools or give explicit conditions for choosing them instead.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds further non-obvious facts: no DNS lookup is performed, the output grades findings by level, and a pasted record cannot unlock p=reject. This is substantive behavioral context beyond the annotations.

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

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

The key points are front-loaded: use case first, then what validation returns, then the no-DNS-lookup constraint. The upgrade_record caveat is somewhat long and tangential but carries useful routing information, so it earns its place even if it could be tightened.

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

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

For a single-parameter read-only validation tool, the description covers the trigger, the accepted input form, the output categories, and a notable policy limitation. No output schema exists, but the description tells the agent what to expect and to present any returned record verbatim.

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

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

The schema already describes the single parameter thoroughly, including an example and the distinction between the record value and the _dmarc hostname; schema coverage is 100%. The description only restates 'pass the record string itself', so it adds little additional parameter meaning.

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

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

The description opens with a specific use case (pasted DMARC record asked about validity/correctness/safety) and names the concrete outputs: parsed tags, level'd findings, and validity. It also states what the tool does not do ('No DNS lookup'), which distinguishes it from check_record and scan_domain.

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

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

It explicitly says to use this when the user pastes a DMARC record string, and it contrasts with upgrade_record by explaining when stronger-policy previews are off-limits (p=reject requires reporting-window evidence). This gives the agent clear routing criteria versus related tools.

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