email-deliverability

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds meaningful behavioral context: it returns both 'ours' and 'theirs' verdicts, whether they agree, and parsed envelope/headers, which goes beyond the annotations without contradicting them.

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

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

The description is a single, dense sentence that front-loads the primary purpose and key return fields, with no superfluous content. It earns its place efficiently.

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 compensates by explaining the return values (ours, theirs, agree, parsed envelope/headers). Given the moderate complexity of 4 parameters and the clear input requirements, the description 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 parameters are fully documented in the schema. The description adds a general reference to 'envelope/headers' but does not provide additional parameter-level meaning beyond what the schema already gives, so baseline 3 is appropriate.

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

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

The description clearly states the tool re-verifies SPF, DKIM, DMARC, and ARC from raw email, which is a specific verb and resource. It also distinguishes itself from siblings like get_dmarc_summary or scan_domain by focusing on raw header analysis and returning independent vs. sender auth results.

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 provides clear context on when to use it (spotting forged or mismatched auth results) and notes that no account is needed, implying a low-friction usage context. It does not explicitly list exclusions or alternatives, but the use case is well 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?

Beyond the destructiveHint annotation, the description adds critical behavioral context: it specifies that the tool creates/updates/deletes DNS records, that the server re-derives the diff and rejects stale ops, and that owner/admin write or full scope is required. This greatly exceeds the annotation's binary flag.

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 well-structured and concise: it front-loads the purpose, clearly flags destructiveness, explains the two-step protocol, server validation, auth requirements, and follow-up action. Every sentence contributes meaningful information without 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?

The description covers purpose, workflow, prerequisites, validation, auth, and post-action guidance. The only gap is the lack of explicit information about what the tool returns on success or failure, which would be useful given there is no 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?

The input schema has 100% coverage with detailed property descriptions, including the verbatim passing requirement and server-side validation. The description reinforces this but does not add new parameter-level 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 clearly states the tool applies a DNS fix plan to a tracked domain by publishing records at the connected registrar. It distinguishes itself from the sibling get_dns_fix_plan by explicitly framing the two-step relationship and using a specific verb (apply) with a clear resource.

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 provides explicit when-to-use guidance: first call get_dns_fix_plan, then pass its connectionId and ops verbatim. It also instructs to re-scan afterward and specifies the required API key scope, giving the agent a full operational sequence.

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 behavior. The description goes beyond these by explaining that queries use authoritative-side checks and avoid public-resolver false positives, adding valuable behavioral context about how results are obtained and what guarantees are provided.

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 no redundant words. It efficiently packs the verb, scope, outputs, and an important methodology note, every part earning its place.

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

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

For a one-parameter, read-only tool with rich annotations, the description is sufficiently complete. It covers what is checked, what is returned, and the underlying query approach. No critical aspects are missing, and the lack of an output schema is compensated by the explicit listing of return contents.

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 clear parameter description, but the tool description adds extra meaning by clarifying that both the apex domain and MX-host IPs are checked. This extends the understanding of what 'domain' entails beyond the schema's basic example.

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

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

The description clearly specifies the action ('Check') and resource ('DNS blocklists'), with the exact scope ('apex + MX-host IPs') and outputs ('listings, targets checked, issues'). It distinguishes itself from sibling tools like scan_domain or get_dns_fix_plan by focusing specifically on DNS blocklist 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?

The description implies usage for checking blocklist status, but it does not provide explicit when-to-use guidance or contrast with alternatives like scan_domain. The methodology note ('authoritative-side queries') hints at a use case but no direct comparison is made.

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

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

Annotations already indicate it is not read-only, and the description adds the need for an owner/admin key with write or full scope, which is useful auth context. It does not contradict the annotations.

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

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

The description is a single, efficient sentence with semicolons, front-loading the main action and avoiding any redundant words. Every clause adds meaningful 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 simple schema, lack of output schema, and presence of sibling tools, the description covers the core action, prerequisites, and relationship to start_inbox_placement_test. Minor gap: it does not mention whether storing a new provider overwrites an existing one, but this is not critical for the tool's basic use.

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 all parameters described. The description reiterates the provider enum and the projectId requirement, which are already in the schema, adding only minimal context like 'seed-list' to clarify the API key's purpose.

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

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

The description clearly states the tool stores the org's seed-list inbox-placement provider and API key, naming the two supported providers and the additional projectId for GlockApps. This specific verb+resource framing distinguishes it from sibling tools like connect_snds.

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

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

It explicitly says this enables start_inbox_placement_test, providing clear context for when to use the tool. It also specifies the required API key scope, but it does not mention alternatives or when not to use it.

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

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

The description adds context beyond the annotations: it requires a privileged API key, and data appears within ~24 hours. It also implies the operation persists a key. Annotations already indicate a non-readonly, non-destructive mutation, and the description complements this with operational details. No contradictions.

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 with a distinct purpose: what/why, how to get the key, and prerequisites/expected latency. No redundant 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?

The tool is simple (2 parameters, no output schema), and the description covers purpose, source, permissions, and latency. It could mention the behavior of repeated calls or verification, but the essentials are covered. Sibling tools for status checks exist, so a user can verify post-setup.

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

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

The input schema covers both parameters with descriptions, including the source of the key and an example label. The description repeats the key source but doesn't add new parameter details beyond the schema. Given 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description uses the verb 'Store' and specifies the resource (Microsoft SNDS automated-data-access key), and explains the purpose (enabling daily per-IP reputation sync). This clearly distinguishes it from sibling tools like get_snds_ip_stats and get_snds_status which read data.

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 states the context for use: to enable daily syncing of Outlook/Hotmail reputation. It also specifies the permission prerequisite (owner/admin API key with write or full scope). However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

Annotations already indicate readOnlyHint=false, confirming this is a mutation. The description adds valuable behavioral context: it returns a channel id and, for webhooks, a signing_secret for verification, and notes that webhooks are HMAC-signed. It does not contradict annotations and provides useful details beyond the 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?

The description is two sentences, front-loaded with the core purpose, and contains no filler. Every clause adds value: channel types, return values, signing secret, and authorization requirements. It is efficiently structured and easy to parse.

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 moderate complexity and fully documented schema, the description covers the essential aspects: purpose, supported channel types, return values, and security/authorization requirements. It does not need to explain the schema parameters in prose, and the absence of an output schema is compensated by the explicit mention of the returned channel id and signing_secret.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minor context by listing the channel types and indicating that the target matches the kind, but it does not substantially expand on the schema definitions. The schema already fully documents each parameter, so the description's contribution is marginal.

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

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

The description clearly states the tool creates a notification channel for InboxGuard alerts, enumerating the supported channel types (webhook, Slack, Teams, PagerDuty, SMS, email) and specifying the return value. The verb 'Create' plus the resource 'notification channel' makes the purpose unmistakable and distinguishes it from sibling tools like scan_domain or list_alerts.

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

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

The description explicitly states the required API key scope (owner/admin with write or full scope), which is essential for determining when the tool can be invoked. While it doesn't name alternatives, no sibling tool creates notification channels, so the guidance is clear in context and provides a concrete prerequisite.

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

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

The description goes well beyond the annotations (which are all false) by disclosing that the link is read-only, accessible to anyone without an account, and returns a token and public URL. It also states the authentication and plan requirements, providing rich behavioral context.

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

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

The description is two sentences: the first states the core purpose and key characteristics, the second covers return value and requirements. Every sentence adds value, and it is front-loaded with the most important 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 tool with one parameter and no output schema, the description covers purpose, return format, access scope, authentication, and plan requirement. It is fully self-contained and leaves no obvious gaps for an agent 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?

The input schema already fully documents the single 'domain' parameter with a clear description. The tool description does not add additional parameter information beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the action: 'Create a read-only public share link for a tracked domain's latest report'. It specifies the resource (tracked domain's latest report) and the outcome (public share link), distinguishing it from sibling tools that query, scan, or delete data.

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 provides clear context for when this tool is appropriate: it creates a public share link, and it explicitly states prerequisites: 'Requires an owner/admin API key with write or full scope, on a plan that includes public reports.' It doesn't name alternatives but none are needed given the unique purpose.

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 readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds valuable behavioral context: the meaning of 'unverified' and 'not_applicable' statuses, and the auth-gated pdfUrl requiring a bearer token. No contradiction with annotations.

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

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

The description is a single dense paragraph with many details. Each clause adds operational value (e.g., explaining scoreSubtitle, status meanings, PDF auth), but the long run-on sentence structure makes it slightly harder to parse. Still, nothing feels 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 tool's complexity and the absence of an output schema, the description thoroughly enumerates all return fields (score, grade, scoreSubtitle, check statuses, top issues, blocklist count, DMARC policy, pdfUrl) and explains ambiguous statuses. It is complete enough for an agent to invoke 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?

There is only one parameter ('domain') and the schema describes it completely with an example. The description does not add additional meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Return') and identifies the resource ('structured deliverability report') with clear scope ('for a tracked domain'). It distinguishes itself from sibling tools like get_deliverability_score (score only) and get_dmarc_summary (DMARC-specific) by enumerating the full report contents.

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 provides a clear use case: 'Use this to summarize a domain's posture or hand a client a report.' It does not explicitly mention when not to use it or name alternative tools, but the context is sufficiently clear for an AI agent to decide.

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, openWorld, idempotent, and non-destructive. The description adds the behavioral detail that this tool 'runs a fresh scan', indicating it performs an active operation rather than just reading cached data. This goes beyond the annotation safety profile without contradicting it.

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, concise sentence that front-loads the primary purpose and includes the key nuance of running a fresh scan. Every word adds value; there is 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 one simple parameter and no output schema, the description adequately conveys what the tool returns ('overall deliverability score and letter grade'). It could mention the output format or scan timing implications, but for this simplicity level it is largely 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?

The input schema description for 'domain' ('Domain to score, e.g. example.com') already provides clear semantics. The tool description does not add any additional parameter-level meaning, so a baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool returns an 'overall deliverability score and letter grade' for a domain, with the specific verb 'Return'. It also notes 'runs a fresh scan', distinguishing it from potentially cached report tools like 'get_deliverability_report'.

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 'runs a fresh scan' implies this tool is for getting up-to-date data, but it does not explicitly state when to use this over siblings like 'get_deliverability_report' or 'scan_domain'. Usage context is only implied, not fully articulated.

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 description need not repeat those. It adds value by specifying what the summary includes (volume, pass rate, top sources, rua inbox) and the prerequisite of an existing domain and DMARC ingest plan, which are not captured in structured fields.

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

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

Two sentences, front-loaded with the main purpose and followed by key details and prerequisites. Every phrase earns its place; no redundant or filler 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?

The tool has no output schema, so the description compensates by enumerating the summary components (report volume, pass rate, top sending sources, rua inbox). It also states prerequisites. Missing are error/edge-case behaviors (e.g., no reports available) and any response format details, but for a read-only summary with strong annotations, this is nearly 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% — both 'domain' and 'days' have descriptive text. The description adds no additional parameter-level detail beyond the schema. It mentions account/plan prerequisites but these are contextual, not parameter semantics. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Summarize') and clearly identifies the resource ('ingested DMARC aggregate (RUA) reports for a domain'). It lists concrete output elements (report volume, pass rate, top sending sources, rua inbox) and distinguishes this DMARC-specific tool from sibling tools like get_deliverability_report or get_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 description provides clear prerequisites: the domain must already be added to the account and the plan must include DMARC ingest. It implies the tool is for DMARC summary data specifically, but it does not explicitly name alternatives or state when not to use it. Still, the context is clear enough to guide selection.

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, and non-destructive behavior. The description adds valuable context beyond those: it states 'nothing changes' (reinforcing annotations), clarifies that results are computed from 'latest scan' and 'connected registrar,' and explains what the return payload contains (ops and manualReview with SPF, DKIM, BIMI specifics). It also discloses failure prerequisites (tracked domain, scan exists, registrar coverage), which helps the agent anticipate errors.

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 tightly structured: the opening verb and resource immediately convey the main purpose, followed by read-only status, return values, and prerequisites. Every sentence contributes meaningful information without repetition or fluff. At three sentences, it is appropriately sized for the tool's complexity.

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

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

With no output schema, the description takes on the responsibility of explaining return values, and it does so clearly ('ops' to pass to apply_dns_fix, plus manualReview items). It also covers input context (latest scan, connected registrar) and prerequisites. While it doesn't mention edge cases like when no changes are needed, the level of detail is strong for a single-parameter read-only tool with rich annotations.

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 parameter 'domain' is fully described in the input schema. The tool description adds only that the domain must be 'tracked' and that a scan and registrar connection are required—these are tool-level prerequisites, not new parameter meaning. Since the schema already handles the parameter, the baseline of 3 applies.

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

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

The description uses a specific verb ('Compute') and clearly identifies the resource ('exact DNS-record changes needed to fix a tracked domain's deliverability'). It distinguishes itself from siblings by explicitly linking to apply_dns_fix ('pass verbatim to apply_dns_fix') and noting it returns manualReview items, making its preview role unmistakable.

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 provides clear context for when to use the tool (previewing changes before applying) and names the alternative (apply_dns_fix) as the destination for the ops. It lists prerequisites (domain tracked, scan exists, registrar connection), which guide the agent's decision. However, it stops short of explicitly saying 'use this instead of apply_dns_fix when you want to preview only,' so the exclusion is implied rather than 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, idempotentHint, and destructiveHint, covering safety. The description adds meaningful behavioral context by detailing what data is included (e.g., latest scan findings, score history, alerts) and noting that Postmaster stats are included 'when connected'. No contradictions with annotations.

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

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

The description is a single, dense sentence that front-loads the core purpose ('Full detail for one tracked domain') followed by a structured enumeration of contents. Every phrase adds value, with no redundancy or unnecessary words.

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

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

Despite no output schema, the description thoroughly enumerates the return contents, making the tool's behavior predictable. Annotations cover safety, and the single parameter is fully documented. The description is complete for a read-only, single-domain detail 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?

The single parameter 'domain' is fully described in the schema with an example ('exampl.com'), covering 100% of schema fields. The description does not add additional parameter-specific syntax or format details beyond the schema, which is the baseline for high schema coverage.

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

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

The description clearly states the tool provides 'Full detail for one tracked domain' and enumerates the specific components: domain record, latest scan with per-check findings, score history, alerts, and Postmaster stats. This distinguishes it from siblings like list_domains (which lists domains) and get_scan_job (which focuses on a specific scan).

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

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

The description clearly implies use when you need comprehensive detail for a single domain. It does not explicitly mention when to avoid this tool or suggest alternative siblings, but the scope ('one tracked domain') and content specificity provide sufficient context for appropriate selection.

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 this as readOnly, non-destructive, and idempotent. The description adds value beyond annotations by specifying exactly what the tool reports (whether connected, which provider, test count, and supported providers when not connected), giving agents a clear picture of the output content without contradicting any hints.

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 'Report', and every word adds value. It efficiently conveys the tool's scope and the fallback behavior without any fluff or repetition of the title.

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

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

Given the tool's low complexity (no parameters, no output schema), the description is largely complete: it covers what is reported and the behavior when not connected. It could optionally mention the output format, but for a status-checking tool this is sufficient. The description covers the key context needed for an agent 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?

There are zero parameters, so the baseline is 4 as per rubric. The description adds no parameter-specific details, but none are needed. The schema coverage is 100% (empty schema), and the description compensates by explaining the fully parameterless nature implicitly.

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 'Report' and names the exact resource (seed-list inbox-placement provider connection status), including what aspects are reported (connection, provider, test count). It clearly distinguishes from sibling tools like connect_inbox_placement and list_inbox_placement_tests by focusing on connection status rather than individual tests.

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 of use is implied: checking connection status and seeing supported providers when not connected. However, it does not explicitly state when to use this vs alternatives, nor does it mention any exclusions or prerequisites. The 'when not connected' clause hints at a use case but does not name alternatives like connect_inbox_placement.

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. The description adds that the tool returns status (running/completed/failed) and, once measured, counts and score, which is useful polling context beyond annotations. No contradictions.

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 concise sentences: the first states the action and return values, the second gives usage timing. No redundant or filler content.

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 one-parameter polling tool with no output schema, the description covers purpose, input, return values, and usage sequence. The context is fully adequate for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, and the schema already explains testId as returned by start_inbox_placement_test. The description repeats this source but adds no new parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb 'Poll' and specifies the resource ('a seed-list inbox-placement test by testId'). It clearly differentiates from sibling tools like start_inbox_placement_test and list_inbox_placement_tests by focusing on a single test's status and results.

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

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

The description explicitly states when to call: 'Call after sending your campaign to the seed addresses from start_inbox_placement_test.' This provides clear timing guidance. It does not explicitly mention when not to use it or list alternative tools, but the context is sufficient.

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, and non-destructive behavior. The description adds useful behavioral context by detailing the rollup contents and ordering ('domains needing attention (lowest score / open alerts first)'), which goes beyond the annotations. No contradictions.

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 main verb and scope. The first sentence is a slightly long but well-structured list, and the second sentence gives usage. It is concise and free of jargon or fluff.

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 thoroughly enumerates all the important return values (average score, grade distribution, alerts, attention list, client breakdown), making the output fully understandable. Input is trivially complete with zero parameters. Sibling context confirms its portfolio-level role.

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, so there is no schema to clarify. According to the rubric, a baseline of 4 is appropriate for zero-parameter tools, and the description correctly avoids inventing parameter details.

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

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

The description clearly states the tool provides an org-wide deliverability rollup across all monitored domains, enumerating specific metrics like average score, grade distribution, alerts, and client-group breakdown. This distinguishes it from sibling getters like get_deliverability_score or get_domain, which focus on individual domains.

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

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

The description explicitly says 'Use this for an at-a-glance portfolio health summary across an agency or multi-domain account,' giving clear usage context. However, it does not explicitly name alternatives or specify when not to use it, so it stops short of a 5.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations by specifying the polling nature, the possible statuses, and the per-domain result structure.

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, well-structured sentence that front-loads the action and uses a colon to efficiently enumerate return fields. Every word contributes value.

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 polling tool with one parameter, no output schema, and strong annotations, the description fully covers the return structure and how it ties into scan_domains_batch. No critical information is missing.

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

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

Schema coverage is 100% with the parameter fully described as 'The jobId returned by scan_domains_batch.' The description adds no new semantic detail about the parameter beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Poll') and clearly identifies the resource ('async batch scan started with scan_domains_batch'). It distinguishes the tool from siblings by focusing on the batch scan job lifecycle and explicitly naming the initiating tool.

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 implies when to use this tool: after calling scan_domains_batch, to poll the async job. It doesn't explicitly list exclusions or alternatives, but the context is specific enough to guide correct selection.

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, covering the safety profile. The description supplements this with the 'latest' temporal behavior, the specific data fields returned, and the SNDS connection requirement, adding value without contradicting annotations.

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

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

The description is a single sentence with a colon-separated list of outputs followed by a short prerequisite clause. The main action is front-loaded, and every word contributes meaningful 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 present, the description fully enumerates the return fields (filter result, complaint-rate band, spam-trap hits, message volume, block status) and the necessary precondition. For a zero-parameter, read-only tool, this is complete and self-sufficient.

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, so schema coverage is vacuously 100%. The description adds context that the data is for 'the org's sending IPs', clarifying that the no-parameter call operates on organization-level data, which aligns with the baseline 4 for parameter-less tools.

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 the specific verb 'Return' with the resource 'per-IP reputation from Microsoft SNDS' and enumerates exact output fields (filter result, complaint-rate band, spam-trap hits, message volume, block status). This clearly distinguishes the tool from siblings like get_snds_status, which relates to connection state.

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

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

The description explicitly states that SNDS must be connected and points to connect_snds / get_snds_status as references. It provides clear prerequisite context but does not offer explicit when-not-to-use guidance against related report tools, so it earns a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about what data is returned (sync time, IP counts, blocked status) and implies the tool handles both connected and disconnected states. It does not mention any side effects, but no such effects are expected for a read-only status check.

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 first sentence lists the concrete reporting items; the second provides usage guidance. Every word contributes value.

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 zero-parameter, read-only status tool with strong annotations, the description is complete. It covers the main return data fields, the integration validation use case, and the relationship to sibling tools. No output schema exists, but the description sufficiently explains what the tool reports.

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, so the baseline is 4. The description correctly implies no input is needed by focusing entirely on the output. No parameter explanation is required.

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

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

The description clearly states the tool reports whether Microsoft SNDS is connected, last sync time and status, tracked IP count, and blocked IP count. It uses a specific verb ('Report') and resource ('Microsoft SNDS status'), and differentiates from sibling get_snds_ip_stats by explicitly mentioning it should be used first.

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

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

Explicitly says 'Use before get_snds_ip_stats to confirm the integration is live', giving a direct usage context and naming the alternative. This is clear guidance on when to use this tool versus get_snds_ip_stats.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds no new behavioral traits: 'Defaults to open alerts only' repeats schema info, and the alert-type examples are semantic context, not behavior. No side-effects, rate limits, or authentication details are disclosed beyond the annotations.

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

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

The description is a single, front-loaded sentence that states the primary action, gives concrete examples, and notes the default filter. Every word earns its place with no redundancy or fluff.

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 list tool with three fully documented parameters, no output schema, and strong annotations (read-only, idempotent, non-destructive), the description is complete enough. It provides an overview of alert types and the default open-alert behavior, which is sufficient for an agent to decide when to use 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 description coverage is 100%, so baseline is 3. The description adds minimal value: 'Defaults to open alerts only' restates the resolved parameter default, and the alert-type examples don't clarify any parameter semantics. The schema already fully documents limit, resolved, and severity.

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

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

The description clearly states the tool's function: listing the account's deliverability alerts, with concrete examples of alert types (score drops, check failures, blocklist listings). This specific verb+resource combination distinguishes it from sibling tools like list_domains or get_deliverability_report.

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 provides clear context that this tool lists alerts and defaults to open alerts, implying it's for viewing alerts. It does not explicitly mention alternatives or exclusions, but the purpose is well-scoped relative to siblings like resolve_alert.

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, establishing safe read behavior. The description adds the output fields, but does not disclose potential pagination, ordering, or performance characteristics. This is similar to the get_calls calibration example, where the added context is useful but incomplete.

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 that directly states the tool's purpose and output details. No unnecessary words or repetition, making it highly concise and well-structured.

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 zero-parameter, read-only list tool with no output schema, the description is adequately complete. It states what is listed and the key fields returned, covering the essentials. It could mention pagination or ordering, but these are not critical for understanding the tool's basic function.

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, so the baseline is 4. The description does not need to explain parameter meaning, and no information is missing regarding inputs.

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

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

The description clearly states the tool lists the account's tracked domains and specifies the included data (scan score, last scan time, open alert count). This is a specific verb+resource combination that distinguishes it from sibling list tools like list_alerts and list_scans.

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 provides clear context: this is for listing tracked domains rather than a single domain (get_domain) or other resource types. It does not explicitly mention alternatives or when-not-to-use, but for a simple list operation the context is sufficient.

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

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

The description adds behavioral context beyond annotations by revealing the ordering ('most recent first') and the response structure ('status and Inbox/Spam/Missing scores'). It does not mention pagination or limits, but the read-only and idempotent hints already cover safety, so the added detail is valuable without being excessive.

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 no wasted words. Every phrase contributes: 'recent', 'seed-list', 'for the org', 'most recent first', and the specific score fields. It is appropriately sized for a simple list tool.

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

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

For a parameterless, read-only list operation, the description fully covers the tool's purpose and expected output. The annotations provide safety semantics, and the description supplies ordering and return fields, so no output schema is necessary. It is complete for the tool's complexity.

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 zero parameters, the schema coverage is trivially 100% and no parameter explanations are needed. The description enriches understanding by clarifying what the returned list contains, matching the baseline for 0-parameter tools.

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

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

The description clearly identifies the action ('List'), the resource ('seed-list inbox-placement tests'), and the scope ('for the org'). It also states the ordering and output fields, distinguishing it from sibling tools like get_inbox_placement_test and start_inbox_placement_test.

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 implies this is for browsing the org's test history by specifying 'most recent first' and 'for the org'. However, it does not explicitly name alternative tools or exclusions (e.g., 'use get_inbox_placement_test for a single test'), though sibling names make the intent reasonably 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 the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context by detailing the output fields (provider, verification, last-used time) and connecting the tool's purpose to the detect-and-fix workflow.

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-loaded with the primary verb and resource, and each sentence contributes distinct value: the first details the output, the second gives usage context. No redundancy or fluff.

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 zero-parameter schema, strong annotations, and no output schema, the description thoroughly covers what the tool returns and why it should be used. It provides enough context 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?

The input schema has zero parameters, so the baseline score is 4. The description appropriately makes no parameter-specific claims, and no additional semantics are needed.

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

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

The description clearly states the verb ('List') and specific resource ('registrar accounts'), enumerates the supported providers, and specifies the output fields. It distinguishes itself from sibling tools by focusing on registrar connections and explicitly referencing related detect-and-fix 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 description provides explicit when-to-use guidance by stating the tool should be used to check if the detect-and-fix loop is available before attempting it. It does not explicitly list when-not-to-use scenarios, but it clearly contextualizes the intended use case.

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 safety traits are covered. The description adds the field list and the scoping between all domains and one domain, but does not disclose additional behavioral traits like default limit handling or pagination behavior. This is adequate but not rich.

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, well-structured sentence that directly states the action, scope, and output fields. There is no redundancy or filler, making it highly concise and easy to parse.

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 list tool with two optional parameters, full schema coverage, and strong annotations, the description is sufficient. It includes the output fields and the filtering behavior, so there are no significant 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?

Schema description coverage is 100% for both 'limit' and 'domain', so the parameters are already well-documented. The description adds no further semantics beyond mentioning the domain filter ('when a name is given'), which is already in the schema. 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 uses a specific verb ('List') and resource ('scans'), specifies the fields returned (id, domain, run time, score), and distinguishes from siblings by noting the aggregation across all tracked domains or a single domain via the 'name' parameter. This is clear and 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?

The description clearly indicates when to use the tool: for listing recent scans, either globally or filtered to one domain. It does not explicitly exclude alternatives or mention when not to use it, but the context of 'recent scans' and the optional domain filter provides adequate usage 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 description adds important behavioral details beyond the destructiveHint annotation: it is 'DESTRUCTIVE and not reversible' and deletes the domain's scan history. It also discloses authentication scope requirements. No contradiction with readOnlyHint=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?

The description is compact yet information-dense, covering the action, side effects, irreversibility, permissions, and alternative in two sentences. Every clause contributes meaningful 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 destructive tool, the description covers all critical aspects: the action, irreversible nature, deleted data, required permissions, and the alternative for adding domains. With only one parameter and no output schema, nothing essential 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?

The sole parameter 'domain' is fully described in the schema with an example and meaning. The description adds no additional parameter semantics, but the schema coverage is 100%, 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 clearly states the action: 'Stop monitoring a domain and delete it (and its scan history)' with a specific resource and scope. This distinguishes it from sibling tools like scan_domain, which the description explicitly contrasts for adding domains.

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

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

It explicitly instructs when to use scan_domain instead for adding domains, providing an alternative. It also states the required API key permissions (owner/admin with write/full scope), clarifying prerequisites. This goes beyond vague context to actionable 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 declare idempotentHint true and readOnlyHint false; the description reinforces this by explaining the no-op behavior and explicitly requiring write/full API key access. It also explains the reopen functionality via resolved=false, which is not apparent from annotations alone.

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 three short sentences, each carrying distinct value: action, auth requirement, and idempotency. 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 simple two-parameter mutation with no output schema, the description covers purpose, auth, idempotency, and parameter behavior fully. The schema completes the remaining details.

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%: alertId references list_alerts or get_domain as the source, and resolved explains its default and meaning. The tool description repeats the resolved=false behavior but adds no significant additional 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 ('Mark') and identifies the exact resource ('an alert'), also distinguishing the dual action of resolving or reopening. It clearly differentiates from sibling tools like list_alerts, which only lists alerts without modifying them.

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

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

The description states the prerequisite of write/full API key scope and the idempotent behavior (resolving an already-resolved alert is a no-op). While it doesn't explicitly name alternative tools for when not to use it, the clear purpose and lack of overlapping siblings make the usage context 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?

Annotation Contradiction: Annotations declare readOnlyHint=true, but description states 'saves the scan to the domain history in your account,' implying a state mutation. This directly contradicts the read-only hint. Aside from contradiction, the description otherwise adds useful context about not_applicable/unverified statuses and plan-tier 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?

Every sentence contributes: action, output, status semantics, scoring explanation, plan behavior, persistence. Long but dense and front-loaded; 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 complex scanning tool with no output schema, description covers statuses, score denominator, plan-tier differences, and side effects. It gives enough for an agent to set expectations and interpret findings.

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 has 100% coverage for both params, so baseline is 3. Description adds meaningful context for dkimSelectors by explaining DKIM unverified cases (e.g., Amazon SES Easy DKIM random selectors) and reinforces domain scope with examples.

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?

Description uses a specific verb+resource ('Run a full email-deliverability scan') and enumerates concrete checks (SPF, DKIM, DMARC, MTA-STS, etc.) and result (0-100 score with per-check findings). It clearly distinguishes from narrower sibling tools like check_blocklists by emphasizing a full scan.

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?

Provides clear context: use for a full deliverability scan that returns a scored report, respects plan tier, and persists to history. It lacks explicit 'use X instead' exclusions, but the scope and side effects make appropriate use 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?

Beyond the annotations, the description discloses important behavioral traits: the operation is asynchronous, returns a jobId, is not saved to monitoring or history, and requires write/full API key scope. It also warns about the 30s limit and directs the user to poll get_scan_job for status, which is valuable context not present in annotations.

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

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

Three concise sentences, each earning its place: the first states the core function and benefit, the second explains the polling workflow, and the third covers auth and side effects. The most important information is 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 tool with a single parameter and no output schema, the description fully covers the user's needs: what to expect (jobId), how to get results (poll get_scan_job with statuses), auth requirements, and what won't happen (not saved). It is complete for its complexity.

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

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

The schema already documents the 'domains' parameter with a clear description ('1-50 domains to scan'), giving 100% coverage. The description adds a bit of context ('up to 50 domains') but does not need to elaborate further because the schema is self-sufficient.

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 ('Queue'), a clear resource ('asynchronous batch scan of up to 50 domains'), and the immediate result (jobId). It distinguishes from siblings by noting it 'avoids the 30s per-call limit' and by referencing the polling workflow via get_scan_job.

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

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

The description clearly indicates when to use this tool: for batch scanning up to 50 domains asynchronously to avoid the per-call limit. It also tells the user to poll get_scan_job. However, it does not explicitly state alternatives like scan_domain for single domains, though the sibling context implies 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?

The description discloses behavioral details beyond the annotations: it returns a testId and seed addresses, may require a header, and requires specific permissions. It also implies an asynchronous workflow by telling the user to poll for results. While not exhaustive, it adds meaningful context about what the tool does and what is needed to use it.

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-loaded with the primary action, and packs essential information about return values, follow-up steps, and prerequisites without any fluff. 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?

Given there is no output schema, the description appropriately explains the return values (testId, seeds, header) and the necessary follow-up (polling). It also covers prerequisites. It does not mention potential errors or what to do if the provider doesn't require a header, but it is sufficiently complete for a simple tool with one optional parameter.

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

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

The input schema has 100% coverage for the single optional 'subject' parameter, with a clear description in the schema. The description does not add any additional parameter semantics, but the schema already fully documents the parameter, 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 clearly states the tool's function: 'Start a seed-list inbox-placement test.' It uses a specific verb ('start') with a specific resource ('inbox-placement test'), and the description of return values (testId, seed addresses, optional header) distinguishes it from sibling tools like get_inbox_placement_test or list_inbox_placement_tests.

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 provides clear usage context: it explains that after starting a test, you should send to the seeds and then poll get_inbox_placement_test for the verdict. It also states prerequisites (inbox-placement connected, owner/admin key with write/full scope). It does not explicitly name alternative tools, but the workflow is clear enough.

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