MX Verdict

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: checking is scoped by target type, and domain blocklists differ from IP-based mail-server checks.

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

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

Two sentences, no filler, with the core purpose front-loaded and the input rule immediately after. Every clause carries operational weight.

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

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

For a one-parameter, read-only lookup with full annotation coverage, this is sufficient to call correctly. The only mild gap is the absence of any note on the shape of the result (listed/not listed, which blocklists), which matters slightly since no output schema exists.

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?

With 100% schema coverage and a single required parameter, the baseline is 3. The description goes further by explaining the semantic distinction between supplying an IPv4/IPv6 address versus a domain name and what each is checked against, adding meaning the schema itself does not convey.

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 whether an IP or domain appears on public DNS blocklists (DNSBLs). It also scopes the operation ('A domain is checked on domain blocklists only'), which lets an agent distinguish it from the DNS-record siblings like check_spf or lookup_mx without opening a schema.

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

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

It gives clear conditional guidance on input selection: use a domain for domain blocklists, use the IP address to check a mail server. It does not explicitly name alternative tools or state when this check is unnecessary, so it stops short of a 5, but the context 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: the no-selector mode probes common names, and a negative result is not proof of missing DKIM because selectors cannot be enumerated from DNS. That false-negative caveat is real value 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?

Three compact sentences: purpose first, then the selector semantics, then the interpretation caveat. Every sentence carries information and nothing is padded.

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

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

For a two-parameter read-only DNS check with no output schema, the description covers both modes and the key interpretive risk (false negatives). An agent has everything it needs to call this correctly and to interpret a negative result.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds semantic meaning the schema lacks: it identifies the selector as the s= tag of a DKIM-Signature header and clarifies that omitting it triggers a common-name probe, which explains the optional parameter's behavior rather than just its format.

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 ('Check a domain's DKIM public keys in DNS') and immediately scopes the operation to the DKIM record type, which cleanly separates it from check_dmarc, check_spf and check_blacklist. No ambiguity about what is being queried.

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 describes the two invocation modes: pass a selector to check that specific key, omit it to probe common selector names. It does not name sibling alternatives (e.g. check_dmarc) or say when DKIM checking is the right tool versus them, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully discloses what the check inspects (policy values, alignment, report destinations), which substitutes for the absent output schema, but adds nothing about auth needs, rate limits, or behavior when no record is found.

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

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

A single front-loaded sentence that states the action first and then the specific attributes returned. Every clause carries information; no filler or repetition of the title.

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

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

For a single-parameter read-only lookup with no output schema, the description does the necessary work by enumerating the returned fields (existence, validity, policy, alignment, report destinations). It is nearly complete; only edge-case behavior, such as the response when no DMARC record exists, is left unstated.

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?

Only one parameter exists and schema coverage is 100%, with the schema itself supplying the example ('example.com'). The description adds no syntax, format, or validation detail beyond the schema, so the baseline 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 (check) and resource (a domain's DMARC record) and enumerates what the check covers: existence, validity, policy, alignment, and reporting destination. The resource is inherently distinct from siblings like check_spf and check_dkim, but the description never explicitly differentiates itself from them.

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 phrasing 'Check a domain's DMARC record' implies the usage context (validating email authentication for a domain), but there is no explicit when-to-use guidance, no when-not-to-use, and no routing to alternatives such as check_spf or check_email_domain. Usage is inferable but not stated.

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

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is handled. The description adds value by disclosing the breadth of external lookups (blocklists, MTA-STS, BIMI, DKIM on common selectors), implying multiple network calls, though it omits latency, rate limits or result format.

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

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

Two sentences, zero waste. The scope of checks is front-loaded and the usage cue follows immediately, making it easy to scan.

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

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

With no output schema, the description compensates by enumerating what is inspected, which is enough for an agent to know the result is a multi-check health report. Minor gaps (return shape, per-check failure semantics) remain but are not blocking.

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?

Only one parameter ('domain'), and schema coverage is 100% with a clear example in the schema itself. The description adds no format or constraint detail beyond the schema, so the baseline 3 is appropriate.

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

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

Names a specific verb+resource ('check everything about a domain's email setup') and enumerates the exact checks performed (SPF, DMARC, MX, DKIM, blocklists, MTA-STS, TLS-RPT, BIMI). This clearly distinguishes it from the granular siblings like check_spf, check_dkim and check_dmarc.

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

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

Explicitly routes the agent with 'Use it for a general question such as "is email set up correctly for example.com"', which signals aggregate use versus the single-check siblings. It stops short of naming those siblings or stating when NOT to use it (e.g., for a targeted DKIM-only check).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered structurally. The description adds genuine semantic context by naming exactly what the check evaluates (the 10-lookup limit, all-mechanism treatment of unlisted senders), which 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?

A single, front-loaded sentence that names the subject first and then lists the three evaluated facets. No filler and no redundancy with the schema or annotations.

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 present, the description must signal what comes back, and it does by enumerating the three result dimensions (existence/validity, lookup count, all-mechanism behavior). It is nearly complete; it could still hint at how a count-over-limit or missing record is reported, but an agent has enough to call and interpret it.

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

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

There is a single parameter with 100% schema description coverage ('Domain name, for example example.com.'), so the schema already carries the semantics. The description adds no format, normalization, or edge-case detail for the domain argument, making the baseline 3 appropriate.

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

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

The description states a specific verb (Check) and resource (a domain's SPF record) and immediately enumerates the exact facets examined: existence/validity, DNS lookup count, and all-mechanism behavior. This is far more precise than a sibling like check_dkim or check_dmarc, so an agent can distinguish it by resource without opening the schema.

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

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

Usage is implied by the resource (you call it to audit a domain's SPF configuration), but there is no explicit when-to-use/when-not guidance and no routing to or from the sibling check tools. Nothing tells the agent whether this is a standalone check or part of a combined email-domain audit.

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, open-world, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: ALL expands to a defined set of record types, and an IP input silently switches to a PTR reverse lookup. No output format or failure behavior is described, hence not a 5.

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

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

Three short sentences, front-loaded with the verb and resource, then the default behavior, then the IP special case. No filler and nothing redundant with the schema.

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

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

For a two-parameter read-only lookup with no output schema, the description covers the essential call semantics: what to pass, what the default does, and the reverse-lookup edge case. It stops short of describing result shape or the enum types not covered by ALL, but nothing critical to correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: it defines ALL as a query of A, AAAA, CNAME, MX, NS, TXT, SOA and CAA, and explains that an IP-valued name produces a PTR lookup. Note it does not account for the SRV/DS/DNSKEY/TLSA/HTTPS/SVCB enum values that ALL apparently omits.

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 ('Look up DNS records of a name') and clarifies the ALL default and reverse-PTR behavior. It implicitly separates itself from siblings like lookup_mx and check_dmarc, but never names an alternative, so it stops short of full sibling differentiation.

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?

Explains what the default ALL does and that a single type can be requested, but gives no explicit when-to-use versus the sibling tools (lookup_mx, check_spf, check_dmarc) that overlap in domain-record territory. Usage is implied rather than directed.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuine context beyond them by scoping the operation to 'DNS only: it does not connect to the mail servers', clarifying that no SMTP probing occurs, and by naming the returned data (IPs and reverse DNS) since there is no output schema.

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

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

Two tight sentences with the primary purpose front-loaded, immediately followed by the scope constraint and return contents. Every clause carries information; nothing is wasted.

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 tool with rich annotations and no output schema, the description covers purpose, scope boundary, and the shape of the result (IPs, reverse DNS). Nothing an agent needs to invoke it correctly is missing.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents 'domain' with an example. The description adds no formatting or validation nuance (e.g. punycode, subdomain handling), leaving this at the baseline 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 ('Look up a domain's MX records') and glosses the resource ('its incoming mail servers'), so the agent knows exactly what is returned. It does not explicitly contrast itself with the sibling dns_lookup, which is the likely generic alternative, so it stops short of 5.

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

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

No explicit when-to-use or when-not-to-use statement, and no sibling alternative (e.g. dns_lookup) is named. The narrow MX framing makes appropriate usage inferable, but the agent must do that inference itself.

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