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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior on top: counts are message-weighted, the window defaults to 30 days and is clamped at 365, results are capped at 50 days with a truncated flag, and paging backward is done via day_before. This discloses the exact response-shaping and limit behavior an agent needs.

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, front-loaded with what is returned (counts and dispositions) before the window rules and the paging escape hatch. Every sentence carries distinct information and there is 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 compensates by enumerating the returned fields (total, DMARC pass, DMARC fail, disposition) plus the truncated flag, and it covers defaults, clamping, and paging. 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 description coverage is 100%, so the baseline is 3, and the description earns an extra point by adding parameter meaning the schema omits: the 365-day clamp, the 50-day truncation with a truncated flag, and the backward-paging pattern using day_before. It does not restate the domain filter semantics, but the schema already covers those.

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 and output shape: per-day message counts broken into total, DMARC pass, DMARC fail, and disposition buckets, with message-weighted semantics. That is far more specific than a tautology. It stops short of a 5 because it never contrasts itself with sibling tools like get_report_records or query_records that an agent might otherwise pick for DMARC 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?

Usage guidance is operational rather than selective: it explains the default 30-day window, the 365-day clamp, the 50-day truncation, and how to page backward with an earlier day_before. That is genuinely useful, but there is no statement of when to choose this tool over the sibling reporting tools, which is the main when-to-use decision an agent faces.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful content disclosure (the response includes a DMARC policy snapshot and the RUA tag to publish), but with no output schema it does not describe remaining fields, auth needs, or error 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?

One compact sentence with no filler, front-loaded on the resource and key. It is a noun-phrase fragment rather than a full sentence, and 'the RUA tag to publish' is slightly compressed, 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 simple single-record getter with annotations covering safety and a fully documented parameter, the definition is adequate. With no output schema, however, the description only partially describes the return payload and omits behaviors such as not-found handling, so a gap remains.

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 id parameter with 100% schema description coverage, including the hint that it comes from list_domains. The description adds nothing about the id 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 names a specific resource (one domain) and its retrieval key (by id), and lists the distinctive payload it returns (DMARC policy snapshot, RUA tag), so an agent can separate it from list_domains. It lacks an explicit verb and does not name a sibling directly, so it falls just short of 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?

Usage is only implied: the 'by id' phrasing and the schema note that the id comes from list_domains suggest a list-then-detail flow. There is no explicit when-to-use statement, no exclusions, and no named alternative.

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, so the safety profile is covered. The description adds genuine behavioral context beyond that: the row granularity, the sort order (volume descending), and the hard cap of 50 rows, which tells the agent results are truncated rather than complete.

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, zero filler, and the most important fact (what a row represents) is front-loaded. The sort order and row cap follow as useful qualifiers rather than padding.

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

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

With no output schema, the description does the necessary work of explaining the returned row shape, its fields, ordering, and cardinality cap. It omits only the default date-window behavior, which the schema already supplies.

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 domain, day_after, and day_before are fully documented in the schema, including defaults. The description adds no additional parameter meaning, which is the expected baseline when the schema carries the burden.

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

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

The description states the resource precisely: one row per receiving mailbox provider (DMARC reporter_org) with message-weighted pass/fail counts. An agent knows exactly what data comes back, though it never names a contrasting sibling such as get_alignment_summary to differentiate scope.

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

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

There is no when-to-use or when-not-to-use guidance. With siblings like get_alignment_summary and list_sending_sources that also summarize DMARC data, the description leaves the agent to infer which tool answers which question.

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, non-destructive), so the description's added value is real: it discloses that third-party strings are length-capped (lossy output), caps results at 50 rows, and defines the truncation/next_offset contract. That is genuine behavioral context beyond the structured fields, though it omits error behavior for an invalid id.

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, each carrying distinct information: what is produced, what is degraded, and how to page. The pagination rule is stated last where it is needed, 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 usefully enumerates the returned row fields (source, count, alignment, disposition, identifiers) and the truncation flag, so the agent knows the shape of the result. The remaining gap is routing: it never says how to obtain the report id or when this beats query_records.

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

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

Schema coverage is 100% and both parameters are documented there, so the baseline is 3. The description only reinforces the schema by explaining the next_offset → offset round-trip, adding no syntax or format detail the schema lacks.

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: re-parses one aggregate XML into per-record rows, and enumerates the row fields. Clear what it produces, though it never names which sibling to use first (list_aggregate_reports) to obtain the id it requires.

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 'one aggregate XML' plus the pagination instruction ('when truncated is true, pass next_offset back as offset'), which tells the agent how to continue an existing sequence. It gives no when-to-use vs query_records or list_aggregate_reports, and no preconditions beyond the pagination loop.

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 the safe read-only profile, so the bar is lower, and the description clears it by disclosing a non-obvious pagination contract: it does not follow standard pagination, truncation is signalled by 'truncated', and 'next_cursor' must be passed back as 'cursor'. This is exactly the kind of behavior an agent could not infer from structured data.

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 short sentences, each carrying distinct information: result shape, downstream use, pagination quirk, cursor semantics. Front-loaded with the row semantics and free of 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 document the return fields, and it does name 'truncated' and 'next_cursor' and explain their meaning. Filter parameters (domain, reporter_org, date bounds) are left untouched, but their names are largely self-describing, so the omission is 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?

Schema coverage is only 60%, and 'cursor' has no schema description at all. The description compensates by explaining what the cursor is for ('The cursor carries the filters') and how to advance it, which is the highest-risk parameter to get wrong. The filter params remain undocumented, so it does not fully close the coverage gap.

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 the resource and its granularity precisely: 'One row per ingested aggregate XML.' Combined with the name, an agent knows exactly what is returned, and the mention of get_report_records begins to separate it from siblings. It stops short of explicitly stating what filters scope the list, 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?

It gives a clear downstream step ('Use the id with get_report_records') and explains the pagination protocol, which is genuine usage guidance. However, it never says when to choose this over siblings like query_records or get_alignment_summary, so alternative selection 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 cover the safety profile (readOnly, non-destructive, openWorld), so the bar is lower. The description still adds real context the annotations lack: the result set is scoped to the token's organisation, matching is case-insensitive with a trailing dot stripped, and the returned ids are the identifiers other tools accept. It does not address pagination or result size limits.

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 no filler; the resource scope, the filter behavior, and the return contract each appear once and in a sensible order. Nothing could be cut without losing 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?

No output schema exists, so the description must carry the return contract, and it does so at a useful level: the ids other tools consume. Minor gaps remain around result count, ordering, and pagination, but for a one-parameter read tool this is close to 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 coverage is 100% and already documents fqdn as an exact domain name. The description adds semantics the schema omits, notably case-insensitive matching and trailing-dot normalization, which materially affect how the caller should format the value.

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 (list) and resource (domains), plus the scoping qualifier 'registered on this token's organisation'. An agent can distinguish it from get_domain by the list-vs-single semantics, though the sibling is never named.

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 usage cue for the fqdn parameter ('Pass fqdn for an exact hostname match') but never states when to prefer this tool over get_domain or the other listing tools. Usage is implied by the resource scope rather than made 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 cover safety (readOnly, non-destructive, open-world), so the description's job is added context — and it delivers: message-weighted counts, greatest-value-wins identity strings that are length-capped, volume-descending sort, a hard 50-row limit, and a 'truncated' flag. It does not mention auth scope or latency, but the return-behavior disclosure is unusually 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?

Four tight sentences, each carrying a distinct fact (granularity, weighting, identity capping, sort/limit). Information is front-loaded with the row shape. Slightly dense with no explicit lead verb, but 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 must explain the shape of the return, and it does: one row per bucket, weighted counts, capped identity strings, sort order, row cap and truncation signal. Combined with a fully documented input schema and safety annotations, 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?

Schema coverage is 100%, so per the rubric the baseline is 3 and the schema already documents domain, group_by, day_after and day_before. The description confirms the source_ip default and clarifies that window bounds are inclusive via the schema rather than adding new syntax, so it adds only marginal value.

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 the resource (sending IPs / autonomous systems / From domains) and the row granularity, plus sorting and the default grouping, so an agent can tell what this returns. It does not explicitly contrast itself with siblings like get_alignment_summary or query_records, but the construct is specific enough to be distinguished.

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 such as list_aggregate_reports or query_records, and no prerequisites or exclusions. The default 30-day window and grouping behavior are only implied by the schema, not framed as 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?

Annotations already cover the safety profile (readOnly, non-destructive, open-world), so the bar is lower. The description adds genuinely useful behavior beyond that: rows are narrowed, third-party strings are length-capped, and pagination is non-standard (truncated/next_cursor contract). It doesn't mention auth or rate limits.

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?

Five tight sentences, front-loaded with what the rows are, no repetition, and the pagination contract is stated as a concrete action rather than prose.

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, so the description must carry return semantics, and it does mention truncation/cursor and length-capping. It still doesn't say what a row contains or the shape of the response, but it is adequate for a parameter-driven query tool with strong 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 53%, so several params (domain, day_after, day_before, disposition, alignment booleans) lack descriptions while others (day, cursor, source_ip) are self-evident. The description adds filter semantics for alignment outcome and cursor but does not document the unlabeled parameters, leaving the coverage gap only partially filled.

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 the resource concretely ('day-aggregated fact rows') and names usable drill axes (IP, day, alignment outcome), which distinguishes its granularity from aggregate/report siblings. It stops short of naming a specific sibling alternative, so an agent still has to infer when to prefer it over get_report_records.

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

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

Gives clear context ('drill into one IP, day, or alignment outcome') and an explicit continuation protocol for truncation, including that the cursor carries filters. No exclusions or named alternatives are stated, so it doesn't reach 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value by noting that user is null for an API token, which is a real behavioral quirk an agent must handle. However, it does not describe response shape or what 'the rest' of the plan features contains, and there is no output schema to fall back on.

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 compact two-clause sentence with no padding, and the most important content (what identity is returned) comes first. The phrase 'and the rest' is loose and slightly undercuts the precision, keeping it from a 5.

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

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

With no output schema, the description carries the full burden of explaining return values. It names api_tokens_enabled, retention_days, and the user-null case, but dismisses the remaining fields as 'the rest', leaving an agent unsure what else to expect from a plan-features payload.

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 the baseline of 4 applies. Nothing in the description is needed to explain inputs, and nothing about the input contract is ambiguous.

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 identifies the resource precisely: the organisation the token is bound to plus resolved plan features, and it clarifies the user field semantics for API tokens. It reads as a noun phrase rather than an explicit verb+resource, so it is clear but slightly less crisp than a well-formed definition. No sibling overlaps with identity/plan inspection, so differentiation is not needed here.

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 call this tool, when not to, or what alternatives exist. The zero-parameter, obviously diagnostic nature of the tool makes usage inferable, but the description itself provides no guidance.

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