MepMail

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

No annotations are present, so the description carries the full burden. It does disclose one genuine behavioral constraint — the operation only succeeds before the email is sent — but omits whether cancellation is reversible, what happens if the email already went out, required permissions, and what is returned.

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 operation and its timing constraint are stated immediately.

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

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

For a one-parameter mutation with no annotations and no output schema, the description is adequate but thin: it never says what a successful call returns (e.g. the cancelled email) or how an already-sent or unknown id is handled.

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%; the single 'id' parameter is already documented as 'Email id returned by send_email'. The description adds no format, source, or lookup guidance 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 (Cancel) and resource (a scheduled email) with a temporal scope ('before it is sent'), which is more precise than the bare name. It does not, however, distinguish itself from siblings like send_email or update_email by naming an alternative or a precondition.

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 framing, no prerequisites (e.g. the email must still be in a scheduled state), and no alternatives. An agent must infer that this is the counterpart to send_email and only applies to pending mailings.

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 are empty, so the description carries the full burden. It does disclose one meaningful behavior beyond the schema: a 409 failure when the email already exists. It omits other mutation-relevant traits such as required scopes/permissions, whether creation triggers automations or welcome sends, and whether segment/topic assignment has 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?

Two sentences, zero filler, with the core create action front-loaded and the failure mode appended as a compact caveat. 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 7-parameter mutation tool with nested objects (topics, segments), no annotations, and no output schema, the description is adequate but thin: it explains what is created and one error case, but says nothing about the response, permission requirements, or the semantics of nested subscription choices.

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 71%, so the schema already documents most parameters (email uniqueness, custom properties, global unsubscribe). The description restates the segments and topics concepts but adds no format, constraint, or default information beyond what the schema provides; first_name/last_name remain undocumented.

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 ('Create') plus resource ('a contact') plus scope ('in the team audience'), with the two optional behaviors (segments, topic subscriptions) named. An agent can distinguish it immediately from siblings like update_contact, get_contact, and delete_contact.

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 'Create a contact', and the 409-on-duplicate-email note usefully signals that an existing address must be handled differently, hinting at update_contact. However, it never explicitly states when to prefer this over update_contact or what prerequisite state (e.g., an existing audience/domain) is required.

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 only flag destructiveHint=true; the description goes well beyond that by specifying what is destroyed (segment memberships), what is preserved (emails in the log), the irreversibility ('cannot be undone'), and a second, deeper destruction mode behind erase=true. That is exactly the added behavioral context the annotation 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 tight sentences, front-loaded with the core action and its side effects, then the optional destructive escalation. No filler, no repetition of 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 two-parameter destructive tool with no output schema, the description covers the cascade, the data-retention outcome, irreversibility, and the high-impact optional flag. An agent has everything needed to decide whether to call it and with which arguments.

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

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

Schema coverage is 100%, so the baseline is 3; the description raises it by framing erase=true in compliance terms (GDPR/LGPD), which tells the agent why and when that flag matters rather than just what it does. The id parameter gets no extra treatment, which is acceptable since the schema documents it fully.

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 ('Delete a contact') and immediately scopes the operation by naming the exact cascade ('its segment memberships') and the exact non-effect ('its emails stay in the log'). This is unambiguous against siblings like update_contact and create_contact.

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 clear conditional for the optional parameter — pass erase=true when GDPR/LGPD erasure of the address is required — which is real usage guidance, not just a restatement. It does not name when to prefer update_contact or a suppression-list alternative, so it falls short of explicit alternatives/exclusions.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds a view of which fields come back, but nothing about auth scope, error behavior, or freshness of the schedule/status data.

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

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

A single front-loaded sentence that names the resource first and then enumerates the payload. No filler, though it is terse enough that structure alone carries no additional routing signal.

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 and no output schema, the description adequately compensates by enumerating the returned sections. Only error/not-found behavior is left unstated.

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 id parameter is documented with a useful provenance hint ('from list_broadcasts'), which the schema already carries. The description adds no further syntax or format guidance, so baseline 3 applies.

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

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

States a specific verb (Get) and resource (broadcast) plus the contents returned (audience, content, schedule, status). It implicitly contrasts with the sibling list_broadcasts by saying 'one broadcast', but never names that sibling explicitly.

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

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

Usage is only implied: fetching a single broadcast by id. There is no statement of when to prefer this over list_broadcasts, no prerequisites, and no mention of what happens if the id is unknown or access is missing.

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?

readOnlyHint=true already establishes this as a safe read, so the bar is lower. The description adds useful disclosure about payload content ('custom properties and global unsubscribe state'), but says nothing about auth requirements, error behavior for an unknown id/email, or rate limits.

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

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

A single front-loaded sentence with the lookup key and the returned content in the right order. No filler, no repetition.

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

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

With no output schema, the description must carry the return-value burden, and it does name the notable fields returned. For a one-parameter read-only tool this is close to sufficient; missing only failure/auth context.

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

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

Schema description coverage is 100% and the schema already documents 'id' as a contact id or email address. The description's 'by id or email' restates the schema without adding format, precedence, or lookup semantics.

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 ('Get one contact') and constrains the lookup key ('by id or email'), which implicitly separates it from list_contacts. It does not name any sibling explicitly, so differentiation is inferable 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?

Usage is implied by 'one contact' versus the sibling list_contacts, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent can infer the intent but gets no routing guidance.

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

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

readOnlyHint=true already establishes the safety profile, so the bar is lower, and the description still adds real context: the 30-day lookback window, the specific metrics returned, and a caution against 'fixing' deliverability by disabling tracking or stripping content. It does not mention auth scope, freshness/staleness, or caching behavior, so it stops short of a 5.

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

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

Two sentences, front-loaded with the return contents; the second sentence is prescriptive rather than descriptive but is short and guards against a plausible misuse. Slightly off-purpose for a read-only getter, which keeps it out of 5 territory.

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

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

With no output schema, the description carries the burden of describing returns and does so (score + band, complaint rate, hard-bounce rate, guardrail status), which is the key information an agent needs. Missing only secondary details such as data freshness or how bands are defined.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies the tool needs no arguments and instead spends its words on what the fixed 30-day window returns.

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 the team's deliverability standing'), pins the scope to the trailing 30 days, and enumerates the headline contents (score with band, complaint/hard-bounce rates, guardrail status). This is enough to separate it from siblings like get_email_insights and get_usage without opening a schema.

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

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

Usage is implied by the described output, but the description never states when to call this versus get_email_insights or get_usage, and offers no exclusions or prerequisites. The remediation sentence ('Improve it by fixing per-email failures and list hygiene') is advice about acting on the result, not guidance on when to invoke the tool.

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

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

readOnlyHint=true already covers the safety profile, so the description's added value is disclosing the response payload - status, region, and the required DKIM/MAIL FROM DNS records. That tells an agent what it will actually receive, which matters since no output schema exists; it stops short of covering error behavior for an invalid or missing 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?

One sentence, verb-front-loaded, with zero filler. The return fields are listed compactly after the purpose statement.

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-resource read with no output schema, the description compensates by naming the returned fields, so an agent knows what to expect. Remaining minor gap is failure/not-found behavior, which is low stakes for a read-only lookup.

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

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

Single parameter with 100% schema description coverage; the schema already defines the UUID format and states the id comes from list_domains. The description adds no further meaning about the parameter, so baseline 3 applies.

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

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

States a specific verb and resource ('Get one sending domain') and enumerates what the record contains (status, region, DKIM/MAIL FROM records). The singular 'one sending domain' implicitly separates it from the sibling list_domains, though the sibling is never named explicitly.

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

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

Usage is only implied: retrieving a single domain by id is the obvious complement to list_domains, and the schema notes the id comes from list_domains. There is no explicit when-to-use, when-not, or named alternative in the description itself.

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

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

readOnlyHint=true already establishes the safe-read profile, so the bar is lower. The description adds genuinely useful context by enumerating the returned payload (sender, recipients, subject, body, schedule, delivery status) and the last_event state machine values (queued, sent, delivered, bounced, complained), which is valuable given there is no output schema.

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

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

One dense sentence with the verb and scope front-loaded, followed by the field list. Nothing is wasted, though the trailing "..." in the status enumeration is slightly loose.

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 appropriately covers the return shape and the delivery-status vocabulary, which is the main thing an agent needs. It is missing only edge behavior such as a not-found id, which is a minor gap for a simple single-resource getter.

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 id property is already documented as "Email id returned by send_email". The description's "by id" adds no syntax, format, or sourcing detail 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?

States a specific verb+resource ("Get one email by id") and enumerates the returned fields, so it is distinguishable from the plural list_emails. It does not explicitly differentiate itself from the close sibling get_email_insights, which keeps it out of the top band.

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 and no mention of alternatives. The agent must infer that a single-id fetch differs from list_emails or get_email_insights purely from the word "one".

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, so the safety profile is covered. The description adds real value beyond that: the report is 'computed when it was sent' (a frozen snapshot, not live), returns per-check results plus a score, and warns the score is not an inbox-placement probability — meaningful behavioral context.

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

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

Two tight sentences, front-loaded with the core action and output, followed by the disambiguating caveat. Every clause earns its place with no filler.

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

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

With no output schema, the description carries the return-value burden and does so adequately by naming per-check results and the 0-10 score and clarifying the score's meaning. It could say more about what individual checks contain, 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 coverage is 100% and the single email_id parameter is fully documented (uuid, sourced from send_email). The description adds no syntax or format meaning beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb (Get) and resource (best-practice report for one email) with the exact output (per-check results and a 0-10 score). The disclaimer that it is 'NOT an inbox-placement probability' cleanly disambiguates it from the sibling get_deliverability, so an agent can route 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?

Usage is only implied — it retrieves insights for one already-sent email. There is no explicit when-to-use statement or named alternative (e.g., when to prefer get_email vs get_deliverability), though the score clarification hints at its scope.

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?

readOnlyHint=true already declares this is a safe read, so the safety burden is covered. The description adds the set of returned fields, which is useful given there is no output schema, but omits error behavior (e.g., missing id) and any auth context.

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

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

A single, front-loaded sentence that names the action and its payload with zero filler. Nothing is wasted or 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?

For a one-parameter read tool with annotations covering the safety profile and no output schema, stating the returned fields is largely sufficient. Minor gaps (not-found behavior, usage routing) keep it from a 5.

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 id parameter is fully documented in the schema ('Template id from list_templates'). 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) and resource (template), and enumerates the returned fields (name, subject, html, variables). The 'one template' phrasing implicitly distinguishes it from list_templates, though the sibling is never named.

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

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

There is no explicit when-to-use guidance, no mention of the alternative list_templates, and no stated prerequisites. The singular 'one template' hints at lookup-by-id, but the agent must infer this.

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 readOnlyHint=true already covering the safety profile, the description adds real value by disclosing the shape of the response (plan, send limit, domain/contact limits, today's accepted count, billing period). It does not mention auth requirements, rate limits, or how quota exhaustion is represented, so it is not fully transparent.

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: purpose and usage trigger first, then a compact colon-list of returned fields. No filler and nothing 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?

With no output schema, the description carries the burden of describing the return payload and does so by enumerating the key fields. It is nearly complete, though it omits units/format nuance (e.g., whether limits are per-day or per-month) and any error or empty-state behavior.

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

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

The tool takes no parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies a parameterless, whole-team query rather than a scoped lookup.

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

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

The description names a specific resource (the team's plan and quota picture) and enumerates the concrete fields returned: effective plan, send limit, domain and contact limits, emails accepted today, and billing period. It is clearly distinct from analytics-style siblings like get_email_insights or get_deliverability, though it does not explicitly say so.

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

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

It gives a clear usage context — fetch this 'before bulk work' — which tells the agent the practical trigger for calling it. It stops short of naming alternatives or when-not-to-use conditions, so it is strong but not exhaustive.

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

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

readOnlyHint=true already establishes the safe-read profile, so the description is not the primary carrier. It adds the enumeration of possible status values, which is useful context, but says nothing about ordering, pagination behavior, or volume limits.

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

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

A single front-loaded sentence with no filler, appropriately sized for a simple list endpoint. It stops short of earning a 5 only because the status list is the sole piece of real information.

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

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

With no output schema, the description could say more about the shape of returned broadcast objects, but it does provide the status vocabulary. For a zero-required-parameter read tool with full schema coverage, this is minimally adequate rather than complete.

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

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

Schema description coverage is 100%, and the cursor/limit semantics (including the after-vs-before exclusivity) are fully documented in the schema itself. The description adds no parameter information, 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?

Specific verb (List) plus resource (broadcasts) and states what is returned (status). It implicitly distinguishes itself from get_broadcast, the singular sibling, though it never names 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?

No indication of when to use this versus get_broadcast or list_emails/list_contacts, and no note on filtering or prerequisite context. The agent must infer that this is the collection-level retrieval.

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 only declare readOnlyHint=true. The description adds genuinely non-derivable behavioral facts: results are returned oldest first, and pagination is cursor-based. It stops short of 5 because it says nothing about auth requirements, rate limits, or result volume.

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 behavior and ordering are front-loaded and the filter hint follows. Nothing is wasted.

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

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

For a read-only list tool with no output schema and full parameter coverage, the description covers scope, sort order, pagination style, and filtering. The only gap is that no return-shape guidance is given, though with no output schema that is a minor omission.

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

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

Schema description coverage is 100%, so all four parameters (after, before, limit, segment_id) are already documented, including forward/backward paging semantics and the mutual exclusion of after/before. The description's segment_id sentence restates the schema description, so the baseline 3 applies.

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

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

States a specific verb and resource ('List contacts of the team') and adds scope (team-wide) and ordering (oldest first), which cleanly separates it from get_contact and list_suppressions. It does not explicitly name or differentiate from any sibling, so it falls 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?

'Pass segment_id to list only that segment's members' hints at the optional filter, but there is no when-to-use vs when-not guidance and no named alternative (e.g., search or get_contact for a single record). Usage is implied rather than stated.

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

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

readOnlyHint=true already declares the safety profile, so the description's main added value is disclosing that each domain carries a verification status. It says nothing about pagination behavior or result ordering, which the schema partially covers via cursors.

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 resource and the returned attribute are stated immediately.

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

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

For a simple read-only enumeration tool with a fully documented schema and readOnlyHint annotation, this is nearly complete. The only shortfall is the absence of any tie-breaker against get_domain or note on paging/volume.

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 all three parameters (after, limit, before) are fully documented in the schema including mutual exclusivity of before/after. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

Clear specific verb+resource: "List the team's sending domains" with the added scope of verification status. It is distinguishable from the singular sibling get_domain by the list framing, though it never names or contrasts that sibling explicitly.

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

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

No when-to-use guidance, no prerequisites, and no mention of the sibling get_domain for fetching a single domain's details. The agent must infer that this is the bulk-enumeration counterpart.

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?

readOnlyHint=true already establishes this is a safe read, so the bar is lower. The description adds useful behavior the annotation does not: results are oldest-first and paging is cursor-based. It says nothing about default page size behavior beyond the schema, total counts, or what fields come back.

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

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

One sentence, front-loaded with the verb and resource, then scope, ordering, and pagination. Nothing is wasted and nothing important is 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?

For a read-only list tool with fully documented params and no output schema, the description covers resource scope, ordering, and paging style. Minor gaps remain around return shape and whether other filters (e.g., status, domain) are intentionally absent.

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%: after, before, and limit are all documented in the schema, including the mutual exclusivity of after/before and the 1-100 range. The description's mention of cursor pagination and oldest-first ordering reinforces the semantics but adds no syntax the schema lacks, so baseline 3 is correct.

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

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

States a specific verb (list) and resource (the team's transactional emails), plus the states included (sent, queued, scheduled). It does not distinguish itself from near-siblings such as mailbox_list_messages or list_broadcasts, 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?

The description implies when it applies (you want the team's transactional email set) and mentions ordering and pagination, but gives no explicit when-to-use versus mailbox_list_messages, list_broadcasts, or list_templates, and no exclusions.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: results are ordered oldest first, paging is cursor-based, and suppressions cause 'every send' to be skipped — a functional consequence an agent should know.

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 packs the resource, its constituents, sort order, and pagination model with zero filler. 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 read-only list tool with fully documented parameters and no output schema, the description supplies the sort order and pagination model an agent needs to page correctly. Return-value shape is not covered, but with no output schema that 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 description coverage is 100%, so all three cursor/limit parameters are already documented in the schema. The description only echoes 'cursor pagination' without adding format or constraint detail beyond what the schema provides, which is 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 (List) and resource (suppressed addresses) and immediately disambiguates what a suppression is — bounces, complaints and manual blocks. No sibling tool covers suppressions, so there is no ambiguity to resolve and an agent can act on it directly.

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

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

The description implies the usage context (viewing the send-skipped suppression list) but offers no explicit when-to-use, prerequisites, or alternatives. Since no sibling performs this function, the omission is low-cost, but it is still only implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds scope ('the team's templates') and the returned field set, but says nothing about pagination behavior despite the schema exposing cursor parameters.

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; the resource and the useful return fields are stated immediately.

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

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

For a read-only list tool whose annotations cover safety and whose schema fully documents cursor paging, the description supplies the one missing piece — the shape of each returned item. No output schema exists, and this is adequately handled.

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%: all three parameters (after, limit, before) carry their own descriptions including default, range, and mutual-exclusion note. The description adds no parameter detail, which is acceptable given 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 the team's templates') and even enumerates the returned fields, so the agent knows exactly what it gets. It does not distinguish itself from the sibling get_template, though the singular/plural naming makes the split largely self-evident.

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 by the verb 'List' — there is no explicit statement of when to use this versus get_template, nor any exclusion or prerequisite. Adequate but leaves 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?

readOnlyHint=true already declares this is a non-mutating read, so the safety profile is covered by annotations. The description contributes the returned field set, which is genuinely useful since there is no output schema, but says nothing about volume, pagination semantics, or auth/scope requirements.

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 resource and the payload contents are stated immediately and nothing is repeated from 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 simple, fully documented, read-only list tool with annotations covering safety and a complete input schema, this is nearly sufficient. The one small gap is that it never signals that results are paginated, though the schema's cursor parameters make that discoverable.

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?

All three pagination parameters are fully documented in the schema (100% coverage), including cursor direction and limit bounds, so the baseline of 3 applies. The description adds no parameter-level meaning beyond that, and none is needed.

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

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

States a specific verb (List) and resource (the team's webhooks) and even enumerates the key fields returned (endpoint, subscribed events, status), so an agent knows exactly what it gets. There is no sibling webhook tool to distinguish it from, so the only thing keeping it short of a 5 is the absence of any scoping detail (e.g., team-only vs. all).

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 explicit when-to-use statement, no prerequisites, and no mention of alternatives. For a plain list tool the usage is strongly implied by the verb, which matches the 'implied usage' bar, but the description does nothing to clarify context such as when to page versus fetch a single webhook.

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 only declare readOnlyHint=true, so the description carries the rest and does so richly: output content branches on MEPMAIL_MAIL_DOWNLOAD_DIR, saved files never overwrite, an inline override exists, a 512 KiB ceiling applies, and returned bytes are untrusted data that must not be opened or followed. This is exactly the behavioral context annotations cannot express.

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

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

Three tight sentences, front-loaded with the operation and its inputs, then return contract, then the safety caveat. Every clause carries information; nothing is padding.

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

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

With no output schema, the description must describe returns and does: filename, bytes, sha256, plus the environment-dependent saved_to vs content_base64 behavior and the size limit. Nothing needed to call or interpret the tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description genuinely adds meaning beyond it: it explains the provenance of id/revision/index and ties the environment variable to the saved_to vs content_base64 branch, which the schema only states for the inline parameter.

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

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

Starts with a specific verb+resource ('Get one attachment of a message') and immediately anchors it to the sibling that supplies the required identifiers ('the message id and revision from mailbox_read_message and the attachment's index there'). An agent can distinguish this from mailbox_read_message 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?

It tells the agent where the mandatory inputs come from (mailbox_read_message's id, revision, and attachment index) and the inline parameter's schema description covers when to force inline content. There is no explicit when-not or named alternative for attachment retrieval, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, so safety is covered, but the description adds real value by enumerating the returned fields (permissions, default, availability) in the absence of any output schema, plus the explicit 'No message content' boundary. The final `server` sentence is ambiguous but does signal connection metadata.

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 first sentence is dense and front-loaded with useful field information, but the closing sentence about `server` naming the connection's tool set is cryptic and references a non-existent parameter, weakening an otherwise tight description.

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

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

With no output schema, the description usefully documents the return fields an agent needs. The only gap is the unexplained `server` reference, which leaves ambiguity about whether it is an input, output, or internal detail.

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

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

The tool takes zero parameters, so the baseline is 4. The trailing mention of `server` is confusing since no such parameter exists, but there is no parameter semantics gap to compensate for.

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 (mailboxes/accounts) and enumerates exactly what is returned: address, label, kind, permissions, default flag, availability. The clause 'No message content' cleanly separates it from sibling tools like mailbox_list_messages.

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 mailboxes this credential can use' implies the discovery use case, and 'No message content' hints the agent should go to mailbox_list_messages for content, but no alternative is named and no explicit when/when-not guidance is given.

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 only assert readOnlyHint, so the description carries the rest and does so well: quarantined messages never appear, blocked content is withheld, cursors are bound to one listing, search results come from an index that may lag ~1 minute, and search pages cap at 50. It even flags third-party content as untrusted data rather than instructions.

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

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

Front-loaded correctly – purpose, then item shape, then paging, then filter semantics, then caveats. It is a dense single block of roughly 200 words, and the filter-operator enumeration sits mid-paragraph rather than in a scannable list, but nearly every sentence carries non-obvious behavior, so little is wasted.

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

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

With 10 optional parameters, no output schema and only a readOnlyHint annotation, the description compensates fully: it documents the returned item fields, paging contract, index staleness, search page limits, quarantine behavior and prompt-injection handling. An agent has everything needed to call and consume this tool correctly.

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

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

Schema coverage is 100%, yet the description still adds real semantics: the actual query operators (de:/from:, para:/to:, assunto:/subject:, tem:anexo, depois:/antes:) that the schema only alludes to as 'operators', and the fact that filters run server-side before the page is cut. It does duplicate the schema's own limit defaults/caps, so it is not fully additive.

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

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

Opens with a specific verb+resource+scope: 'List or search one page of messages in a mailbox (inbox, drafts or sent), newest first.' The mailbox/folder/paged framing distinguishes it from siblings like list_emails (outbound) and mailbox_read_message (single message), and the return fields are enumerated immediately.

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

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

Gives explicit operational rules: pass nextCursor as `cursor` with the same mailbox/folder/filters until hasMore is false, a foreign cursor is refused, and restart without a cursor to pick up newly arrived mail. It also states the negative case – a short or empty page does not prove absence, widen filters before concluding – which is exactly the when-not guidance most tools omit.

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, so the safety profile is covered. The description goes beyond that by disclosing the shape of the response (headers, text, revision, attachment index/filename/bytes) and by warning that message text is untrusted third-party data that must not be treated as instructions — genuinely useful context a schema cannot convey.

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

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

Three sentences, front-loaded with the core read action, then the attachment route, then the safety caveat. Every sentence earns its place, though the final security sentence is long and could be tightened slightly.

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

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

With no output schema, the description compensates by enumerating the returned fields, and it covers the credential/multi-mailbox nuance of the optional mailbox parameter. The only minor gap is that it says nothing about size limits or truncation of large messages.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema: it ties 'id' to its origin in mailbox_list_messages and adds the 'same mailbox' constraint linking id and mailbox, which is not stated in either parameter 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?

States a specific verb and resource ('Read one message by id') plus the exact payload returned: headers, text, revision, and attachment metadata. It also names where the id comes from (mailbox_list_messages) and routes attachment bodies elsewhere, so it is clearly distinguishable from siblings like mailbox_list_messages and mailbox_get_attachment.

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

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

Explicitly names the prerequisite source of the id ('from mailbox_list_messages, in the same mailbox') and the alternative for attachment content ('Get an attachment's content with mailbox_get_attachment'). It gives clear context and one alternative but no explicit when-not condition, so it falls just short of a 5.

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

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

Annotations only say idempotentHint=false and destructiveHint=false; the description adds substantial context beyond that: the mailbox signature is appended once, the body is formatted, a stale revision is refused and must be re-read, attachment index retention defaults differ between edit/forward (keep all) and reply (keep none), and hard limits are given (10 files, 256 KiB each, ~700 KiB total). This is exactly the behavioral detail an agent needs.

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

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

Dense but front-loaded: purpose first, then editing/revision rules, then reply/forward, then attachments, then limits. Every clause carries information, though the run-on paragraph is heavier than it needs to be and the phrase 'the message also goes out formatted' is slightly ambiguous.

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 mutation tool with no output schema, the description covers the create-vs-edit lifecycle, revision conflict handling, reply/forward derivation, attachment retention, and resource limits. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is already 100%, so baseline is 3, but the description earns above that by supplying the retention default for keep_attachments (not in the schema), the two attachment input forms, and the size/count limits. It leaves cc/bcc and subject semantics to the schema, which is reasonable.

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 precise verb and resource ('Create or update a plain-text draft in a mailbox') plus the critical qualifier 'without sending it', which cleanly separates it from the sibling mailbox_send_draft. An agent can pick this tool without opening the schema.

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

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

Gives explicit conditions for the two modes: expected_revision 0 for new drafts, id plus current revision for edits, and source_item_id with mode reply/forward for answering or passing on a message. It stops short of naming mailbox_send_draft as the alternative for actually sending, though 'without sending it' implies the boundary.

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

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

Annotations only flag idempotentHint and destructiveHint, but the description goes much further: the approval-fallback flow, the fact that sending cannot be undone, that a submitted draft can no longer be edited, and that repeating the same id+revision returns the existing send status instead of re-sending. It even explains that 'queued is not delivered' and where to check the real outcome.

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?

It is dense and slightly long, but front-loaded with the core action and every clause carries information (permission branch, irreversibility, idempotency, status values, next step). No filler sentences, though the status enumeration could be trimmed.

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

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

There is no output schema, and the description compensates by enumerating the possible send statuses (queued, sending, accepted, unknown, failed) and pointing to the draft/Sent folder for the delivery outcome. Combined with the approval flow and idempotency guarantees, an agent has everything needed to invoke and interpret this tool.

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

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

Schema coverage is 100%, so the schema already documents id, mailbox and expected_revision, making 3 the baseline. The description adds genuine meaning by framing expected_revision as an optimistic-concurrency pin ('exactly as it is at the given revision') and by explaining that id+revision together form the idempotency key.

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 precise verb+resource: sending an already-saved draft pinned to a revision. It clearly distinguishes this from sending a new message by tying it to drafts produced by mailbox_save_draft or mailbox_list_messages, so an agent can tell it apart from send_email/send_email_batch.

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 clear conditioning: with the send permission it goes out immediately, otherwise it becomes an approval request and the owner is emailed. It also tells the agent what to do on repeat calls. It never explicitly contrasts with send_email or send_email_batch, so the alternatives routing is implied rather than stated.

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

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

With no annotations present, the description carries the full behavioral burden and does disclose real traits the schema does not: suppressed and topic-opted-out recipients are silently skipped, and the call returns the email id. It still omits permission/domain verification requirements, error/partial-failure behavior, and rate limits, so it is not complete.

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

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

Three short sentences, front-loaded with the core action, and each sentence carries a distinct fact (what it does, suppression behavior, return value). 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 14-parameter write tool with no annotations it is only partially complete; noting the returned email id usefully compensates for the missing output schema, and the suppression rule is valuable, but constraints such as html/text being required together, domain verification, and 30-day scheduling limits are left entirely to the schema.

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

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

Schema coverage is 71%, so the schema already documents most parameters (notably the detailed idempotency_key and scheduled_at semantics). The description adds only the high-level meaning of scheduled_at; undocumented params like tags, headers, and attachment fields get no help from it. Baseline 3 is appropriate.

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

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

Clear specific verb+resource ('Send a transactional email') with an explicit secondary mode ('or schedule it with scheduled_at'). However it does not distinguish itself from the very similar sibling send_email_batch, leaving the agent to infer the single-vs-batch boundary.

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

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

It hints at scheduling usage via scheduled_at and implies the normal immediate-send path, but gives no when-to-use/when-not guidance and never names the alternative tools (send_email_batch for multiple sends, cancel_email to undo a scheduled one). Usage is implied rather than stated.

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

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

With no annotations, the description carries full behavioral burden. It does add real value: 'one id per accepted email' implies non-atomic partial success, and the 100-item ceiling is stated. But it says nothing about rate limits, permission/domain verification requirements, or what happens to entries that are not accepted.

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 clauses with no filler; the batch cap and the send_email shape reference are front-loaded. 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?

There is no output schema and no annotations, so the description is the only source for return behavior, and it gives just one clause ('one id per accepted email'). For a batch send operation, missing details about partial failures, error reporting per entry, and delivery semantics leave the agent under-informed despite the rich input schema.

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

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

Schema description coverage is 100% and the two top-level parameters are thoroughly documented there, including the idempotency-key semantics (409 on reuse with a different payload). The description adds only the cross-reference to send_email's entry shape, so the baseline 3 is appropriate.

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

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

States a specific verb and resource (send emails) plus batch scope (up to 100 in one call) and ties the entry shape to the send_email sibling. It distinguishes the batch case implicitly, but never explicitly says to prefer this over send_email for multiple sends, so sibling routing is left to 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 'up to 100 emails in one call' phrasing implies when this tool is appropriate (bulk sending), but there is no explicit when-to-use/when-not guidance, no threshold telling an agent to use send_email for a single message, and no prerequisites or limits on concurrent batches.

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 supplied, so the description carries the full behavioral burden. It does disclose a genuinely useful trait the schema does not frame explicitly: omitted fields are left unchanged (patch semantics), and that unsubscribed is a global flag rather than a per-broadcast suppression. It stops short of permissions, idempotency, behavior when the id does not resolve, 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 sentences, no filler. The primary purpose leads and the patch-semantics caveat follows immediately, which is exactly the ordering an agent needs before deciding to call it.

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

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

For a mutation tool with zero annotations, no output schema, and a nested arbitrary-key properties object, the description covers the core contract but leaves real gaps: no auth/permission expectations, no error behavior, no note on whether clearing fields is reversible, and nothing about what is returned. Adequate but clearly under-specified for the complexity of the operation.

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 80%, so the schema already explains id, first_name/last_name (null clears) and properties (merged; null removes a key), putting the baseline at 3. The description adds a little meaning by calling out the unsubscribe flag as 'global' and by summarizing the field groups, but it provides no format or syntax guidance for the custom properties map, and the unsubscribed parameter has no schema description of its own that the text compensates for in detail.

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

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

The description names a specific verb and resource (update a contact) and enumerates the mutable field groups: name, custom properties, and the global unsubscribe flag. That is enough to distinguish it from list_contacts/get_contact/delete_contact, though it never explicitly names a sibling or a boundary case to reinforce the distinction.

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

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

Usage is only implied: an agent can infer this is the tool for modifying an existing contact rather than creating one, and the patch-oriented phrasing hints that partial updates are the expected mode. There is no explicit when-to-use statement, no mention of prerequisites (the contact must already exist), and no routing to alternatives such as create_contact or delete_contact.

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 are empty, so the description carries the full burden. It states only that the email must be unsent, but does not disclose what happens if the email was already sent, whether the previous schedule is replaced, what authorization is needed, or what the operation returns. This is a significant gap for a mutation tool with no annotations.

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

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

A single front-loaded sentence with no filler. Every word earns its place and the key action and constraint are clear immediately.

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

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

For a simple two-parameter mutation with rich schema coverage, the description states the core action and precondition. However, with no annotations and no output schema, it still leaves gaps around error behavior, side effects, and return values, making it only adequately complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, including the id source and the scheduled_at format. The description adds no parameter meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb, 'Reschedule', on a specific resource, 'a scheduled email', and scopes it with 'that has not been sent yet'. This clearly distinguishes the tool from send_email and cancel_email by state and action.

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

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

It implies usage by stating the email must be scheduled and unsent, which is a precondition. However, it never names alternatives like cancel_email or send_email, nor says when not to use this tool. Usage is therefore only implied.

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