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

Annotations already cover the safety profile (write, non-idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: the response carries the DNS records to create and a verification step is required afterward. It omits failure behavior for duplicate domains or invalid input, so it stops short of full disclosure.

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, front-loaded with the action and followed by the one piece of information an agent could not infer. Nothing is redundant.

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

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

For a one-parameter creation tool with annotations and no output schema, the description covers the essential gap: what comes back and what to do next. A note on duplicate-domain behavior would make it fully 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?

There is a single parameter with 100% schema description coverage including an example format, so the schema already does the work. The description adds no further meaning about expected domain format, 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 opens with a specific verb+resource ('Add a sending domain'), which is unambiguous against siblings like list_domains, get_domain, and verify_domain. It does not explicitly say which sibling to use instead, but the operation is distinct enough that confusion is unlikely.

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 supplies real workflow context: the caller must create the returned DNS records before calling verify_domain, which tells the agent where this step fits. There are no explicit when-not conditions, for example what to do if the domain already exists.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the failure mode and error identifier (cannot_cancel) and the state transition that triggers it, which is exactly the kind of context annotations cannot carry.

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

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

Two short sentences, front-loaded with the action and followed by the failure condition. No filler, no repetition of the title.

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

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

For a single-parameter mutation with no output schema and full annotation coverage, the definition supplies the essential precondition and error behavior. It could add whether a successful cancellation is reversible or whether the sender is notified, but nothing critical for correct invocation is missing.

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

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

Only one parameter, and the schema documents it at 100% coverage with format hint (msg_…). The description adds nothing about the id, so the baseline of 3 applies — the schema does all the work here.

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

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

Specific verb+resource ("Cancel a queued or scheduled email") with a scoping constraint ("before it is sent") that implicitly separates it from send_email and the read siblings. It stops short of naming an alternative explicitly, so it is clear but not fully sibling-differentiated.

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

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

Gives a concrete precondition and a when-not condition: fails with cannot_cancel once delivery has started. That tells an agent when the call is valid and when it will not work, though it does not point to any alternative tool for already-sent mail.

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 write (readOnlyHint=false), non-idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral convention beyond that — the {{ name }} placeholder syntax used inside template bodies — but says nothing about whether names must be unique, what happens on duplicate names, or what the created template must contain.

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 no filler and the core purpose front-loaded. Nothing is wasted, though the terse phrasing leaves the description doing very little work overall.

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 five-parameter mutation tool with no output schema needs more than two sentences: an agent is not told that a body field is effectively required, whether the template name is a unique identifier, or that the returned template id is what must later be passed to send_email's template_id. The key lifecycle detail motivating the tool is stated, but the contract for calling it correctly is not.

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 40% — name, html_template and text_template are completely undocumented in the schema, while variables and subject_template are described. The placeholder convention helps interpret subject_template/html_template/text_template, but the description does not say which body field is required, how `variables` relates to the placeholders actually appearing in the bodies, or that the placeholder example uses a variable literally called "name", which collides with the required `name` parameter and can mislead.

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

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

Specific verb+resource ("Create a template") plus a downstream consumer ("send with send_email's template_id"), which tells an agent exactly what this produces and how it gets used. It is clearly distinct from update_template/delete_template by verb, though it never names those siblings 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?

"to send with send_email's template_id" implies the situation that motivates using this tool, but there is no when-not guidance (e.g. don't create a template for a one-off send, use send_email body fields directly) and no mention of prerequisites such as needing an html_template or text_template body.

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 destructiveHint=true and idempotentHint=true. The description adds valuable domain-specific consequence by noting that emails using the template ID can no longer be sent, which goes beyond the annotation's generic destructive 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 two short sentences with no wasted words. The core action is front-loaded, followed immediately by the key consequence.

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 delete tool with complete schema coverage and explicit destructive/idempotent annotations, the description provides sufficient context by stating the main side effect. No output schema exists, so return values need not be explained.

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

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

The schema has 100% description coverage for the single id parameter. The description does not add further meaning about the template ID format or constraints, so it meets the baseline without exceeding 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?

The description uses a specific verb and resource: 'Delete a template.' It is clearly distinct from sibling tools like update_template, get_template, and create_template.

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

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

Usage is implied by the verb 'Delete,' but the description does not explicitly state when to use this tool versus alternatives or when not to use it. It also does not mention confirmation or alternative actions for handling templates.

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 openWorldHint=false, so safety is covered. The description usefully adds that the response includes the DNS records the domain needs and a found/not-found indicator per record, which is real behavioral context. It says nothing about behavior for a nonexistent or unverified domain id, which is the main gap.

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 tightly written sentence with no filler, and the core outcome (domain plus DNS records with found status) is front-loaded. It is efficient, though very sparse for a tool that returns a compound payload.

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

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

With no output schema, the description must hint at the return shape, and it does at a high level (DNS records + found flags). It omits error behavior (unknown id), record ordering, and whether the domain object's other fields are returned, leaving the agent to discover these at call time.

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

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

There is a single required parameter and the schema documents it fully (100% coverage) with the 'dom_…' id format, so the description carries no param burden. It does not repeat or extend parameter meaning, which is acceptable at this coverage level but adds no 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 and resource ('Get one domain') and adds what comes back (DNS records plus per-record found status). This distinguishes it from list_domains, which the description implicitly contrasts with by specifying 'one domain'. It stops short of naming siblings explicitly, so it is strong but not maximally differentiated.

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 'Get one domain' implies single-record lookup usage versus list_domains, but no when-to-use/when-not-to-use guidance or alternative is stated. An agent can infer the case (it needs details for one known domain id), but nothing routes it away from other tools like verify_domain.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by disclosing the returned payload — delivery status and lifecycle events (sent, delivered, opened, bounced) — which is the main unknown for a read tool with no output schema. It stops short of saying what happens on a missing/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?

A single sentence with no filler, and the returned-payload detail is packed into a parenthetical instead of a second sentence. Every clause 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 one-parameter read tool with annotations covering safety, the description covers purpose and return content adequately. Only edge behavior (not found, invalid ID) is unaddressed, a minor gap given the low 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?

Only one parameter and schema coverage is 100%, so the schema already documents the 'msg_…' ID format. The description's 'one sent email' only restates that a single identifier is expected, adding no format or constraint detail beyond the schema. Baseline 3 applies.

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

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

Specific verb plus resource ('Get one sent email') and it names the payload (status and events), which separates it from list_emails and get_inbound by implication. It never names a sibling explicitly, so differentiation is inferred from 'one sent email' rather than stated.

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?

Retrieval of a single email by ID is implied by 'one sent email', and the sent-only scope subtly distinguishes it from get_inbound. But there is no explicit when-to-use, no exclusion (e.g., use list_emails for enumeration), and no mention of what to do if the ID is unknown.

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 openWorldHint=false, so the safety profile is covered. The description usefully discloses that authentication results (SPF/DKIM/DMARC) are included, which is behavioral value annotations cannot convey, but it says nothing about not-found/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?

A single front-loaded sentence that lists exactly what the caller receives; every clause earns its place and nothing is padded.

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

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

With no output schema, the description does the necessary work of naming the returned fields, which is the key gap it needs to fill for a one-parameter read tool. Minor gap: no mention of behavior when the id is unknown or the email is unavailable.

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

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

Schema coverage is 100% and the single 'id' parameter is already documented as an inbound email ID with the 'inb_…' prefix. The description adds no further parameter meaning, 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?

States a specific verb ('Get one') and resource ('received email') and enumerates what comes back: headers, content, attachments list, and SPF/DKIM/DMARC results. It is clear what it does, but it never differentiates itself from sibling get_email, so an agent cannot tell which of the two fetches inbound mail without inspecting 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 word 'received' implies this is the inbound counterpart to get_email, and the sibling list_inbound implies this is the single-item fetcher. However, no explicit when-to-use guidance or alternative (get_email vs. list_inbound) is named, leaving routing to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful value by disclosing which fields come back (subject, HTML, text) since there is no output schema, but says nothing about behavior when the id does not exist or about field nullability.

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 short sentence with the returned fields front-loaded and zero filler. 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 single-parameter read-only tool with full schema coverage, the description plus annotations give an agent enough to call it correctly and know roughly what comes back. Only error/not-found behavior is left unspecified, a minor gap without 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 coverage is 100% and the single parameter already documents the 'tmpl_…' format, so the schema does the heavy lifting. The description adds no meaning beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Get one template') and names the fields returned (subject, HTML, text), which distinguishes it from list_templates and get_email by scope and content. It stops short of explicitly naming a sibling to contrast with, so it lands at 4 rather than 5.

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

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

'Get one' implies retrieval of a single known template, which implicitly distinguishes it from list_templates, but the description never states when to use it versus that sibling or how to obtain the required id. Usage is inferred rather than instructed.

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 openWorldHint=false, so the safety profile is covered. The description adds useful scoping detail — workspace-scoped domains and verification status — but does not discuss pagination behavior or result completeness beyond what the schema provides.

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

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

A single, front-loaded sentence that states the resource and the additional returned attribute 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?

For a simple read-only list tool with complete schema documentation and safety annotations, the description supplies the essential purpose and scope. It could mention pagination defaults or return shape, but the schema already covers pagination parameters and no output schema is present.

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

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

Schema description coverage is 100%, so limit and offset are fully documented by the schema itself. The description adds no parameter semantics beyond that baseline, which is appropriate but not enriching.

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 ("List") and resource ("the workspace's sending domains") and adds the verification-status detail. It does not explicitly distinguish itself from siblings like get_domain or verify_domain, but the plural/list framing is clear enough for an agent to differentiate it.

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

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

Usage is implied by "List the workspace's sending domains," suggesting it is the bulk-retrieval tool for domains. There is no explicit guidance on when to use it versus get_domain for a single domain, nor any exclusion or prerequisite stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a genuinely useful default ('newest first') not present in schema or annotations, but says nothing about pagination behavior, result volume, or what happens when no filters are supplied.

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

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

One front-loaded sentence with the verb, scope, default ordering, and filter surface — no filler and nothing buried.

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

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

Adequate for a simple read-only list tool with annotations covering safety, but for a six-parameter paginated endpoint with no output schema, an agent gets no sense of what a page contains beyond 'emails' or how many to expect. Some gaps remain around pagination and returned fields.

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 67% and the description restates four of six parameters (status, q, source, days) without adding format or interaction detail. Pagination parameters limit/offset are left entirely to the schema, so the description neither compensates for the gap nor adds meaning beyond structured fields.

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

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

States a specific verb ('List') and resource ('sent emails'), plus the default ordering ('newest first'). That scope already separates it from get_email (single item) and list_inbound (inbound), though it never names those siblings explicitly and 'sent emails' is mildly ambiguous against the 'sent' status enum value.

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 filters imply when the tool is appropriate (browse/filter outbound mail), but there is no explicit when-to-use versus get_email/list_inbound guidance and no stated exclusions or prerequisites. Usage must be inferred from the filter list.

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 openWorldHint=false, so the safety profile is covered. The description adds ordering ('newest first'), which is genuine behavioral context, but says nothing about result caps, pagination behavior, or whether results are scoped per authenticated workspace beyond the phrase 'workspace's inbound domains'.

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 resource, its scope, and the sort order with no filler. Every clause carries information an agent needs.

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

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

For a simple read-only list tool with a fully documented 3-parameter schema, the description covers what is listed and in what order. The only gap is that no output schema exists and the description doesn't characterize what each returned item contains, but that is a minor omission for a listing endpoint.

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 q, limit, and offset are fully documented in the schema, setting the baseline at 3. The description adds no extra meaning about how q interacts with ordering or what the paging semantics are beyond what the schema already says.

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 (email received on the workspace's inbound domains), plus ordering (newest first). It implicitly contrasts with get_inbound (single item) and list_emails (outbound), but never names those siblings, so the differentiation requires inference.

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

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

The scope phrase 'received on the workspace's inbound domains' implies when this applies, and the sibling get_inbound suggests single-item retrieval, but there is no explicit when-to-use versus list_emails or get_inbound, and no exclusions or prerequisites stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds nothing beyond that — no ordering, no scope of what 'stored' means (all templates? account-wide?), and no hint about whether results are paginated beyond what the schema already states.

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 wasted words. It is efficient, though its brevity borders on under-specification rather than optimal 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 paginated list with full schema coverage and read-only annotations, this is minimally adequate. It leaves gaps around scope and ordering that an agent might want, but nothing critical to invoking it correctly is missing.

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

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

Schema description coverage is 100%, with both limit and offset fully documented including defaults and maximums. The description adds no parameter meaning, which is acceptable at this coverage level.

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

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

States a specific verb and resource ('List stored email templates'), so the agent can tell it retrieves a collection rather than a single template. It does not differentiate from siblings such as get_template or list_emails, but the purpose itself 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 indication of when to use this versus get_template (single retrieval) or how it relates to create/update/delete. 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?

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=true. The description adds the most important non-annotation behavior: all-or-nothing atomicity, so one rejection cancels the whole batch, plus the 100-recipient ceiling. It does not cover rate limits, retry semantics, or what a caller can do about a partial rejection, keeping it below a 5.

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

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

Two sentences, zero waste, with the scope constraint front-loaded ahead of the atomicity caveat. Nothing repeats the title or the schema.

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

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

For a 6-parameter mutation tool with no output schema, the description covers the critical atomicity and size limit but omits how the caller learns which recipients succeeded/failed, whether sends can be scheduled or cancelled via cancel_email, and any auth/verification preconditions. 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 coverage is only 50% and the description adds no meaning beyond the schema — 'per-recipient variables' is already documented on the batch/variables fields. The undocumented parameters (html, text, template_id) are left entirely to the schema, and the description never clarifies the subject-vs-template_id relationship.

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) and resource (batch email) with concrete scope: 'up to 100 recipients, one email each, with per-recipient variables.' An agent can immediately distinguish this from send_email (single send) without opening either schema.

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

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

Usage is only implied — the 100-recipient / one-email-each framing suggests when batch sending applies, but the description never names send_email as the alternative for single sends or states prerequisites (e.g., verified domain on a live key). No explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the write-and-external-effect profile is covered structurally. The description adds genuinely new behavior: a ps_test_ key accepts and reports the email without delivering it, which an agent could not learn from the annotations. It omits any mention of rate limits or what happens on partial failure, keeping it below 5.

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

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

Three short sentences, each carrying distinct information: the action, the content-mode rule, and the test-key behavior. The most decision-relevant content (what it does) is front-loaded with zero 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 12-parameter, no-output-schema mutation tool, the description covers the core invocation shape but omits two things an agent needs: what the call returns (presumably an email id, since get_email and cancel_email are siblings) and how scheduling interacts with idempotency_key. Adequate to call correctly in the common case, incomplete for scheduling or retry workflows.

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 a middling 58%, and the description compensates by explaining the conditional relationship between subject, html/text, template_id, and variables — the single most important semantic an agent needs to build a valid call, and one the flat schema cannot express. It says nothing about cc/bcc/reply_to or scheduled_at, leaving roughly half the surface to the schema.

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

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

States a specific verb and resource ("Send one email through Postilon"), and the word "one" implicitly separates it from the sibling send_batch. It does not explicitly name send_batch or explain how this differs from scheduling via scheduled_at, so sibling differentiation is present but implicit rather than stated.

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 the two mutually exclusive content modes ("subject with html and/or text, or a template_id with variables") and notes the ps_test_ key path, which is real usage context. However it never states when to reach for this tool over send_batch, nor any prerequisites such as verified sender domains or rate limits, so the agent must infer routing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description usefully adds that this is a partial/PATCH-style update where omitted fields retain current values. However, it does not say what 'destructive' actually means here (existing subject/HTML/text content being overwritten, effect on in-flight sends) or whether variables must match placeholders.

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, verb-first, with the most decision-relevant fact (partial update) up front. No filler, though it is under-specified rather than over-long.

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 mutation with no output schema and only 50% parameter coverage, the description covers partial-update semantics but omits overwrite consequences, permission requirements, and interaction between variables and template placeholders. Adequate minimum, clear gaps remain.

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 50%, with name, html_template and text_template undocumented in both schema and description. The description compensates partly by explaining that all non-id parameters are optional and leave values untouched when omitted, which clarifies mutability semantics for the six parameters.

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 ('Change a template'), which is distinguishable from create_template, get_template and delete_template in the sibling list. It does not explicitly name those siblings, so differentiation relies on the reader inferring from the name.

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 create_template or get_template, and no prerequisite or permission context. The only usage-adjacent statement is the patch semantics of omitted fields, which is behavioral rather than routing guidance.

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

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

The annotations already declare non-read-only, idempotent, non-destructive, and open-world. The description usefully adds that the mutation is conditional (verified only once required records are found), which the annotations do not convey. However it omits what happens on failure, whether verification can be revoked, and whether the DNS lookup is live/network-dependent (only implied by the annotation).

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 well-formed sentence with the action and the outcome condition 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?

There is no output schema, so the description should say what the call returns or what happens when records are missing/mismatched. It covers the happy path only, leaving the agent guessing on failure and retry semantics.

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

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

One parameter with 100% schema coverage, so the schema already documents the dom_… ID format. The description says nothing about the id, which is acceptable at this coverage level but adds no 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 pair (check DNS records, mark verified) on a specific resource (domain), which is clearly distinguishable from siblings like get_domain, add_domain, and list_domains. It stops short of naming an alternative, 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?

"Now" implies this is the on-demand trigger for a verification flow, but the description never says when to call it versus the passive alternatives (get_domain, list_domains) or whether it should be retried after DNS propagation. Usage must be inferred.

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