email59

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the suppression effect (campaigns will skip the address) and the all-lists default, which is more than the schema says, but it omits idempotency, error behavior on already-unsubscribed addresses, and any auth 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?

Two short sentences, zero filler, with the primary action stated first and the scoping rule immediately after. 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 two-parameter write tool with no output schema, the description covers the essential effect and default scope. It falls short only on operational details (repeat calls, error cases) that an agent might want before mutating state.

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 both parameters are documented there, so baseline is 3. The description restates the list_id empty-means-every-list semantics already captured in the schema, adding no new syntax or format 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?

States a specific action and resource: recording an opt-out for an address, plus its downstream effect on campaigns. It is clear what the tool does, though it never distinguishes itself from neighbor tools like block or list_blocklist, which an agent must infer are different mechanisms.

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 prerequisites, and no comparison against siblings such as block/unblock or list_blocklist. The list_id default behavior hints at scope but is not framed as routing advice.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the signup side effect and its consequence ('a new email is signed up with 200 free emails a day'), states that a session key is the return value, and documents how to use it ('Authorization: Bearer <session_key>'). It omits key lifetime, invalidation, and failure behavior for a bad OTP.

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 purpose, then the two auth flows, then the downstream header usage. No filler and no repetition of the name.

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

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

No output schema exists, so the description correctly states the returned session key and the signup side effect, and all three params are optional so the alternative flows account for that. It stops short of error cases (invalid/expired OTP) and session key lifetime, which an auth tool arguably should mention.

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

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

Schema coverage is 100%, so per-parameter text is already covered, but the description adds cross-parameter semantics the schema cannot express: email alone triggers an OTP send, email+otp yields a session key, and api_key is a mutually exclusive alternative. That mapping is genuinely additive beyond the individual property descriptions.

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 ('Sign up or sign in to email59') and spells out the two concrete paths: email → OTP → session key, or API key swap. It is instantly distinguishable from adjacent siblings like create_api_key (which issues keys rather than exchanging one) and the many send/check tools.

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

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

It gives an explicit call sequence ('Pass email to have a 6-digit code emailed, then call again with email and otp') and names the alternative path (api_key). What is missing is explicit guidance about which path to choose when both are available, or when not to use this 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?

With no annotations, the description carries the full burden, and it does disclose one genuine behavioral trait: 'Sends to it are refused.' It omits reversibility (unblock exists), whether re-blocking an already-blocked address errors, permission requirements, and the response shape.

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, no filler, with the core action and its effect front-loaded. 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 mutation tool with no annotations, no output schema, and an undocumented 'reason' parameter, the description leaves too much open: no error behavior, no confirmation of what changes, and no pointer to unblock as the inverse. It covers the happy-path action only.

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

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

Schema description coverage is only 33%: 'kind' relies on its enum and 'reason' is entirely undocumented in both schema and description. The description's 'email address or a whole domain' merely restates the enum values and adds nothing about what 'reason' is for or how it is surfaced.

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 ('Block') and resource ('email address or a whole domain') with the scope 'for this account'. An agent can distinguish it from list_blocklist and unblock by the verb alone, though the description never names those siblings to make the routing explicit.

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 block versus alternatives such as add_unsubscribe or check_email, and no prerequisites (e.g., whether the address must be validated first). Usage is only inferable from the tool name and the sibling set.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the return value (checkout_url), the delayed credit delivery ('credits arrive once the payment clears'), the non-renewing nature of credits, and the 5%/$0.50 minimum purchase fee. It does not cover retry/idempotency behavior or what happens if payment never clears, which keeps it 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?

The opening clause front-loads purpose and pricing, and the remaining clauses cover output, payment timing, and prerequisites in order. The nested parentheticals are dense, but 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 no-annotation, no-output-schema purchase tool, the description supplies price tiers, fee logic, the return shape (checkout_url), and the consent prerequisite. What is missing is failure/repeat-call behavior and how the resulting checkout relates to order_status.

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 pack_id has no schema description at all, so the description's enumeration of pack_5/pack_10/pack_50 with prices is genuinely required to use that parameter. It also contextualizes agree and policy_version as gating consent values obtained from GET /v1/policy, adding workflow meaning beyond the terse schema descriptions.

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 ('Start buying a pack') and immediately enumerates the exact pack IDs and their dollar values, so an agent knows precisely what this tool sells and at what price. It is clearly distinguishable from sibling reads like get_pricing or order_status.

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 precondition workflow: show the refund policy/terms from GET /v1/policy first, then pass agree=true and the returned version only after consent. It even points to GET /v1/pricing for totals rather than doing that math itself. What it lacks is explicit guidance on when this tool should not be used or how it relates to order_status for subsequent tracking.

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

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

With no annotations, the description carries the full burden and does well: it declares the operation is free, requires no sign-in, sends no email (non-destructive), and notes that big providers skip DNS so results vary by domain. It omits rate limits and any auth/quota caveats, but the behavioral profile is unusually complete for an annotation-free tool.

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

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

Front-loaded with the core action and free/no-sign-in qualifier, then the capability list, then the return shape. The long DNS record enumeration is dense but informative; a slightly tighter grouping would be ideal.

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

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

There is no output schema, so the description compensates by describing the return report: a 0-99 score and a verdict with named enum-like values (likely_valid, risky, likely_invalid, unknown). The single parameter is fully covered; only edge-case behavior (errors, rate limits) is unaddressed.

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 required parameter at 100% schema coverage, which is the stated baseline of 3. The description adds no format or syntax guidance beyond the schema's 'Email address.', though none is really needed for a self-evident single string input.

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 ('check of an email address') and then enumerates the exact checks performed (format, provider rules, disposable/role detection, MX, SPF, DMARC, DKIM, MTA-STS, TLS-RPT, BIMI). That enumerated depth implicitly separates it from shallower siblings like validate_email or verify_check, so an agent can route correctly.

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 'free, no sign-in needed' framing gives context for choosing it over paid/auth-gated siblings, and 'no email is sent' hints at the non-intrusive path. However, it never explicitly names when to prefer validate_email or verify_start, so selection is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden and does well: it discloses that no email is sent, that each domain gets exactly one MX lookup, that provider rules and format checks apply, and that a daily per-account quota limits usage with the remainder reported in the response. It omits auth/permission requirements, which is the main remaining 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?

A single dense sentence that front-loads the core purpose and then packs quota, status values, and request mechanics without filler. It is run-on and could be segmented for scannability, but essentially every clause carries 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 and no annotations, the description steps up by enumerating the six possible statuses, mentioning a per-result reason, and describing counts per status plus remaining quota. Combined with the input forms and the 1,000-address ceiling, an agent has enough to call it correctly; only permissions/auth context 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 the 3 baseline applies, but the description adds real semantics beyond the schema: the CSV variant must contain a column headed 'email', and the two params are alternative input channels ('as emails or the text of a CSV'). That is meaningful clarification of format expectations.

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 check for a mailing list') plus an explicit scale limit ('up to 1,000 different addresses a call'), so the bulk-checking intent is unambiguous. It does not, however, distinguish itself from near-identical siblings like check_email, validate_email, or verify_check, leaving the agent to infer that this is the batch variant.

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 1,000-address scope and the accepted input forms, but there is no explicit when-to-use/when-not statement and no routing to the single-address siblings (check_email, validate_email, verify_check). An agent with many verification tools in its list gets no stated rule for picking this 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?

With no annotations, the description carries the full burden and does well: it discloses the one-time visibility of the secret, the per-account quota of 10, and the non-obvious behavior of test keys (sends accepted and stored, never delivered, no allowance consumed). It omits what happens when the quota is exceeded and whether the live key requires prior verification.

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 with no filler; the core action and its quota are front-loaded, and the mode-specific caveat follows. Every clause carries information the agent cannot get 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 two-parameter tool with no output schema and no annotations, the description covers the critical agent-facing facts: quota, one-time display of the secret, and divergent test-mode semantics. The main residual gap is the undocumented 'label' parameter and the response shape.

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% – 'mode' has just 'Default live.' and 'label' has no description at all. The description substantially compensates for 'mode' by explaining exactly what 'test' produces and how its sends behave, but it leaves 'label' entirely unexplained in both schema and description.

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

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

States a specific verb and resource ('Create a long-lived API key') plus a hard scope constraint (max 10 per account). An agent can immediately distinguish this from the read-side sibling list_api_keys and from auth-related tools.

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

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

The description gives a concrete use case for the 'test' mode (staging and CI), which is genuine usage guidance. However, it says nothing about when to create a key versus using other auth mechanisms (e.g. the 'auth' sibling), or what prerequisites/permissions are needed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the exact return payload (email, daily_limit, sent_today, remaining_today, credits_remaining, resets_at), which is genuinely useful since there is no output schema, but it says nothing about auth requirements, error behavior when signed out, or whether the values are real-time.

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 compact sentence with no filler; the most important information (which account, which fields) is front-loaded. The sentence-fragment form without a verb is slightly terse but wastes nothing.

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?

Because no output schema exists, enumerating the returned fields is the right call and it is done here. The remaining gap is failure/edge behavior (unauthenticated state), which is minor for a zero-parameter self-account 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter surface for the description to clarify or omit.

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

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

The description identifies a specific resource — the signed-in account — and enumerates the fields it exposes, which lets an agent tell it apart from siblings like update_account or list_api_keys. It lacks an explicit verb ('Retrieves...'), but the resource and scope are unambiguous.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. must be authenticated), and no reference to any alternative tool. An agent must infer from the name alone that this is the read counterpart to update_account.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that no sign-in is required, but says nothing about rate limits, caching/freshness beyond 'renewed every day,' cost, or response shape for a read endpoint.

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 compact sentence with no waste, and the 'no sign-in' caveat is placed at the end as a useful qualifier. The list-of-offerings phrasing is slightly muddled but not verbose.

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 and no annotations, the description must carry more, and it only sketches the pricing categories returned. It is minimally sufficient to know what data is involved but omits format and any behavioral caveats.

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 there is nothing to disambiguate and the baseline 4 applies. No parameter detail is needed or missing.

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 name get_pricing plus the description 'Free daily emails..., email credits per dollar, and the packs on sale' conveys the subject matter (pricing tiers/credits/packs), but it never states the action explicitly ('retrieves pricing') and reads as a list of offerings. It also does not distinguish itself from pricing-adjacent siblings like buy_pack or order_status.

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 only usage cue is 'No sign-in needed,' which is an access condition rather than when-to-use guidance. There is no statement of when to call this versus buy_pack, order_status, or check_email, leaving the agent to infer its place in the workflow.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one meaningful trait beyond the schema: secret key material is never returned, only ids and labels. It says nothing about permissions, pagination, or ordering, which are the remaining gaps for a zero-param read tool.

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

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

A single compact sentence with no filler, and the most decision-relevant fact (never the keys themselves) is placed in the parenthetical. It is slightly clipped for a standalone description but wastes nothing.

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 parameters and no output schema, the description is the only source of return-value information, and it supplies the essentials (ids and labels). It omits pagination or result-size expectations, which is a minor gap for a simple account-scoped list.

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 there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

The description names the specific resource (the account's API keys) and what is returned (ids and labels, never the keys themselves), which is enough to separate it from the sibling create_api_key. It is a noun phrase rather than an explicit verb+resource statement, so listing is only implied, but the intent is unambiguous.

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

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

There is no statement of when to use this tool versus alternatives such as create_api_key, get_account, or auth. The only implicit guidance is that it reads existing keys rather than creating them, which an agent must infer from the name.

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

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

With no annotations, the description carries the full burden and discloses almost nothing: no auth requirement, no pagination or ordering, no indication of whether addresses and domains are separate fields. It does implicitly signal an account-scoped read, which is the only behavioral clue offered.

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?

Extremely short with no waste, but it is a sentence fragment lacking a leading verb, and it is under-specified rather than genuinely concise. Front-loading is trivially satisfied because there is only one clause.

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 no-annotation, no-output-schema tool, the description should at least say what the returned entries look like or how they are scoped. Neither is provided, leaving the agent to guess at the response shape and filtering 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 zero parameters, so the schema imposes nothing to explain and the baseline of 4 applies. The description's brief statement of what is returned is the only parameter-adjacent content and it is adequate.

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 fragment 'The account's blocked addresses and domains' identifies the resource returned but supplies no verb, so the agent must infer that it lists existing blocks rather than creating them. Given siblings like block and unblock, that inference is easy but not stated. Purpose is implied rather than declared.

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 mention of block/unblock as the mutation alternatives, and no indication of scope conditions. The read-only listing intent is only inferable from the noun phrase.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: these emails are never delivered, results are ordered newest first, and the single-id lookup exposes html/text including a verify_start code. It stops short of auth/rate-limit/error behavior, but covers the essential traits.

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 dense sentence that front-loads the key behavior (never delivered, newest first) before the parameter modes. It is slightly run-on with stacked colons and parentheticals, but every clause carries information.

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

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

For a simple read-only list tool with no output schema and no annotations, the description covers what is returned, ordering, delivery status, and the single-record mode. Pagination/auth details are absent but limit is handled by 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 100% (baseline 3), and the description adds value beyond the schema by explaining what the id lookup actually returns (one email with html and text, plus a verify_start code) and what to does (filter by recipient). limit is left entirely 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+resource (list test messages) and immediately characterizes them: sent with a test key, accepted, stored, never delivered. It is clearly distinguishable from the send/verify siblings, though it never names a sibling tool 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?

It implies two usage modes (list all vs. fetch one by id, or filter by recipient) but gives no explicit when-to-use/when-not guidance or named alternatives among the many sibling tools. Usage must be inferred from the behavior description.

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

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

With no annotations the description carries the full behavioral burden, and it does add real value by enumerating the possible states (pending or paid). However, it says nothing about auth requirements, error behavior for an unknown or malformed order_id, or latency/rate limits, so significant behavioral gaps remain.

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 resource and the returned values, with no 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 one-parameter getter with no output schema and no annotations, the description covers the essential purpose and the set of possible results, which is most of what an agent needs. It stops short of describing failure modes or auth, leaving a modest but real 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?

The single parameter has 0% schema description coverage, so the schema only says it is a required integer. The description compensates partially by explaining that order_id refers to an order produced by buy_pack, which gives the agent a source for the value, but format and validity constraints are still absent.

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?

Names the resource (an order) and the exact information returned (its status), and ties it to the originating sibling tool buy_pack, so an agent can position it next to buy_pack rather than the auth/email/blocklist siblings. It is a noun phrase rather than a verb, but for a simple getter the intent 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?

The phrase 'from buy_pack' implies the usage context (checking on an order you created), but there is no explicit when-to-use, no statement of prerequisites, and no alternative named. Usage is only implied.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that an unsubscribe link is auto-appended, that invalid/role/blocked/unsubscribed recipients are skipped at no cost, that each accepted recipient consumes 1 email of the daily allowance, and that an oversized campaign is refused atomically. It omits auth requirements and any rate-limit detail beyond the allowance.

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 dense sentences with zero filler, front-loaded with the core action and recipient limit, then the billing and failure semantics. Every clause carries actionable 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 6-parameter mutation tool with no annotations and no output schema, the description covers the critical behavioral surface (cost accounting, skip rules, atomic refusal, auto-unsubscribe). It stops short of describing auth/permission requirements or the response, which the absent output schema leaves unaddressed.

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

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

Schema description coverage is only 50%, so the description should compensate, but it only restates the recipient cap (already in the schema) and alludes to unsubscribes without explaining list_id. Nothing is said about from, html, text, subject, or how html and text interact, leaving half the parameters unexplained in both places.

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 and resource plus scope: "Send a marketing email to up to 1,000 recipients." The batch limit and campaign semantics clearly distinguish it from the single-send sibling send_email without needing to name 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 context is implied rather than stated: the 1,000-recipient cap and the daily-allowance accounting tell the agent this is the bulk path, but there is no explicit "use this instead of send_email" or when-not-to-use guidance. The refusal rule gives useful preconditions but not alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It does add genuinely useful context the schema cannot convey: quota consumption ('Uses 1 email of today's allowance') and the transactional-only restriction. However, it says nothing about auth requirements, failure behavior, deliverability limits, or whether sending is reversible/immediately dispatched.

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

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

Three short sentences, zero filler, and the core scoping constraint plus the alternative route are front-loaded. Every clause earns its place by constraining what the agent may send.

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 and no annotations, the description covers the essentials: scope, quota cost, and the sibling it must not replace. It leaves auth/permission expectations and error conditions unmentioned, which is a modest but real 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 83%, so the schema already documents almost every parameter (including reply_to's fallback behavior and the text/html alternative). The description only indirectly clarifies that 'to' is a single recipient, adding little beyond the structured fields; 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 ('Send one transactional email') plus the scope constraint ('to one recipient') and examples of the category (receipt, code, alert). It explicitly distinguishes itself from the sibling send_campaign, so an agent can choose between the two 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 names the alternative route explicitly: 'Marketing mail must go through send_campaign,' which is a clear when-not condition. It gives no positive guidance for edge cases that siblings imply exist (e.g., test sending vs. list_test_messages, or account/auth prerequisites), so it is clear context without full coverage.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about authentication/permission requirements, idempotency, or what happens when the value is not currently blocked. For a mutation tool with zero annotation coverage, this is a substantial 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?

A single front-loaded sentence with no filler; the action and its target are stated immediately and nothing extraneous is included.

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 tool this covers the core operation, but with no annotations and no output schema the description leaves auth requirements, error/failure behavior, and confirmation of effect 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 0%, so the description must compensate. It does map the two accepted forms ('email address or domain') onto the 'value' parameter and the email/domain 'kind' enum, but it gives no format detail (e.g., whether a domain should omit scheme or subdomain) beyond what the enum already shows.

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 pairs a specific verb ('Remove') with a specific resource ('email address or domain from the blocklist'), so an agent immediately knows this is the inverse of block. It stops short of naming the sibling 'block' or 'list_blocklist', but the operation 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?

Usage is only implied: you call this to undo a block. There is no statement of when to use it versus alternatives, no prerequisite (e.g., the entry must already be blocked), and no guidance on the block/unblock pairing the agent may need.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether this is a partial update, whether omitting a field preserves or clears it, what permissions are needed, or whether the change is reversible. For a mutation tool with zero annotation coverage this is a real 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?

A single short sentence with no filler and the resource front-loaded. Efficient, though terse enough that it underspecifies rather than over-explains.

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 an unannotated mutation tool with no output schema and no parameter descriptions, the description is too thin. It omits update semantics, permissions, and any return behavior, leaving the agent guessing about a write 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 0% and the schema supplies only types, so the description is the only source of meaning. It does name both parameters ('name', 'company'), which maps them usefully, but adds nothing about format, length, or how the two interact.

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 ('Set') and resource ('the account') and names the two fields it touches (name, company). It is clear on its own, though it does not differentiate itself from siblings like get_account beyond the obvious read/write split.

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

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

There is no guidance on when to use this versus alternatives such as get_account, nor any prerequisites, ordering, or exclusions. The agent must infer usage entirely from the verb.

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

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

No annotations exist, so the description carries the full burden. It does disclose the verdict vocabulary (ok, invalid, no_mx, disposable, role), which is real behavioral value not available in the schema, but it says nothing about latency, network/SMTP lookups, caching, or what each verdict implies.

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, purpose front-loaded, with the verdict list appended compactly. No filler or restatement of the name.

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 and no annotations, the description must carry return-value semantics, and it only names the verdicts without explaining them (e.g., what makes an address 'disposable' or 'role', whether 'ok' guarantees deliverability). Adequate but clearly short of complete for a validation 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?

Only one parameter and schema coverage is 100%, so the schema already documents 'email'. The description adds no format, normalization, or multi-address syntax detail, so the baseline of 3 for high schema coverage 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: validate/check an email address, plus the outcome vocabulary. It does not, however, distinguish itself from close siblings such as check_email, verify_check, and verify_start, which an agent could easily confuse with 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?

"Check an address before sending" implies a use context (pre-send hygiene), but there is no explicit when-not guidance and no routing to the similarly named siblings check_email / verify_check / verify_start. The agent is left to infer which of the verification-family tools applies.

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

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

With no annotations, the description carries the full burden and does so well: it enumerates every return status (approved, wrong_code, expired, too_many_attempts, already_used, replaced, not_found), discloses the 5-wrong-code lockout, states codes are single-use ("works once"), and notes it consumes no allowance.

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 information-dense but front-loaded: purpose first, then parameter routing, then return semantics. Slightly run-on, but every sentence adds actionable content and 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 3-param tool with no output schema and no annotations, the description covers returns, edge-case statuses, lockout policy, and billing impact, which is nearly everything an agent needs. It stops short of noting any auth requirement, but the operational picture is essentially complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: "to" resolves to the newest code sent to that address, while "id" is the identifier from verify_start. This clarifies the to/id/code interplay beyond the terse schema strings.

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 ("Check a code from verify_start") and explicitly anchors to the sibling verify_start, so an agent can place it in the two-step verify flow without opening the schema. It is clearly the check step as opposed to the start step.

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 opening clause ties the tool to the verify_start output, giving clear usage context, and "Uses no allowance" signals a billing distinction versus other tools. It does not state explicit exclusions or alternatives, but for a single-purpose step tool the context is clear.

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

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

With no annotations, the description carries the full behavioral burden and does so well: the code is never returned, resends are limited, the code expires, it consumes 1 email of the daily allowance, and a new code to the same address replaces the pending one. These are exactly the non-obvious traits 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: the core action leads, followed by behavior, cost, edge case, and the follow-up call. Every sentence adds an actionable fact 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 code-generation tool with no output schema, the description covers the return value ('Returns an id'), side effects, quota impact, and the required follow-up call. 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 description coverage is 100%, so the schema already documents 'to', 'from', 'app_name', 'expires_in', and 'code_length' with defaults and ranges. The description adds no parameter-level detail beyond noting the usage cost, 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 ('Email a one-time verification code to an address') and immediately names the scenarios it serves (sign-up, sign-in, confirming an email). Clearly distinguished from the sibling verify_check, which is called afterward with the user-entered code.

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 routes the agent to the next step: 'Then call verify_check with what the person typed.' It also enumerates the triggering scenarios, so an agent knows exactly when this tool applies versus verify_check.

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