WarmInboxes Free Deliverability Tools

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's burden is lower. It adds real value by disclosing the output shape — classification, severity class, cause, and recommended action — which is essential since there is no output schema. It does not mention any limits on input size or how ambiguous/unknown bounces are handled.

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: the first front-loads the action, the taxonomy of outputs, and the per-item result fields; the second is a single useful operational instruction. No filler or redundancy.

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-input tool with no output schema and strong annotation coverage, the description supplies the important missing piece — what the return values mean. Only minor gaps remain (behavior on unrecognized bounce text, order of returned items).

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 one parameter and 100% schema coverage, the schema already documents the field fully. The description's 'separate several bounces with a blank line' restates part of the schema and actually omits the '---' separator the schema also permits, so it adds no 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 uses a specific verb ('Classify') with a specific resource ('bounce messages (NDRs)'), enumerates the exact categories it produces, and states what each result contains (hard/soft/block, cause, remediation). It is clearly distinct from siblings like analyze_headers or analyze_dmarc_report without opening any 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?

The context is clear — the tool takes pasted bounce message text — and the final sentence gives concrete operational guidance on handling multiple bounces. What's absent is any explicit when-not condition or comparison to alternatives (e.g. analyze_headers for full raw messages, check_suppression for list hygiene), leaving routing to inference.

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 read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds real value by enumerating what is inspected (trigger words by category/severity, ALL-CAPS, links/shorteners, offers, obfuscation, personalisation/opt-out, length) and by stating the scope limit. It does not disclose scoring thresholds or how weights combine, which keeps it from 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?

A single dense paragraph that front-loads the verb, score scale, and timing before enumerating checks; every clause carries information. The mid-sentence list of checks is long but functional, and the scope caveat lands last where it is easy to miss.

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 stating the return shape ('each finding with how much it cost and how to fix it'), and it covers scope limits, inputs, and scoring model. An agent has everything needed to call it and interpret results.

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 both parameters are already fully documented, including the note that subject-line triggers weigh extra. The description's parenthetical '(subject hits weigh extra)' merely restates the schema, adding no new syntax or format guidance.

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, resource, and output scale: 'Score a cold email's copy 0-100 for spam risk before it is sent.' It also draws a hard boundary ('Content only: it cannot see reputation or authentication'), which cleanly separates it from check_domain_reputation and check_deliverability among the siblings.

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?

'before it is sent' gives clear timing for when to invoke it, and the closing limitation tells the agent when this tool is insufficient. It stops short of naming the sibling tools to use for reputation/authentication checks, so the routing is implied rather than 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 declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral detail beyond that, including output ordering (failing senders first) and duplicate-report deduplication, though it does not discuss errors, size limits, or malformed input handling.

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 core action and resource, then efficiently lists the report contents and input options. Every sentence contributes useful information with no filler.

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 explains what the tool reports: passing/failing counts, alignment-only failures, quarantine/reject counts, and per-IP SPF/DKIM outcomes. A small gap remains around whether at least one input form is required in practice and how errors are surfaced.

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 both xml and gzipBase64 are already well documented. The description reinforces accepted input forms and duplicate handling, but adds little parameter semantics beyond what the schema already states.

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: reading DMARC aggregate (rua) reports and reporting senders, pass/fail outcomes, alignment failures, and per-IP SPF/DKIM results. This is clearly distinct from DMARC record-checking siblings, though it does not explicitly name the alternative 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?

Usage is implied by the resource itself: use this when you have a DMARC aggregate report to analyze. However, it does not explicitly say when to use this versus check_dmarc or check_email_authentication, nor does it state prerequisites or exclusions beyond input format notes.

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 readOnlyHint and openWorldHint annotations, the description discloses important behavior: parsing is inert, nothing loads, no tracking pixel fires, and no link is followed. It also warns that SURBL lookups consume the daily free limit, which is critical operational context.

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 core action and outputs, then adds safety and quota context. Every sentence provides useful information without repetition or filler.

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 lists what is returned: clipping-size analysis, link and image hosts, tracking pixels, URL shorteners, and SURBL results. Combined with annotations and schema, an agent has enough information to call 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?

Schema coverage is 100%, so the schema already defines both parameters. The description adds meaningful semantics for scan by explaining that SURBL lookups consume the daily free limit and can be disabled, which goes beyond the schema's brief wording.

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: reading an email's HTML and returning size, link/image hosts, tracking pixels, shorteners, and SURBL checks. This is clearly distinguishable from sibling tools like analyze_headers or check_surbl, which operate on different inputs.

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 a clear usage rule for the scan parameter: SURBL lookups count against the daily free limit and can be skipped by setting scan to false. It does not explicitly compare this tool to alternatives such as check_surbl, but the intended 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 declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, and the description reinforces the offline nature with 'Text only: nothing is looked up or stored.' More importantly, with no output schema present, it discloses exactly what the response contains: verdicts, alignment reasoning, relay hops and delays, sending IP, plain-English issues, and RFC 8058 List-Unsubscribe evaluation.

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?

One sentence, front-loaded with the action ('Read a received message's raw headers'), followed by the return payload. Every clause carries distinct information and the closing constraint is placed last for emphasis; no filler.

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-input, no-output-schema tool, the description covers the safety profile via annotations and enumerates the returned fields thoroughly, so an agent knows what to expect back. Nothing material for 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 description coverage is 100% and the single parameter is fully documented there (raw header block, Gmail 'Show original' hint). The description adds only the 'received message' qualifier, not new format or edge-case guidance beyond the schema. Baseline 3 applies when the schema does 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?

States a specific verb and resource: 'Read a received message's raw headers', and enumerates the verdicts returned (SPF/DKIM/DMARC as recorded by the receiver, alignment, hops, sending IP). It implicitly separates itself from DNS-checking siblings by stressing 'receiver recorded' and 'nothing is looked up', but never names the closest alternative (analyze_microsoft_headers) or any sibling explicitly.

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 scope ('a received message's raw headers') and a concrete use case ('why DMARC failed on a message that passed') imply when to reach for it, and 'nothing is looked up' hints that check_dkim/check_spf/check_email_authentication serve a different purpose. However, there is no explicit when-to-use/when-not or named alternative, so routing must be inferred.

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 establish that this is a read-only, idempotent, non-destructive operation, so the description does not need to repeat safety details. It adds useful behavioral context by naming the Microsoft-specific verdict fields and saying each is explained, though it does not describe error behavior or output shape.

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, both front-loaded and purposeful. The first sentence names the tool's domain, returned fields, and Microsoft scope; the second sentence routes the agent to the correct sibling when appropriate.

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 responsibility for explaining what comes back, and it does so by listing the verdict and authentication fields. It is nearly complete for correct invocation, though it does not specify the exact output format beyond saying fields are explained.

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 single headers parameter is fully documented in the schema as the full raw headers of a message delivered to a Microsoft mailbox. The description reinforces that the input is Microsoft-specific raw headers but adds no syntax, examples, or format details beyond the schema, 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?

States a specific verb and resource: reading the spam verdict Microsoft 365 or Outlook stamped on a delivered message. It enumerates the exact verdict and authentication fields returned (SCL, BCL, PCL, SFV, category, SPF/DKIM/DMARC) and explicitly distinguishes itself from analyze_headers.

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 a direct usage condition: use it when mail lands in Outlook junk. It also names the alternative analyze_headers for Gmail or other providers' routing and alignment, making the routing decision 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 establish that this is read-only, idempotent, and closed-world, so the description does not need to repeat safety traits. It does add substantive behavioral detail by naming the cross-checks performed: merge tags vs. columns, sequencer parsing, role/disposable addresses, duplicates, per-company limits, and a send forecast.

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 purpose and then lists the audit checks efficiently. It is dense but mostly earns its length; the final sentence slightly restates required inputs already covered by the schema and 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?

For a seven-parameter audit tool with full schema coverage and read-only annotations, the description gives enough context to understand the checks and inputs. It does not describe the return format or how findings are presented, which is a gap given there is no output schema, but the core invocation context is present.

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 description coverage, the schema already documents all seven parameters, defaults, and the daysPerWeek enum. The description reinforces that the CSV text and every sequence step are required, but adds little parameter meaning beyond what the schema already provides.

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: 'Audit a cold email campaign before launch', then enumerates the audit dimensions. It is clear what the tool does, but it does not explicitly differentiate itself from nearby siblings such as analyze_cold_email, clean_csv, or verify_email.

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 phrase 'before launch' implies the appropriate moment to use it, and the closing sentence tells the caller to pass the CSV and sequence. However, there is no explicit guidance on when not to use it or which sibling tools to use instead for cleaning, verification, or post-launch analysis.

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 (readOnly, idempotent, non-destructive, not open-world), and the description adds the critical behavioral fact that this is guidance-only and performs no determination itself, plus what the result contains (a link and named checks). It stops short of describing any other limits, but for a link-returning guidance tool the key disclosure is present and consistent with openWorldHint=false.

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, front-loaded with the destination and the core limitation, with zero filler. Each clause earns its place by either routing or disclaiming.

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 guidance-only tool with no output schema and one optional param, the description supplies everything needed: destination, the fact that no judgment is made, and which sibling checks to combine. Nothing required 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?

Schema description coverage is 100% for the single optional 'domain' parameter, so the schema already carries its meaning. The description only alludes to it ('whether an inbox or domain is burned') without adding format or handling detail; 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 action (directs the person to the external Burned Inbox Checker) and explicitly disclaims what it does not do ('Does not itself determine whether an inbox or domain is burned'). It also names the sibling tools that answer parts of the question, so an agent can distinguish it from the analyze_/check_ tools 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?

Gives explicit routing: use this for the external Burned Inbox Checker link, and names check_domain_reputation and check_deliverability as the in-product tools that answer part of the question. Both the when-to-use and the alternative are 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful context by enumerating the four things validated and the Gmail enforcement condition, but says nothing about the return format, whether lookups are live against DNS, or what a failed result looks like.

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 single front-loaded sentence with zero filler. It puts the verb and the validated components first and does not waste words on redundant name restatements.

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 validation tool with one parameter and no output schema, the description covers what is checked but not what is returned. It also does not resolve the overlap with check_dmarc, which checks one of the same underlying requirements. It is adequate but leaves the agent guessing at result shape and sibling routing.

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% and the sole parameter 'domain' is already documented with an example. The description adds no extra meaning about the domain parameter, such as whether it must be the organizational domain or how subdomains are handled, 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.

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

The description names a specific verb (Validate) and the exact resource scope: BIMI record, logo SVG, VMC, and Gmail's DMARC enforcement requirement. It is far more specific than a tautology and tells the agent precisely what is checked. It does not explicitly differentiate from siblings like check_dmarc or check_dkim, which keeps it at 4 rather than 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?

There is no statement of when to use this tool versus alternatives, even though sibling tools such as check_dmarc and check_dkim overlap with parts of the described validation. The description implies usage for anyone wanting to check BIMI, but gives no exclusions, prerequisites, or routing guidance.

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 elsewhere. The description adds genuinely new context by quantifying the check ('20+ major blacklists') and naming examples (Spamhaus, Barracuda, SORBS), which helps interpret results. It omits operational caveats such as query latency, RBL rate limits, or the possibility of false positives on shared IPs.

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?

One sentence, front-loaded with the action and scope, with the reported outcome trailing it. Every clause earns its place 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 single-parameter read-only check with no output schema and rich annotations, the description covers what is queried, against how many lists, and roughly what comes back. Only the absence of timing/rate-limit expectations and sibling disambiguation keeps it short of complete.

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% and there is a single required parameter whose schema text ('A domain or an IPv4 address') fully documents accepted input. The description restates the same domain/IP acceptance without adding format rules or edge cases such as IPv6 or subdomain handling, so 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?

The description gives a specific verb ('Check') and resource ('a domain or IP against 20+ major email blacklists') and explicitly states the output ('report which list it appears on'). It does not differentiate itself from close siblings such as check_surbl or check_domain_reputation, so an agent must infer the boundary rather than being told 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?

Usage is only implied: the wording suggests use when validating sending domains/IPs for deliverability or spam-listing problems, but there is no explicit when-to-use statement, no prerequisites, and no named alternative such as check_surbl. The agent can guess the context but is given no routing guidance.

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 read-only, open-world, idempotent, non-destructive behavior. The description adds useful context by explaining DNS-based checks, conditional checks, and explicitly naming unchecked requirements (complaint rate, per-connection TLS) rather than passing them. It does not detail return format, but the limitation disclosure is valuable.

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 sentence front-loads the purpose and packs all checks and conditions. 'Sorted honestly' is slightly editorial and the semicolon list is long, but no substantive content 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?

Given the composite complexity and rich annotations/schema, the description covers scope, conditional inputs, and limitations. It lacks an explicit description of return values, though 'named as not checked rather than passed' partially indicates result semantics.

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, but the description adds meaning beyond the schema for optional ip (forward/reverse DNS) and headers (one-click unsubscribe and From alignment). The domain parameter's role in DNS checks is implied rather than restated.

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 resource (Gmail/Yahoo/Microsoft bulk sender requirements) and enumerates the checks performed, distinguishing it from single-purpose siblings like check_spf and check_dmarc. It also explicitly scopes what is and is not covered.

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 clear context by specifying that ip enables forward/reverse DNS and headers enable unsubscribe/alignment checks, implying this is the composite compliance check. It does not name alternative sibling tools or when to prefer them.

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 that the tool flags specific misconfigurations and that passing expected turns the call into an assertion, but it doesn't say which mistakes are flagged, what a mismatch yields, or how failures are reported.

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 action and scope front-loaded and the optional-parameter behavior immediately after. Every clause carries information the agent can act on.

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 should carry return-shape information, yet it only gestures at 'flag the mistakes' without saying what the response contains (chain hops, error classification, pass/fail). For a low-complexity two-parameter read tool this is adequate but leaves a real gap on return values.

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 carry descriptions, so the baseline is 3. The description only slightly extends the schema by framing 'expected' as an assertion ('assert where the chain should end up') versus the schema's neutral 'should resolve to'; it adds no format or failure-mode detail.

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+resource ('Follow a host's full CNAME chain') and adds the diagnostic intent ('flag the mistakes that break a cold-email tracking domain'), which tells the agent this is a CNAME-specific health check. It doesn't explicitly differentiate from close siblings such as check_dns, check_nameservers, or check_tracking_domain, so the agent must infer the boundary.

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?

'Pass expected to assert where the chain should end up' clarifies how to use the optional assertion mode, which implies verification use. However, there is no statement of when to prefer this over check_dns or check_tracking_domain, and no exclusions or prerequisites, so usage is only implied.

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, so the safety profile is covered. The description adds real value beyond them by disclosing the return shape — a weighted A-F score, per-check breakdown, and remediation guidance — which no output schema provides here. It does not mention lookup latency or which blacklists are consulted, keeping it at a 4.

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 with zero waste: capability first, return content second, entry-condition last. Every sentence carries distinct information an agent needs.

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 tool with no output schema, the description covers what is checked, what comes back (weighted score, per-check breakdown, fixes), and when to reach for it. 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?

There is a single parameter with 100% schema description coverage, and the schema already clarifies "Not an email address" with an example. The description adds no additional parameter meaning, 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 and resource ("Grade a domain A-F") plus the domain of concern (cold email readiness), then enumerates exactly what is inspected. The phrase "checks SPF, DKIM, DMARC, MX, blacklists and domain age together" implicitly separates it from the many single-check siblings (check_spf, check_dmarc, check_blacklist) 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?

"Start here for open-ended 'is this domain any good' questions" gives a clear entry condition that selects this tool over the granular per-record checks. It stops short of an explicit when-not clause (e.g., 'if you already know which record failed, use check_spf'), so it is strong context without full routing.

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 safe, read-only, idempotent profile, so the description focuses on behavior the annotations can't express: the 26-selector scan width and the CNAME-delegation diagnostic for Microsoft 365. It does not describe the shape of the success/failure output, which matters because there's 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?

Three sentences, front-loaded with the core action, then selector semantics, then the notable failure mode. No filler; every sentence carries 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?

For a simple two-parameter read tool with no output schema, this covers what it scans, when it scans, and what it reports on failure. The main remaining gap is a hint about what a successful result contains beyond key strength.

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; the description adds value by quantifying the auto-scan (26 selectors) and naming representative selectors (google, selector1, k1), which the schema only gestures at.

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 ("find and validate a domain's DKIM signing key") and adds scope (key strength). This is clearly distinguishable from sibling checks like check_spf, check_dmarc, and check_email_authentication.

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 exactly when to leave the selector empty and what that triggers (26-selector auto-scan), which is practical usage guidance. It stops short of naming when to prefer a sibling tool such as check_dns or check_email_authentication for broader diagnostics.

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 safety, so the description instead adds output shape ('each explained') and, more valuably, interpretive behavior: p=none legitimately passes Google/Yahoo requirements and quarantine is the stricter next step. This steers how the agent reports results, well beyond what the annotations declare.

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?

Front-loaded with the action and returned fields, then two tight advisory sentences. The policy interpretation sentences earn their place because they prevent a common wrong conclusion, though the second half is more advisory than definitional.

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?

No output schema exists, and the description compensates by describing what is returned and that tags are explained. For a single-parameter, read-only lookup this is nearly complete; only cross-tool routing 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% and the single 'domain' parameter is documented with an example in the schema, so the schema carries the load. The description adds no additional parameter detail; 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?

Specific verb+resource: 'Look up and parse a domain's DMARC record', with the returned fields (policy, subdomain policy, percentage, alignment, reporting tags) enumerated. It is implicitly distinguishable from analyze_dmarc_report (which analyzes reports) and check_spf/check_dkim, though no sibling is named explicitly.

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 context is implied by 'look up and parse a domain's DMARC record' and reinforced by interpretation guidance for p=none vs p=quarantine. However, it never states when to prefer this over check_email_authentication, check_bulk_sender_requirements, or analyze_dmarc_report, so the agent must infer routing.

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. The description adds nothing beyond that – no note on which resolver is used, propagation/caching behavior, timeouts, or failure handling for NXDOMAIN – so it contributes no behavioral context of its own.

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 efficient sentence, front-loaded with the verb and resource. It is tight, though the record-type enumeration is largely duplicated by the schema's type parameter.

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?

A simple two-parameter read tool with full schema and annotations, so most of what an agent needs is present. But with no output schema, the description does not say anything about the shape of the response (per-record values, empty results), leaving a real gap.

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%, including the note that type defaults to MX. The description's record-type list is redundant with the schema, so the baseline 3 applies with no added 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?

States a specific verb and resource (query DNS records for a domain) and enumerates the supported record types, which tells an agent this is the generic DNS lookup. It does not, however, distinguish itself from specialized siblings like lookup_mx, lookup_txt, or check_cname.

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 only implied: the phrase 'any DNS record type' suggests it is the general-purpose option versus the targeted sibling checks. There is no explicit when-to-use/when-not and no mention of which sibling to prefer for a single record type, nor any prerequisites.

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 safety is covered. The description adds genuinely useful implementation context beyond that: resolution is via RDAP with a WHOIS fallback specifically for ccTLDs lacking an RDAP service, which tells the agent to expect degraded or variant behavior outside gTLDs. It does not mention failure modes if both sources fail, which keeps it below 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?

Two sentences: the first is a dense statement of outputs and resolution mechanism, the second is a one-line justification of why the tool matters. Nothing is redundant and the outputs 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?

For a one-parameter read-only lookup it covers what is returned, how it is resolved, and why it matters, which is sufficient to invoke it correctly. The only remaining gap is expected behavior when neither RDAP nor WHOIS yields data for an obscure ccTLD.

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 required parameter with 100% schema description coverage including an example ('acme.com'), so the schema fully documents the input. The description adds no format or normalization guidance (e.g., whether to pass a URL or subdomain), 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 (get) and enumerates exactly what is returned: registrar, creation date, expiry date, days remaining. This clearly separates it from sibling checks like check_domain_reputation, check_ssl, or check_nameservers, which look at different attributes of the same 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?

The closing sentence gives a rationale ('domain age is one of the strongest cold-email risk signals'), which implies the scenario — pre-send risk assessment on a cold-email domain. However, it never states when to prefer this over the many adjacent domain checks in the sibling list (reputation, blacklist, Google domain, tracking domain), so the routing decision is left to inference.

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 a safe, read-only, idempotent lookup, so the safety profile is covered. The description adds genuinely useful context above that bar: no reputation score is returned, and Spamhaus DBL is reported as 'not checked' rather than 'clean' when the paid key is absent. It does not, however, describe response shape or latency/caching behavior. A 3 reflects that the annotations carry most of the behavioral weight.

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?

Four compact sentences, each carrying a distinct fact: use case, signals checked, verdict taxonomy, and the two caveats about scores and Spamhaus. Front-loaded with the triggering scenario. The first sentence is slightly idiomatic but not wasteful.

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 available, the description correctly enumerates the possible verdicts and explains what the tool rules out, which is exactly what an agent needs to interpret results. The mutation-free, single-parameter nature makes remaining gaps minor.

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, fully documented in the schema (100% coverage with an example). The description adds no semantics beyond the schema, so the baseline of 3 for high-coverage schemas 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 ('Checks the domain against SURBL, its authentication, its age and the address its website resolves to') and defines the output space (listed, broken, young, clean, unknown). It implicitly differentiates itself from single-check siblings like check_surbl by bundling multiple signals, but never names an alternative explicitly.

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 scenario quote ('this domain used to land and now it does not') gives a clear triggering situation, and 'returns a verdict by elimination' clarifies the intended diagnostic use. No when-not guidance or named alternatives (e.g., check_surbl for a single-signal lookup) are provided.

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/non-destructive, and the description adds genuinely new behavior: the four-level verdict vocabulary (pass, weak, fail, not set), the separation of essential versus optional records, and the rule that BIMI and MTA-STS return 'absent' rather than 'failed'. It does not mention timeout, DNS resolution failure handling, or rate limits, so the operational envelope is only partly 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?

Three sentences, each earning its place: what is checked, how results are graded, and when to reach for it. The core capability is stated in the first clause rather than buried.

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 return-value burden and does so reasonably by defining the verdict labels and the 'absent' convention, which is enough for an agent to interpret results. Missing only secondary detail such as whether records include their raw values or which record is considered the 'essential' set.

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 the schema already documents it at 100% coverage with an example ('acme.com'). The description adds no meaning about the domain parameter (e.g. whether an email address, subdomain, or IDN is accepted), so this sits at the baseline for a fully documented single 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?

Names a specific resource (the six email-authentication records for one domain) and a specific action (check and judge each). The phrase 'in one call' implicitly separates it from the per-record siblings check_spf, check_dkim, check_dmarc, check_bimi and check_mta_sts.

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 a concrete triggering scenario ('someone has been told to fix their email authentication and does not know which record that means'), which is more useful than a generic 'use when you need auth info'. It never explicitly says to prefer this over the individual check_* tools or when a single-record check is the better choice, so it stops short of full routing guidance.

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 and non-destructive, so the safety profile is covered elsewhere. The description adds no behavioral context: it doesn't say how tenancy is determined (DNS/TXT verification records, MX), how confident or stale the signal is, or what a 'clear' result actually implies.

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?

One sentence, front-loaded, with no filler and the two possible outcomes stated together. It is arguably slightly under-specified rather than over-long, but 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 one-parameter read-only check this is close to sufficient, but with no output schema the description should hint at the return shape (boolean? status string? reason?) and what evidence backs an 'attached' verdict. Those gaps leave the agent unsure how to interpret results.

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 and the schema documents it fully (100% coverage, with an example), so the schema carries the burden. The description adds no format constraints beyond the schema, which is the expected baseline here.

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 question ('is this domain already attached to a Google Workspace account, or clear for a fresh tenant') with an explicit verb-and-resource framing. No sibling tool covers Google tenancy, and the outcome ('attached' vs 'clear') is immediately actionable.

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 only implied: an agent can infer this is a pre-provisioning check, but the description never states when to call it versus adjacent checks like check_dns, lookup_mx, or check_deliverability, nor any preconditions (e.g., domain must be a registered root 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that the check spans two surfaces — a DNS TXT record and a remotely published policy file — which is meaningful context beyond annotations, but it doesn't say what happens when the record is missing or the policy fetch fails, nor how results are reported.

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?

One front-loaded sentence with the resource first and the inspected fields enumerated after a colon. Every clause carries information; there is no filler or restatement 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, annotation-rich, output-schema-less check tool, the description covers what is validated and against which aspects. Remaining gaps — behavior on missing records, whether a policy fetch is followed across redirects, and result shape — are modest for this complexity level.

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 single `domain` parameter is documented with an example in the schema. The description adds only the implicit framing that the domain is the subject of the _mta-sts record, not any new syntax or format detail. Baseline 3 applies when the schema carries the 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?

Names a specific verb (validate) and specific resources (_mta-sts DNS record and the published policy file), plus the exact aspects inspected: mode, MX patterns, max_age, TLS-RPT. This clearly separates it from check_dmarc/check_spf/check_bimi siblings. It stops short of naming a sibling for contrast, so a 4 rather than 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?

There is no when-to-use guidance, no prerequisites (e.g. domain must already publish MTA-STS), and no routing to alternatives such as check_email_authentication or check_bulk_sender_requirements for broader auth coverage. Usage is only inferable from the tool name and the object of validation.

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 safety is covered. The description still adds value by disclosing what comes back (NS records and the underlying DNS provider), which matters because 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 sentences, no filler. The core capability is front-loaded and the motivation follows immediately.

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 lookup with no output schema, the description covers what it returns and why you would call it. Minor gap: no note on failure behavior for domains with no resolvable NS or how bulk partial failures are reported.

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 single array parameter is documented, so the description only needs to add shape. It does: 'one domain or a whole list' tells the agent the array accepts a single value, which the schema alone doesn't make obvious.

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 (get) and resource (NS records plus DNS provider), and the title adds bulk scope. It is distinguishable from lookup_mx/lookup_txt/check_cname by the NS-record and provider angle, though it never names those siblings.

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 phrase 'before trying to fix its records' implies a diagnostic use case, but there is no explicit when-to-use or when-not-to-use and no mention of any of the many DNS-check siblings (check_dns, check_cname, lookup_mx) that an agent could confuse it with.

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 readOnly/idempotent annotations, it discloses genuinely useful behavior: missing PTR is reported separately from a PTR that fails to confirm, the `fcrdns` field carries the verdict, and remediation belongs to the address block's operator. That is result-shape and failure-mode information the agent cannot get 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 core operation is front-loaded in sentence one, but the body repeats the same idea twice ('a PTR alone proves nothing' / 'Only the round trip is evidence') and spends a clause on Google/Yahoo bulk-sender framing that is motivational rather than operational.

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 still conveys the return shape well: a PTR value plus a confirmed/not-confirmed verdict, with missing-PTR as a distinct state. Exact field names beyond `fcrdns` and the absence of a hostname-based variant explanation are the only gaps.

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 coverage, and the schema already says it must be an address and not a hostname. The description restates the IPv4/IPv6 acceptance and adds no syntax, format, or edge-case detail (e.g. CIDR or private ranges) 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 first sentence names the exact resource (PTR record for an IPv4/IPv6 address) and the paired forward lookup, which distinguishes it from hostname-oriented siblings like check_dns and check_cname. It does not explicitly name an alternative sibling, but the IP-only scope is unambiguous.

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

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

Usage context is clear: this is the check for FCrDNS compliance against bulk sender requirements and Gmail's IPv6 rejection policy, so an agent knows when it matters. There is no explicit 'use X instead of this' routing, which keeps it 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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuine value beyond that by noting the recursive lookup count and the 10-lookup failure threshold — the specific insight that makes SPF checks non-trivial. It stops short of describing the pass/fail output shape.

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?

One sentence, front-loaded with the primary action, followed by the supplementary lookup-count detail. No redundancy or filler.

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 must hint at return value, and it does so by noting validation plus lookup-count reporting. An agent knows what it will get. Minor gap: it doesn't state whether results include raw record text or per-mechanism breakdown.

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?

Single parameter with 100% schema coverage, and the schema already supplies the 'acme.com' example. The description adds no syntax guidance beyond what the schema provides, which is the correct baseline-3 outcome when the schema does 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?

States a specific verb and resource: 'Look up a domain's SPF record and validate it.' It adds a concrete behavioral detail (recursive DNS lookup count) that distinguishes it from generic DNS siblings like check_dns, lookup_txt, and check_dkim.

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 context is implied by 'domain's SPF record' — an agent can infer this is the SPF-specific checker among the check_dmarc/check_dkim/check_bimi family. However, it never explicitly says when to use this versus lookup_txt or check_dns, nor lists prerequisites such as the domain needing to be resolvable.

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 the safety profile is covered. The description adds genuine behavioral context beyond them: the outbound-SMTP block on port 25 and the fact that the result includes chain trust and hostname coverage. It does not cover extraction failure modes or rate limits, which keeps it at a 4.

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, both front-loaded with the useful part: the return contract first, then usage plus the one hard limitation. Nothing repeats the schema or the 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?

For a two-parameter read-only probe with no output schema, the description enumerates the returned fields and states the one environmental constraint that would otherwise cause a mis-call. An agent has everything needed to decide and invoke.

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%, with both `domain` and `port` documented in the schema, including the port default and the port-25 rejection. The description adds no syntax or format detail beyond that, so baseline 3 is correct.

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 ('Read a host's TLS certificate') and then enumerates exactly what is returned: issuer, validity, SANs, key type/size, signature algorithm, chain, protocol, trust and hostname coverage. This is far more specific than the sibling checks and lets an agent tell it apart from check_mta_sts, check_dns or check_tracking_domain 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?

Gives concrete when-to-use guidance ('on an MTA-STS policy host or a click-tracking domain') with a real consequence ('expired certificate stops mail or turns every click into a browser warning'), and an explicit when-not ('Port 25 is not reachable... the certificate an MX host presents cannot be read this way'). It does not name an alternative sibling tool the way a 5 would, but the usage 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description adds real value beyond them: it discloses that removals come with reasons and that the clean CSV is only returned when it is 500 rows or fewer. That output-size threshold is exactly the kind of behavioral constraint annotations cannot express. It stops short of describing the failure case when the list exceeds 500 rows or what the 'why' values look like.

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 sentence that front-loads the action, then the mechanism, then the return behavior. No filler and nothing implied by the schema is restated.

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 annotations covering safety and no output schema, the description adequately explains what is returned and the 500-row guardrail. Two gaps remain for a 5: how the two suppression input parameters interact, and what happens when the output exceeds the row limit.

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 five parameters are already documented, and this is the baseline case. The description reinforces the semantics of matchDomains and maxPerCompany ('whole suppressed domains', 'per-company cap') but adds no syntax or format detail beyond the schema, and it does not clarify the mutual exclusivity of the suppression vs suppressionCsv input paths.

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 campaign list against a do-not-contact list) plus the matching mechanics (exact email matches, optional domain matching, per-company cap). An agent can tell this is a filtering/screening operation rather than a mutation. It does not explicitly differentiate from the adjacent clean_csv or verify_email siblings, which keeps it from a 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?

The phrase 'before sending' gives a clear temporal/process context for when to invoke the tool, which is actionable. However, it never names alternatives or exclusions (e.g., when to use clean_csv or verify_email instead, or whether this replaces or complements them).

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, non-destructive and open-world, so the safety profile is covered. The description adds real domain context about what SURBL evaluates (body-embedded domains) and restates the 100-domain batch cap, though it says nothing about the shape of the result (per-domain verdicts, which list was hit).

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 tight sentences: the action and scope lead, the explanatory rationale follows, and the limit closes. No filler and nothing that doesn't help an agent decide or call.

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 batch lookup with rich annotations, the definition covers what to send and why it matters. The remaining gap is the absent output schema combined with no description of what a result looks like, which slightly weakens an otherwise complete definition.

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 ('Domains to check. Max 100.'), so the schema already does the work and the baseline is 3. The description repeats the 100-domain cap without adding format guidance (bare domains vs. URLs, whether subdomains count).

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), a specific resource (domains against the SURBL URI blacklist) and the batch scope. That clearly separates it from siblings like check_blacklist, check_domain_reputation and check_tracking_domain, which are domain/IP reputation tools rather than a URI-body blacklist.

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 supplies the decision context an agent needs: URI blacklists cover domains inside a message body, and a single listed tracking/landing domain sinks the whole email regardless of sender reputation. That is a clear when-to-use signal, but it names no alternatives or exclusions (e.g., when to prefer check_tracking_domain or check_blacklist).

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, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context by disclosing that the tool performs external checks (resolution, certificate, SURBL lookup, sharing detection) and explains why the tracking-domain listing matters to content filters. It does not mention latency, rate limits, or failure behavior, but it goes 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 two sentences and front-loaded with the concrete checks, which is efficient. The second sentence, about content filters hashing the tracking domain, is useful rationale but is not strictly necessary for correct invocation, keeping this just below a perfect score.

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 composite multi-check tool with no output schema, the description does well to enumerate the checks but does not describe the shape of the result — whether each check is a boolean, a multi-field report, or a status summary. An agent knows what will be examined but not what it will get back, which is a notable gap given the absent 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 both parameters, including the optional sendingDomain, are already fully documented in the schema. The description's phrase 'belongs under the sending domain' reinforces the purpose of sendingDomain but does not add syntax, format, or behavior beyond what the schema already provides, 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?

The description uses a specific verb and resource — checking a campaign's click-tracking domain — and enumerates exactly what is checked: resolution, certificate, SURBL list, listed address, sending-domain relationship, and shared tracking host. This composite scope clearly distinguishes it from single-purpose siblings like check_surbl, check_ssl, and check_dns without naming 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?

Usage is implied by the phrase 'a campaign's tracked links,' which tells an agent the context in which to reach for this tool. However, there is no explicit when-to-use/when-not guidance and no routing advice versus the many overlapping sibling checks (check_ssl, check_surbl, check_dns, check_blacklist).

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, so the safety bar is low, but the description adds real behavioral detail beyond them: the 500-row threshold at which the output changes shape, and the fallback of sending the user to a page for the full result. It does not state the output format of the cleaned CSV or any size/performance limits, which keeps it short of 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 tight sentences: capability and removals first, then the return/size behavior, then the scope limit. No filler, and the most decision-relevant facts 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?

With no output schema, the description takes on the burden of explaining return behavior and does so precisely, including the conditional response shape. Parameters are fully covered by the schema, so nothing an agent needs to invoke this 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 the csv body and the removeRole/removeDisposable defaults are already documented. The description corroborates those two categories but adds no syntax, format, or edge-case meaning beyond the schema, which is the expected baseline when the schema does the work.

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?

Specific verb plus resource ('Clean a lead CSV') followed by an enumeration of exactly what is removed (malformed, duplicate, role-based, disposable) and with per-reason counts. It also draws an explicit boundary against the sibling verify_email with 'Does not verify mailboxes exist', so the agent can separate it from verification, conversion, and combination 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 closing exclusion ('Does not verify mailboxes exist') effectively routes the agent to verification siblings when mailbox existence matters, and the row-count cutoff tells it when a second step (page download) is needed. There is no positive statement of when to prefer this over combine_csvs/convert_csv, so the guidance is clear but not exhaustive.

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 read-only, non-destructive, idempotent, and closed-world behavior. The description adds valuable context: it returns a link and names the tools for checking drafts, and it clarifies that it does not generate email copy itself. This is useful beyond annotations, though no auth or rate-limit details are needed.

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, front-loaded with the core action. No wasted words—each sentence adds distinct value by stating the external resource and the supported checking tools.

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 has no parameters, rich annotations, and no output schema, the description is complete. It explains what the tool does, its limitations, and what the result contains (the link and relevant checking tools), giving an agent everything needed to decide to call 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?

The tool has zero parameters. The schema is empty with 100% coverage, so there is nothing to document. A baseline of 4 is appropriate for a parameterless tool.

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 ('Directs') and resource ('Cold Email AI'), and explicitly clarifies that it does not generate copy. It distinguishes itself from the named sibling tools that check drafts (analyze_cold_email, preview_inbox, expand_spintax), so an agent can immediately understand its role.

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 implies when to use the tool by contrasting it with the draft-checking tools, but does not give a direct 'use this when...' instruction. The context is clear enough for an agent to infer that this is for writing assistance, while the listed siblings are for checking drafts.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the burden is light, and the description still adds a genuinely non-obvious trait: the call returns the CSV only when it is 500 rows or fewer. It stops short of saying what happens above that threshold, which is the one behavioral detail an agent would still need.

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 tightly packed sentences that front-load the core operation and then the optional behaviors. The closing 'POST JSON: files is an array' restates schema content and is the one clause that doesn't earn 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?

With no output schema and only three parameters, the description covers enough to invoke correctly, including the row-count return condition. The gap is that the over-500-rows path is undefined — the agent doesn't know whether the result is truncated, empty, or an error.

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, and the description earns above it by explaining the semantics of the boolean flags — dedupe means duplicate emails, addSource adds a column naming the originating file — and by clarifying that column matching is semantic (Email/email_address/E-mail). The trailing 'POST JSON: files is an array' adds little 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?

States a specific verb (merge) and resource (lead CSVs), plus the distinguishing behaviors: fuzzy column-name matching, optional email dedupe, and an optional source-file column. What's missing is differentiation from the adjacent sibling tools clean_csv and convert_csv, which an agent could easily confuse with this 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?

Usage is implied by the described behavior ('several' files, optional dedupe), but there is no explicit when-to-use or when-not-to-use guidance and no reference to clean_csv/convert_csv, which handle overlapping CSV-manipulation territory. The agent must infer the routing decision itself.

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 readOnly and idempotent annotations, the description discloses the exact transformation: every row and column is kept, only the header changes, and unmapped columns become snake_case custom variables. It also explains the return behavior, including that the converted CSV is returned only when the input is 500 rows or fewer.

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 core transformation in the first sentence and behavioral details following efficiently. Every sentence adds useful information without repetition.

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 return-value explanation itself and does so clearly: it returns the mapping plus the converted CSV when the threshold is met. Combined with the annotations and fully described input schema, this is complete enough for an agent to select and invoke 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?

Schema description coverage is 100%, so the two parameters are already well documented in the schema. The description reinforces the platform options and the CSV shape but does not add syntax or format details beyond the structured fields.

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: renaming a lead CSV's columns to sequencer import fields. It names concrete target platforms and clarifies that only headers change, which distinguishes it from siblings like clean_csv or combine_csvs.

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 usage context is clear: prepare a lead CSV for import into Instantly, Smartlead, EmailBison, or a generic snake_case format. It does not explicitly name when to choose this over clean_csv or combine_csvs, so it lacks full alternative routing guidance.

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 establish read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful behavioral detail by listing exactly what is returned: total variations, referenced variables, unresolved variables, and rendered samples.

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 and compact: it states the operation, return contents, and intended use in two efficient sentences. Every sentence contributes useful 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?

Given the tool's read-only preview nature, complete annotations, and lack of an output schema, the description is complete enough to call correctly. It explains the rendered output and usage context without unnecessary repetition.

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 template, vars, and samples, including the samples range and default. The description reinforces the template example and variable concept but does not add parameter semantics 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 gives a specific verb and resource: expand a spintax template and render its Liquid merge tags. It also enumerates the outputs, making the tool's purpose unambiguous and distinct from the surrounding analysis and verification 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 provides a clear usage context: "Use it to check a sequence before it sends." It does not explicitly name when not to use it or identify a sibling alternative, but no sibling appears to overlap directly.

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 establish readOnly, closed-world, idempotent, and non-destructive behavior. The description adds important behavioral context beyond that: results include lead counts and verified email counts, each list has a page, lists are emailed from that page, and this tool cannot request or download a list.

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 core purpose, then immediately states scope limits and return behavior in three efficient sentences. There is no redundant or wasted text.

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?

Although there is no output schema, the description explains the return shape well enough: best-matching lists with lead counts, verified email counts, and each list's page. It also covers the critical limitation that the tool cannot request or download lists.

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 all three parameters are already well documented in the input schema. The description reinforces the industry/role/country filtering intent, but does not add syntax, defaults, or edge-case meaning beyond what the schema provides.

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 gives a specific verb and resource: it searches WarmInboxes' own catalogue of about 1,000 free B2B lead lists by industry, role, and country. It also explicitly distinguishes this from web search or any other database, so the agent can tell what the tool is and is not.

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 clearly states when the tool applies and gives strong exclusions: it does not search the web or other databases, and it cannot request or download a list. It does not name a sibling alternative, so it falls just short of fully explicit alternative routing.

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, so the safety profile is covered. The description adds genuinely new behavior: it searches titles AND full text, and each match returns the passage that best answers the query rather than a bare link — that result-shape detail is not in the annotations or 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?

Front-loaded with the action and corpus, then the ranking/return behavior, then the sibling routing rule. The long enumeration of resource kinds is informative but is the bulkiest part; it could have leaned on the type enum instead of restating all eleven values.

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 must convey what comes back, and it does: matches plus the best-answering passage. The content coverage (own measurements vs. guides) is useful scope information. It stops short of describing match fields or ordering, a minor gap for a simple search tool.

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 nevertheless adds value by mapping its enumerated content kinds onto the type enum and by framing the query as a question or topic whose best-matching passage is returned, which clarifies result semantics beyond the schema's example strings.

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 (search) and a specific corpus (everything WarmInboxes publishes), then enumerates the resource kinds so the agent knows exactly what is indexed. It also explicitly contrasts with the sibling read_resource, which returns a whole page, so the two are distinguishable without opening either 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?

The closing sentence gives a clear routing rule: search with find_resources, fetch a full page with read_resource. That covers the main alternative, but nearby siblings such as cold_email_writing_resources and find_tools are not addressed, so an agent could still hesitate between those and this tool.

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 read-only, non-destructive, idempotent, closed-world behavior. The description adds useful behavioral context beyond that: it returns either an MCP tool to call or a page to send someone to, and with no task it lists every tool.

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, covers the return behavior and the no-task case, and uses concrete examples without wasting sentences.

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 discovery/routing tool with no output schema, the description gives enough information to invoke it correctly: what it returns, how it routes between MCP and browser usage, and what happens when no task is supplied.

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 defines task, limit, and callableOnly. The description still adds meaning by explaining the empty-task behavior, which is not stated in the schema and is important for 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 states a specific verb and resource: find the WarmInboxes free tool for a described task, then say how to use it. The examples (checking headers, cleaning CSV, spam prediction) and the MCP-tool-vs-browser-page distinction make its purpose distinct from the many specific 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?

It clearly explains the main use case: give it a task and it routes to either an MCP tool or a browser page. It also specifies the no-argument behavior ('Call with no task to list every tool'), but it does not explicitly say when to prefer this over calling a known sibling directly.

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 and non-destructive, and the description adds real context beyond them: the 10-lookup limit estimate for SPF, that output is host/type/value pairs to publish, and that it generates rather than publishes. The phrase 'It writes records' is slightly loose against readOnlyHint, but the surrounding 'Returns host, type and value to publish' makes clear it produces text and does not mutate DNS, so it is not a true contradiction.

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 tight sentences with zero filler, front-loaded with the primary generator action and closing with the routing rule. Every clause carries 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 nine optional parameters and no output schema, the description usefully discloses the return shape (host, type, value) and the lookup-estimate feature. It could say a bit more about how partial inputs are handled (e.g., calling with only dmarcPolicy), but nothing essential is missing for 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?

Schema coverage is 100% with enums and defaults documented, so the schema carries parameter meaning. The description adds only the lookup-limit framing around spfProviders; it does not explain the interplay of dmarcPolicy, dmarcPct, or subdomain policy beyond what the schema already says. 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?

States specific verbs and resources: writing an SPF record from sender providers, a DMARC record from a policy, and DKIM publication location. Explicitly contrasts itself with the check_spf/check_dmarc/check_dkim siblings, so an agent can distinguish generator from checker without opening schemas.

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-not rule: 'to check what is published, use check_spf, check_dmarc and check_dkim,' naming the alternatives directly. This is the key routing decision for this tool and it is spelled out, not implied.

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, non-destructive and closed-world, so the safety profile is covered. The description adds what annotations cannot: that output is dual-format (plain text plus HTML) and includes a per-requirement compliance checklist, which is real value given 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 sentences, front-loaded with the verb and deliverable, and the second sentence earns its place by naming the most common failure mode. No filler or hedging.

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 five all-optional parameters, no output schema, and simple flat fields, the agent has enough to call correctly: it knows the artifact, the two output formats, and the checklist return. Minor gap is guidance on the reply-vs-link-vs-both styles and when each applies, which is left entirely to the 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%, including defaults for tone and style and the note that address is 'Required by CAN-SPAM'. The description's remark that 'a footer with no postal address is the usual failure' reinforces the address parameter but adds no syntax, format, or interaction detail (e.g. that unsubUrl is needed for link/both styles).

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 artifact: 'Build a CAN-SPAM and GDPR compliant opt-out footer in plain text and HTML', and adds that a compliance checklist is included. No sibling tool produces footers (the others are analyze_/check_/plan_ utilities), so the resource is unambiguous.

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 artifact name (you call this when you need an unsubscribe footer), and the closing line steers the agent toward supplying an address. But there is no explicit when-to-use/when-not framing, no mention of prerequisites, and no named alternative for related compliance checks such as check_bulk_sender_requirements.

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, non-destructive and closed-world, so safety behavior is fully covered. The description adds value by disclosing what the returned data actually contains (per-inbox send pace, delivery time, all billing cycles), going beyond what the annotations say. It stops short of describing format or whether pricing is static, which keeps it at a 4.

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: the first front-loads what the data is and what dimensions it covers, the second routes to the alternative. Nothing is wasted, and the enumeration of providers and fields earns its space by telling the agent what it will get.

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 parameters and no output schema, the description carries the burden of explaining the return content, and it does so by listing the axes of the price list. Minor gaps remain (currency, unit of pricing, whether tiers are returned as a table), but nothing prevents a correct call.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument, whole-catalog read.

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 resource (the WarmInboxes price list as data) and enumerates its scope: prewarmed/fresh inboxes across Google Workspace, Microsoft 365 and Azure, billing cycles, safe daily send pace, and delivery time. It also explicitly distinguishes itself from plan_infrastructure, so an agent can tell the two apart without inspecting either 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 an explicit routing rule — use plan_infrastructure when you need a costed fleet for a volume — which is exactly the when-not guidance that matters for a catalog lookup. It does not mention the other closely related sibling, quote_inboxes, so the guidance is clear but not exhaustive.

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, non-destructive, and open-world, so the safety profile is covered. The description adds real behavioral value beyond that: it returns null MX per RFC 7505 rather than flagging it broken, and it deliberately refuses to guess the provider behind a gateway because that is unobservable — useful disclosure about output fidelity.

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 sentences, front-loaded with what is returned, then the bulk-mode difference, then the two edge-case behaviors. No filler and every sentence carries information an agent needs.

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 only two optional parameters and no output schema, the description carries the return-value burden well: priorities, resolved IPs, provider, gateway, and the bulk breakdown are all named. Minor gaps remain on failure behavior (nonexistent domain, no MX) and the null-MX format itself.

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 would be 3, but the description adds meaning the schema does not: the `domains` array mode additionally returns a provider breakdown, and the 100-domain cap is stated in prose as well as schema. It does not clarify precedence when both parameters are supplied.

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) plus the derived output (provider identification, security gateway detection). This is clearly distinguishable from siblings like check_dns, lookup_txt, or check_google_domain, which cover different record types or single-provider checks.

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 the choice between the two parameters: use `domains` for up to 100 at once, which also returns a provider breakdown. It gives clear context for the tool's purpose (mail provider discovery) but never names an alternative sibling or states 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.

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 goes well beyond that by disclosing three diagnostic conditions the raw records cannot show: duplicate SPF causing permerror, DMARC/DKIM at the apex being unread, and TXT strings over 255 bytes. That is exactly the kind of behavioral context annotations cannot carry.

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 is front-loaded in the first clause, and the failure-mode list and the usage warning follow in a logical order. It is a long description, but nearly every clause carries distinct information; the embedded parenthetical enumerations of record types and underscore names make sentences dense rather than 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?

With no output schema, the description does the work of telling the agent what comes back: each record identified by type or service ownership token, plus four underscore names, plus three flagged mistakes. What it does not state is the response shape or how the identification and warnings are labeled in the output, which is the remaining gap for a no-output-schema tool.

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 coverage is 100%, and the schema description already explains the underscore-prefixed name behavior, so the schema does the work. The description reinforces the underscore names in prose but adds no new syntax or format detail beyond the schema. 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 and resource ('Every TXT record on a domain') and immediately scopes it as an aggregate: all record types identified plus the four underscore names a receiver reads. That clearly distinguishes it from the narrow siblings check_spf, check_dkim, check_dmarc, check_mta_sts and check_bimi without needing to open any 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?

Gives an explicit usage rule with a reason: 'Use this before concluding a record is missing, because the usual cause of a missing DMARC record is a DMARC record at the wrong name.' It does not name the individual checker as the alternative to use for a single-record confirmation, so the routing guidance is strong but not exhaustive.

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/non-destructive/openWorld, and the description stays consistent, explicitly saying it neither provisions nor orders. It adds genuine behavioral context the annotations can't: the 100-domain cap and MX lookups, the fallback that gateways/self-hosted/no-MX recipients are folded into the Google pool with their share reported, and the no-reserve-capacity assumption. Lacks any note on runtime or lookup failure 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?

Front-loaded with purpose and mechanism, and dense with useful detail. The closing sentences on how orders are placed are relevant context but not needed to invoke the tool, so a small amount could be trimmed.

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, and the description fully compensates by enumerating what comes back: inbox count, domain count, per-inbox pace and monthly cost per pool, plus totals, plus the 'other' share. An agent can call it correctly and interpret the return without further 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 coverage is 100%, so every parameter including enums already documents itself; baseline 3 applies. The description only reinforces the `domains` cap and the routing of non-Google/non-Microsoft recipients, which clarifies result interpretation more than 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?

Opens with a specific verb and resource ('Estimates a sending fleet for a recipient list') and immediately explains the mechanism: MX lookups over up to 100 domains feeding Google/Microsoft/other mix and pool sizing. It also draws a hard line against provisioning or ordering, which separates it from ordering-adjacent siblings.

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 one real usage rule — 'For a longer list, send a sample: the estimate follows the provider split, not the list length' — and states it assumes no reserve capacity. But it never says when to choose this over quote_inboxes, plan_rotation, plan_infrastructure, or get_pricing, so the agent must infer the 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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, and the description still adds real context: it discloses assumptions (provider default pace unless emailsPerMailbox is set, 22 sending days a month) and limitations (no placement or reply guarantees, revenue follows only from supplied rates, nothing is ordered).

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 purpose is front-loaded in the first clause, followed by inputs, the optional revenue extension, and the assumption/limitation caveats. It is dense but each sentence carries information; minor redundancy in restating the input list.

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 an 11-parameter read-only estimator with no output schema, the description covers the input model, the optional revenue path, and the modeling assumptions. It could say more about the shape of the returned figures (inbox/domain counts, cost breakdown), but the key planning caveats are present.

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 each parameter already carries a default-aware description, so the schema does the heavy lifting. The description mostly re-enumerates inputs (esp, prewarmed, billing cycle, per-inbox and per-domain rates) rather than adding new meaning, which fits the baseline 3 for high 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 states a specific verb and resource: it estimates how many inboxes and domains a given daily volume needs, plus the monthly cost. It implicitly separates itself from ordering tools by stating it 'orders nothing', though it never names a sibling such as quote_inboxes or plan_from_list directly.

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 only implied through the input list and the note that supplying dealValue unlocks the revenue/ROI projection. There is no explicit when-to-use framing and no named alternative for related tasks (quote_inboxes, plan_from_list, plan_rotation), leaving the agent to infer the 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes further by enumerating exactly what is computed and returned: batch sizes, per-inbox daily load against a 15-a-day pace, required inbox count at that pace, and an eight-week calendar. It also explicitly disclaims any side effects on inboxes or sequencers, which is the key behavioral risk an agent might assume for a 'plan' tool with write-adjacent siblings.

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, front-loaded with what it produces, followed immediately by the safety disclaimer. No filler, and the disclaimer is placed where an agent skimming will still see it.

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 must explain return values, and it does so concretely (batch sizes, load comparison, needed inbox count, eight-week calendar). Combined with the disclosed 15-a-day assumption and the no-side-effects disclaimer, an agent has everything needed to call this correctly and interpret the 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, but the description adds meaning the schema does not: it explains the two-batch model these parameters feed and surfaces the built-in 15-a-day pace assumption used in the comparison output. The cadenceWeek enum values are only echoed from the schema, not elaborated.

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 ('Suggests a two-batch inbox rotation schedule') and pins down the model: fleet split in half, one batch sending while the other rests, swaps at fixed intervals. This clearly separates it from sizing/planning siblings like plan_infrastructure or burned_inbox_guidance.

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 clear context for use (planning a rotation for a fleet given daily volume) and an explicit non-goal: 'it does not pause, resume or change any inbox or sequencer.' It stops short of naming an alternative sibling to use instead, so it is clear but not fully routed.

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 read-only, idempotent, non-destructive behavior, but the description adds meaningful calculation traits: sequential waterfall processing, unknowns cascading, every order compared, and default 'typical figures for three verifiers' when no custom rates are supplied. It stops short of describing the exact response shape or the assumptions behind those typical figures, so it is 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?

The description is two sentences, front-loads the purpose, and each clause adds concrete information: process, comparison, optimization objective, default, and override. No filler.

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 pricing tool with a fully described schema and safety annotations, the description supplies enough to call the tool and understand its optimization objective. Because there is no output schema, it could more explicitly describe the returned comparison format beyond 'cheapest cost per usable email first.'

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 listSize and the verifier fields are already documented in the schema. The description adds the important default behavior—three typical verifiers are used unless the caller passes custom prices and resolve rates—though the parenthetical 'POST JSON for verifiers' is a little unclear and listSize is not discussed.

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 verb and resource: 'Price an email verification waterfall.' It then clarifies the mechanics (sequential verifiers, unknowns passed down, every order compared) and the optimization goal (cheapest cost per usable email), so an agent can tell it is a pricing/planning tool rather than a direct verification tool like verify_email.

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 opening 'Price...' scenario, but the description never states when to choose this over verify_email or quote_inboxes, nor any when-not conditions. The only conditional guidance concerns supplying custom verifier data, which is parameter usage rather than tool-selection guidance.

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 establish that this is a read-only, idempotent, non-destructive, non-open-world operation. The description adds useful behavioral detail by explaining that it previews truncation across three specific clients and emits warnings such as no sender name, all caps, or empty preview.

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 two sentences, front-loads what the tool does, and follows with a direct usage recommendation. There is no unnecessary repetition or filler.

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 simple read-only preview tool with complete schema coverage and rich safety annotations, the description supplies the missing conceptual context: the clients previewed, the kind of truncation shown, and the warning categories. An agent has enough information to select and 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 description coverage is 100%, so all three parameters are already documented in the input schema. The description reinforces the roles of sender name, subject line, and preview text but does not add syntax or optionality details beyond what the schema provides, 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 and resource: it shows how a cold email's sender name, subject line, and preview text are truncated in Gmail desktop, Gmail mobile, and Outlook. It also names the warning conditions it reports. This is clearly distinguishable from all sibling analysis and deliverability 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 gives a clear usage context: use it to check whether a subject line fits before sending. It does not list when not to use it or name alternative sibling tools, but the intended timing is 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 declare readOnly/idempotent/non-destructive, but the description adds genuinely useful behavior: it is a quote that 'orders nothing', it discloses the Azure tenant-rounding rule with a note, and it points to where the exact named preview lives. It stops short of describing rate limits or response shape in detail, which keeps it below 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?

The core purpose is front-loaded in the first clause and the usage rule follows immediately; the third sentence carries real information (quote-only, Azure rounding, preview location). It is somewhat dense and longer than strictly necessary, but no sentence is filler.

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?

No output schema exists, yet the description enumerates the return content (tenants/domains, capacity, cost, delivery time) and sets expectations that names are not resolved in this tool. For a read-only pricing tool with four well-documented parameters, an agent has everything needed 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?

Schema coverage is 100% so the baseline is 3, but the description adds meaning beyond the schema: the Azure 'sold by the tenant' semantics explain why a non-filling count is quoted for whole tenants, which the enum description alone does not convey. Billing is only implied via 'monthly cost', so it does not fully round out every 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?

States a specific verb and resource ('Prices a given number of inboxes') and immediately enumerates what the quote contains: domains/Azure tenants, daily sending capacity, monthly cost and delivery time. It also distinguishes itself from the sibling plan_infrastructure by input shape (count vs send volume).

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 condition ('when the person already knows the count') with a concrete example, and names the alternative tool and the condition that selects it ('for a send volume use plan_infrastructure'). It further routes the user elsewhere for exact previews with real names.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: long pages are split at headings, the first call reveals how many parts exist, and datasets additionally return JSON data. That pagination and dual-format behavior is exactly the kind of trait annotations cannot express; only the slightly opaque reference to 'nextPart' (the schema field is named 'part') keeps it from 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?

Four sentences with no filler, and the core purpose is front-loaded before the pagination mechanics. The mention of 'nextPart' without explaining that it is a response field is a small clarity cost, but nothing is redundant.

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 return burden and does: markdown body, part structure with a count, and JSON data for datasets. Combined with a fully documented two-parameter schema and complete annotations, an agent has everything needed to call this correctly and interpret the 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, but the description adds meaning beyond the schema: it explains why 'part' exists (long pages are split at headings) and how the agent learns which part to ask for, which the bare 'Which part of a long page, from 1' does not convey. The url parameter is also contextualized as coming from find_resources rather than being any arbitrary link.

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 (read) and enumerates the resource types it covers (guides, studies, playbooks, datasets, recipes, comparisons, changelogs) plus the output format (markdown). It also distinguishes itself from the sibling it pairs with by telling the agent to use the url find_resources returned, so no schema-opening is needed to tell them apart.

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 clear entry conditions: come here after find_resources, pass the url it handed you. It also explains the long-page workflow (first call reports the part count, then request the needed part), which is real usage guidance. It does not state any case where a different sibling should be preferred instead, which keeps it 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds one useful behavioral fact — segmentation is derived from MX records — but says nothing about how domains with no MX or an unrecognized provider are handled, nor about scale limits for bulk submission.

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, front-loaded with the operation and its categorization, zero padding. The second sentence is motivational rather than operational but is short and justifies the tool's existence.

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 tool with full annotations and no output schema, this covers the essentials: what goes in, what buckets come out, and where the signal comes from. Edge-case behavior (unresolvable domains, unknown providers) is the main omission.

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% with a single required array parameter, so the schema carries the parameter documentation. The description reinforces the bulk-list nature ('a list of domains') but adds no format, size, or dedup guidance beyond that.

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 (split) plus the resource (list of domains) and names the resulting buckets (Google, Microsoft, security gateway) and the data source (MX records). It is distinguishable from siblings like lookup_mx, though it never names that sibling explicitly to sharpen the boundary.

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 second sentence supplies a rationale for using the tool (Google-to-Google / Microsoft-to-Microsoft matching improves inbox placement), which implies the when. There is no explicit 'use this instead of lookup_mx when...' guidance and no stated preconditions or exclusions.

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?

Goes well beyond the readOnlyHint/idempotentHint annotations by disclosing that no query is performed, that a paid key would be required, and that the response content states nothing was checked. It even pre-describes the shape of the result (lookup URL plus alternative checks), which is unusually candid for a non-functional tool.

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 filler, and the most decision-relevant fact (it does not query) is front-loaded in the first clause. 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?

No output schema exists, yet the description compensates by describing what the response contains (a statement that nothing was checked, Spamhaus's lookup, and the checks the server does run). Nothing an agent needs to call or interpret this tool 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?

Single optional 'domain' parameter with 100% schema description coverage, so the baseline is 4. The description mentions the domain being asked about but adds no syntax or validation detail beyond the schema, which is acceptable at this coverage level.

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 ('Explains how to check a domain on the Spamhaus Domain Block List') and immediately disambiguates the title's 'not queried' caveat by declaring it never issues a listing verdict. An agent can distinguish it from check_surbl and check_blacklist without opening any 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?

Explicitly frames the manual path (https://check.spamhaus.org) and names the alternatives this server actually runs: check_surbl and check_blacklist. The when-not condition — no paid key, nothing is checked — is stated rather than inferred.

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 read-only, idempotent, non-destructive and open-world traits, so the description's job is to add more. It does so meaningfully by disclosing a real limitation: no SMTP connections are opened and catch-all domains therefore return valid, which is a false-positive warning an agent could not get from structured fields. It stops short of disclosing bulk-size limits or credit consumption.

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, nothing wasted; the check list comes first and the important caveat about SMTP and catch-all domains is placed immediately after it.

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 could go further in indicating what a result looks like per address (verdict categories, reason codes) and any list-size limits. What it does cover — the verification signals and the catch-all caveat — is sufficient for an agent 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?

There is a single parameter with 100% schema description coverage, so the schema already documents it; the baseline of 3 applies. The description adds a little context about what is done to those addresses but no format or batching constraints for the array.

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 (email addresses) and enumerates the exact checks performed: syntax, MX, disposable providers, role prefixes. This makes it distinguishable from lookup_mx or check_deliverability, though no sibling is named explicitly.

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 rather than stated — an agent can infer this is the list-cleaning tool, but there is no explicit when-to-use, no when-not, and no pointer to alternatives such as plan_verification_waterfall or check_deliverability for cases needing SMTP-level validation.

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