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

No annotations are provided, so the description carries the full behavioral burden. It does not state that this blocks future sends to that address, whether re-adding is idempotent, what happens if the address is already suppressed, or whether elevated permissions are needed for a mutation tool.

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

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

A single front-loaded sentence with no padding, which is efficient. It is under-specified rather than verbose, so it loses points for content, not for structure.

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

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

A mutation tool with no annotations, no output schema, and 0% parameter coverage needs the description to explain effects and parameters. It delivers only the barest statement of intent, leaving the agent without enough to call it correctly.

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

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

Schema description coverage is 0%, so nothing documents the two parameters. The description's word 'address' loosely maps to 'email', but it never explains what 'reason' is for or what format either expects, so it fails to compensate for 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?

States a specific verb (add) and resource (address to the suppression list), so an agent can distinguish it from list_suppressions and remove_suppression. It does not explicitly name those siblings or state scope, but the purpose is unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no mention of the alternatives (remove_suppression, list_suppressions) that share this domain. The agent must infer usage purely from the name.

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?

With no annotations at all, the description carries the full burden. It usefully discloses that credentials can come from the dashboard or be supplied per-request, which is real behavioral context beyond the schema. But for a tool that writes live DNS records it says nothing about whether existing records are overwritten, what happens on partial failure, or what auth level is required.

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

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

Two tight sentences with no filler, and the core action is front-loaded ahead of the credential nuance. Nothing is redundant, though it is arguably too terse for a live-DNS mutation.

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 mutation tool with no annotations and no output schema, the description covers the action and credential model but omits vercel handling, overwrite/idempotency semantics, and any indication of what the caller gets back. Adequate as a minimum-viable definition, incomplete for the risk profile.

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 33%, so the description has to compensate. It clarifies credential sourcing for Cloudflare and GoDaddy, adding meaning beyond the schema's brief 'GoDaddy api key/secret' note. However, the provider enum includes 'vercel' and the description never mentions vercel, leaving that accepted value and its credential handling unexplained.

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 ('Apply Groundmail DNS records for a domain'), so an agent knows this writes DNS records rather than just creating or verifying a domain record. It does not explicitly differentiate itself from the close siblings create_domain and verify_domain, but the action is unambiguous.

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

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

It gives conditional credential guidance per provider (Cloudflare/GoDaddy can use dashboard-stored credentials, GoDaddy also accepts one-time credentials), which is implied usage context. However, it never says when to call this versus create_domain or verify_domain, nor what prerequisites (domain must exist, be verified) apply.

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?

With no annotations, the description carries the full disclosure burden, and it does add real value by stating the post-creation state: the domain cannot send production mail until DNS is applied and verified. It says nothing about auth requirements, idempotency/duplicate-domain behavior, or rate limits, so the safety profile remains underspecified.

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 short sentences, both earning their place: the first defines the action, the second front-loads the critical follow-up constraint. No redundant restatement of the title or schema.

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

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

For a simple two-parameter creation tool with no output schema and no annotations, the description supplies the action plus the essential downstream workflow constraint. Only edge-case behavior (duplicate domains, errors, immediate usability of the returned domain) is missing, which is a minor gap.

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

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

Schema coverage is 100% with both parameters documented, including an example for 'name', so the schema already carries the semantics. The description adds no meaning beyond the schema for 'inbound_enabled' or the domain-name format, making 3 the correct baseline.

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

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

States a specific verb and resource ('Add a sending domain'), which clearly separates it from list_domains, apply_domain_dns, and verify_domain. It does not name those siblings explicitly, but the second sentence implies this is the first step of a multi-step domain workflow.

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 conveys central context — that this is the provisioning step whose DNS must still be applied and verified — which implicitly routes the agent to apply_domain_dns/verify_domain next. However, it never names an alternative or states when NOT to use this tool, so usage is only implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It does disclose one meaningful trait: the created resource is a draft, not a live template. However, it says nothing about permissions, whether the draft must later be published, how optional fields behave, or what the mutation returns.

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

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

A single, front-loaded sentence with no filler. It is well structured, though its brevity reflects under-specification rather than efficient completeness.

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 mutation tool with six parameters, no annotations, no output schema, and 0% schema coverage, one sentence leaves large gaps: required-field semantics, draft lifecycle, and any behavioral implications of 'draft' versus publishing.

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 0%, so the description must compensate for six undocumented parameters. It only touches the format concept ('html or blocks'), incidentally revealing the enum options, while required fields (name, subject) and alias/text remain unexplained in both schema and description.

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 (Create) and resource (draft email template), and adds format scope (html or blocks). The word 'draft' implicitly separates it from publish_template, though no sibling is named explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives like publish_template or get_template. Usage context is only inferrable from the verb.

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?

With no annotations present, the description carries the full burden, yet it does add a genuinely valuable behavioral fact: the signing secret is returned only once and cannot be retrieved later. However, it omits permissions/auth requirements, whether the endpoint is active immediately, idempotency behavior, and what the default event set is.

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 short sentences with zero filler; the core action is front-loaded and the return-value caveat follows immediately. Every sentence earns its place.

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

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

For a mutation tool with no annotations and no output schema, the description usefully flags the one-time secret but leaves the caller guessing about activation/verification, default events, and the shape of the returned endpoint object. Adequate but with clear 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% (url and events are both documented), so the schema already handles parameter meaning. The description adds no additional parameter detail such as valid event type values or URL constraints, so the baseline 3 applies.

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

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

States a specific verb (Create) and resource (webhook endpoint), clearly mapping to the endpoint concept. It does not explicitly name or differentiate from siblings like list_webhooks or delete_webhook, but the CRUD verb makes the distinction obvious without opening schemas.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., send_test_webhook_event to validate before creating). Usage is only inferable from the verb.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only restates the mutation. It does not disclose whether deletion is permanent, whether it requires elevated permissions, or whether in-flight deliveries are affected — critical context for an irreversible operation.

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

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

A single front-loaded sentence with zero filler and no redundancy. It is efficient, though its brevity comes at the cost of the behavioral detail noted elsewhere.

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 destructive tool with no annotations and no output schema, the description is too thin: it omits irreversibility, permission requirements, and side effects on existing deliveries. An agent could invoke it correctly by name but without understanding the consequences.

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

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

Schema description coverage is 100% and the single parameter already documents the id format (wh_…). The description's 'by id' adds no meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb (Delete) and resource (webhook endpoint) with the identifying key (id), so the agent knows exactly what the tool does. It does not, however, distinguish itself from siblings like create_webhook or list_webhooks beyond the obvious verb difference.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no mention of what happens to webhook delivery history or configuration. The agent must infer usage entirely from the name.

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?

With no annotations, the description carries the full burden, and 'best-effort' is a genuine disclosure that the metrics may be incomplete or approximate. It says nothing about auth requirements, rate limits, data freshness, or whether results are aggregated per-domain or per-send.

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

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

A single tight sentence with the resource and window scope front-loaded and zero wasted words. Nothing is redundant and every phrase earns its place.

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

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

No output schema or annotations exist, and the description does not indicate what metrics are returned or how they are broken down. For a simple one-parameter read tool this is adequate but leaves real gaps for an agent predicting the response.

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

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

Only one optional parameter exists and its enum (7d/30d) is self-documenting in the schema; the description merely restates those two values. It does clarify that the window applies to 'recent sends', adding modest meaning, but no default or omission behavior is described.

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 ('Fetch') and resource ('deliverability metrics') with scope ('recent sends'). An agent can tell it apart from list_emails/get_email, though the description never names a sibling or explicitly contrasts with 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The only implicit cue is 'recent sends', which hints at the reporting use case but does not tell the agent when this tool is the right choice.

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?

With no annotations, the description carries the full behavioral burden, yet it only restates the lookup. It says nothing about what the returned email contains (delivery status, body, headers), whether a deleted or unknown id errors, or whether any auth/scope is required.

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

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

A single short sentence with the resource and identifier format front-loaded; every word earns its place and nothing is padded.

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

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

For a simple single-entity read with a fully documented parameter and no output schema, the description is minimally sufficient to invoke the tool. However, it leaves an agent guessing about the shape and fields of the returned email and error behavior on a missing id.

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 one parameter with 100% schema description coverage, so the schema already documents the id. The description's '(msg_…)' prefix hint duplicates what the schema field description already states, adding no new meaning.

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

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

States a specific verb (Get) and resource (a single email) plus the identifier form (msg_…), which cleanly separates it from list_emails. It does not name or contrast any sibling explicitly, so it stops 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?

There is no guidance on when to use this versus list_emails or other retrieval tools, and no mention of prerequisites such as needing an id obtained from a send/list call. The usage context is only implied by the verb 'Get'.

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?

No annotations are provided, so the description carries the full burden. It implies a read but does not state that it is read-only, whether id and alias are mutually exclusive or which wins if both are supplied, or what happens when the template is not found. These are meaningful gaps for a lookup tool.

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

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

A single short sentence with the key information front-loaded and no wasted words. It is efficient, though arguably too terse for the behavioral context it omits.

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

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

A simple two-parameter read with no output schema, so minimal description is defensible, and the parameters are covered. However, missing error behavior and the id/alias interaction leaves an agent with avoidable ambiguity.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema; the description's 'by id or alias' simply restates that. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds nothing beyond it.

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

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

States a specific verb (Get) and resource (template) plus the lookup keys (id or alias), so the operation is unambiguous. It does not explicitly distinguish itself from siblings like list_templates or publish_template, but the get/list contrast is inferable.

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

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

There is no when-to-use guidance, no statement of prerequisites, and no alternatives named (e.g., 'use list_templates to enumerate templates'). The agent must infer that this fetches a single template.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: it does not state that results are paginated (only the schema hints at it), whether it requires authentication, whether it returns empty vs. error on no domains, or any rate limits. "List" weakly implies a safe read, but the disclosure is minimal for a tool with zero annotation coverage.

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

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

A single short sentence, front-loaded with the verb and resource and free of waste. It is efficient, though the size reflects under-specification rather than deliberate economy.

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 paginated list tool with 100% parameter coverage, the description is barely sufficient. There is no output schema, and while "sending domains" implies the return content, nothing is said about pagination flow, empty results, or authentication, which leaves gaps for an agent driving the cursor loop.

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 limit ("Page size (1–100)") and cursor ("Opaque cursor for the next page") are fully documented in the schema. The description adds no format or usage detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ("List sending domains") and scopes it to "this account," which is enough to distinguish it from the mutation siblings create_domain, verify_domain, and apply_domain_dns. It does not explicitly name the alternative list tools or clarify how it differs from other list_* tools, so it stops short of the 5 calibration.

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 explicit when-to-use or when-not-to-use guidance and no mention of prerequisites such as a verified account or required permissions. The listing intent is only implied by the verb, which is weak routing help among so many sibling tools.

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

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

With no annotations the description carries the full burden, and it does add one genuinely useful fact the schema does not: results are restricted to mail sent from this account, not received mail. However it omits ordering ('recent' is undefined), pagination semantics despite exposing a cursor, and any statement that this is a non-destructive read.

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

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

A single front-loaded sentence with no filler; the scope constraint appears immediately. It is efficient, though arguably terse to the point of omitting needed context rather than being optimally sized.

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

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

For a simple two-parameter read tool with no output schema, the definition is minimally viable but leaves ordering, result fields and pagination behaviour unaddressed. An agent can invoke it, but cannot predict what it will get back.

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

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

Schema description coverage is 100%, so both limit and cursor are already documented in the schema with sensible meanings. The description adds nothing further about them, which is the expected baseline when the schema does the work.

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

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

States a specific verb and resource ('List recent emails') plus a scope qualifier ('sent from this account'), which lets an agent separate it from get_email and send_email. The qualifier 'recent' is left undefined, so it is clear but not fully differentiated in behaviour.

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 get_email or any other sibling, and no prerequisites or exclusions are mentioned. Usage is only inferable from the name, which is the definition of no real 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?

No annotations are provided, so the description carries the full behavioral burden, and it does almost nothing: 'List' implies a safe read, but pagination behavior, result ordering, whether it includes recently removed addresses, and any auth requirements are all unstated.

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

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

A single front-loaded sentence with zero filler. It is efficient, though the brevity is partly under-specification rather than disciplined conciseness.

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 paged list tool the schema already covers all three optional parameters and no output schema exists, so little is strictly missing. Still, nothing explains that this returns a paginated collection or how cursor/limit interact, leaving a small gap an agent would appreciate.

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% – email filter, limit (1-100), and cursor are all documented in the schema itself. The description adds no parameter meaning, which is acceptable at this coverage level, yielding the baseline 3.

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

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

States a specific verb+resource: 'List suppressed recipient addresses.' An agent can tell it lists suppressions, but the description never differentiates it from siblings like add_suppression, remove_suppression, or list_emails, so it stops 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?

No when-to-use guidance, no prerequisites, and no mention of the obvious alternatives (add_suppression/remove_suppression) that share the suppression resource. The agent gets a purpose but no routing logic.

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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no indication of whether results are paginated, filtered, ordered, or permission-gated. The only signal is the verb 'List', which the name already conveys.

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

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

A single front-loaded sentence with zero waste, but it is under-specified rather than genuinely concise: for a three-parameter, paginated, filterable endpoint, one sentence leaves material information unstated.

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 a cursor param, a status filter enum, no output schema, and no annotations, the description should explain pagination and filtering behavior. It covers none of this, so an agent cannot call the tool confidently beyond passing bare parameters.

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 67% – limit and cursor are documented in the schema, but status (an enum) has no description anywhere. The description adds nothing about filtering by draft/published or paging semantics, so it fails to compensate for the 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?

States a specific verb and resource ('List email templates'), so an agent immediately knows the operation. However, it does nothing to distinguish itself from the sibling get_template (single-template retrieval) or create_template, leaving the reader to infer the difference from plurality alone.

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

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

No guidance on when to use this versus get_template or how to page through results, despite a cursor parameter implying multiple pages. The agent must infer all usage context from the name.

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?

With no annotations provided, the description carries the full behavioral burden, and it discloses almost nothing: no pagination behavior despite cursor/limit parameters, no rate limits, no permission requirements. 'For this account' hints at scoping, but that is the only behavioral signal.

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

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

A single tight sentence with zero filler and the resource stated up front. It is appropriately sized for a simple read tool, though it could have used its brevity budget to add one useful routing or pagination note.

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 paginated list tool with full schema coverage and no output schema, the description is minimally adequate. It omits any note on pagination workflow or what a webhook endpoint entry contains, but nothing critical blocks a correct call.

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

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

Schema description coverage is 100%, so both parameters (limit, cursor) are already documented in the schema, including the 1-100 range and cursor semantics. The description adds no parameter meaning beyond what structured data provides, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('List webhook endpoints') and scopes it to 'this account', which distinguishes it from resource-level siblings like get_email or list_domains. It stops short of explicitly differentiating itself from other list_* tools, but the resource noun is unambiguous.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternative tools. An agent gets no help deciding between list_webhooks and create_webhook or send_test_webhook_event, though the verb 'List' makes the intent reasonably inferable.

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?

With no annotations, the description carries the full burden. It usefully discloses that publishing creates an immutable snapshot, which is a valuable behavioral trait. However, it omits permissions required, whether the operation is idempotent, what happens if the template is already published, and other side effects.

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

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

A single front-loaded sentence of nine words that conveys the action and its core consequence without any filler. Every word earns its place.

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

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

For a mutation tool with no annotations, no output schema, and two completely undocumented parameters, the description is too thin. It states the core behavior and immutability but leaves the agent without usage guidance or parameter meaning, which are needed to invoke it correctly.

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

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

Schema description coverage is 0% for two parameters, id and alias, and the description does not mention either one. There is slight semantic value from the word 'template' implying a template identifier, but the agent receives no guidance on which parameter to use or what alias means.

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

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

The description states a specific verb and resource: 'Publish a template.' It also adds the key outcome, 'snapshotting an immutable version for sends,' which clearly differentiates it from sibling tools like create_template, get_template, and list_templates.

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 'for sends' hints at usage context, but there is no explicit guidance on when to publish versus create or get a template, no prerequisites, and no exclusions or alternatives named. The agent must infer the situation.

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?

With no annotations, the description carries the full behavioral burden, and it falls short. 'Remove' implies a destructive mutation, but the description never states whether it is permanent, whether it requires permissions, or what happens if the id/email doesn't exist or matches nothing.

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

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

A single front-loaded sentence that names the action, the resource, and the two identifier options with zero waste. It is efficient, though verging on terse for a mutation 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 simple two-parameter deletion tool with full schema coverage and no output schema, the essentials are present, but a destructive operation should disclose permanence and error behavior. The description is the only source for that and omits it.

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

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

Schema coverage is 100%, so the schema already documents both parameters, and the description's 'by id or email address' largely restates the schema's 'alternative to id' note. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb ('Remove') and resource ('suppression') plus the two identifiers that select the target. It is distinguishable from its direct siblings add_suppression and list_suppressions, though it doesn't name them explicitly.

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

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

No when-to-use or when-not-to-use guidance, no prerequisites, and no alternatives named. The only hint is the identifier format ('by id or email address'), which is usage-adjacent but not actual routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it falls short. It does not mention rate limits, suppression-list interactions (despite a list_suppressions sibling), authentication/domain-verification requirements (that constraint only appears in the schema for 'from'), or failure behavior. Only the word 'transactional' hints at intended use.

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

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

Two tight sentences, action-first, with the core capability front-loaded and the parameter modes following. Every clause earns its place with zero 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 9-parameter mutation tool with a nested 'variables' object, no annotations, and no output schema, the description is minimally adequate. It covers the primary send modes but omits reply_to, the variables format, and any response or error expectations that an agent would need in the absence of an output schema.

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

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

Schema description coverage is only 67% (html, text, reply_to are undocumented), so the description must compensate. It does so by clarifying the mutually exclusive content paths — raw content vs. template — which is the key parameter relationship an agent needs to choose correctly, though it leaves reply_to and the variables object shape unexplained.

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 (Send) plus resource (transactional email) and provider (Groundmail), which is immediately distinguishable from the read-oriented email siblings like list_emails and get_email. An agent can tell at a glance this initiates a send rather than a query.

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

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

Gives clear context for the two invocation modes ('subject + html/text, or a published template_id / template_alias with optional variables'). It does not state exclusions or when-not to use it, but there is no competing send tool among the siblings, so the routing need is minimal.

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?

No annotations are provided, so the description carries the full burden. It clarifies the endpoint and the side effect of 'deliver' (enqueuing delivery to account webhooks), which is useful. But it doesn't state whether the simulated event is persisted, whether the account must be configured, or what the response contains.

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 compact sentences with zero filler. The endpoint and the core action are front-loaded, followed by the optional delivery behavior.

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 3-parameter tool with full schema descriptions and no annotations, the description covers the purpose, the test context, and the side effect of the deliver flag. It could be richer about whether events persist or are only routed, but it is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including the event enum and the deliver/email_id defaults. The description adds only a general sense of the operation; it doesn't extend parameter meaning beyond what the schema provides.

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

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

States a specific verb ('Simulate') and resource ('webhook event') with an explicit route (POST /emails/test) and use case (CI or local testing). The 'test' framing clearly distinguishes it from sibling webhook tools like create_webhook or delete_webhook.

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?

Names the intended context (CI or local webhook testing) and contrasts with production behavior via 'Optionally deliver to subscribed endpoints.' However, it doesn't explicitly warn against production use or point to alternatives for real webhook verification.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it says almost nothing. It omits whether verification mutates domain state, whether it is idempotent, whether DNS propagation makes it async/slow, whether it can be re-run, and what permissions it requires.

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

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

A single, front-loaded sentence with no filler; the verb and the precondition arrive immediately. Nothing could be removed 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?

For a state-affecting verification tool with no annotations and no output schema, the description should explain success/failure outcomes and any propagation delay behavior. It covers only the bare purpose, leaving the agent without enough context to interpret results.

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

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

Schema description coverage is 0% and the single 'domain' parameter is undocumented. The description does not clarify whether this expects an apex domain or a sending subdomain, or the expected format, so it fails to compensate for the schema gap even though the parameter is self-evident.

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

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

The description gives a specific verb (verify), resource (DNS for a sending domain), and a temporal precondition (after records are applied), which cleanly separates it from siblings like apply_domain_dns and create_domain. It does not name the sibling tool explicitly, so it falls just short of the top score.

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 'after records are applied' implies the correct point in the workflow, which is useful sequencing guidance. However, it never states alternatives (e.g., use apply_domain_dns first), what to do if verification fails, or whether retries are needed, leaving usage only implied.

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