Mail Blaze MCP by usefulapi

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

Adds substantive behavior the annotations cannot express: the tool may trigger a double opt-in confirmation email, making the write have an outbound side effect. It also discloses that a duplicate email returns a conflict error, which corroborates the non-idempotent annotation. Auth requirements and rate limits remain undisclosed.

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 zero filler, led by the uppercase write/side-effect warning so the agent sees the risk before anything else. Every sentence carries distinct information.

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

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

No output schema exists, yet the description covers the key things an agent needs before writing: side effects, consent precondition, and the duplicate-error path. It is slightly thin on what the call returns and whether existing subscriber fields get overwritten versus merged.

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 description supplies no parameter-level meaning at all; it only expresses scope ('one subscriber'). With 60% schema coverage, the non-obvious fields (first_name, last_name, custom_fields with its cross-reference to mailblaze_list_list_fields) are covered by the schema itself, so 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 ('add one subscriber to a mailing list') and scopes it to a single record, which implicitly separates it from mailblaze_add_subscribers_bulk. It does not name the bulk sibling or the lookup tool 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?

Provides a real precondition ('Only add people who agreed to receive your email') and explains the duplicate outcome, but never routes the agent to alternatives such as mailblaze_find_subscriber_by_email to pre-check existence or mailblaze_add_subscribers_bulk for multiple people. Usage is implied rather than directed.

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 this a non-read-only, destructive, open-world write, and the description adds value beyond them: the 100-item cap, the upsert behavior (existing email is updated rather than duplicated), and the outbound side effect of confirmation emails depending on list settings. It does not explain partial-failure behavior or whether an update overwrites existing field values — the latter is in mild tension with idempotentHint=false but is not a contradiction.

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 compact sentences with the risk warning front-loaded in caps, followed by capability, side effect, and compliance note — each sentence carries distinct information with 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?

For a bulk mutation tool with no output schema, the description covers scope, upsert semantics, side effects, and consent. The main gap is what happens when some of the 100 entries are invalid — whether the batch partially succeeds — which an agent cannot infer from annotations alone.

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 50%: custom_fields is documented inline and the '1 to 100 subscribers' description is present, but list_uid carries no explanatory text in the schema. The description implies list_uid identifies the target list and restates the 100 cap, but adds no format or lookup hints (e.g., that list UIDs come from mailblaze_list_lists), so it only partially compensates.

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

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

States a specific verb and resource (add subscribers to a mailing list), adds the distinguishing scope ('bulk', up to 100 in one request) and the upsert rule that separates it from mailblaze_add_subscriber. An agent can tell exactly what this does and how it differs from the single-subscriber sibling 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?

'Only add people who agreed to receive your email' is a real precondition, and 'may send confirmation emails' sets expectations before calling. But there is no explicit routing guidance against siblings (single add, update_subscriber, or checking with find_subscriber_by_email first), so when-to-use is only implied by the bulk framing.

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 flag a destructive, non-idempotent, open-world write; the description adds the substance behind them — delivery reaches every subscriber of the list or segment, consumes sending credit, and cannot be recalled once sent. That is exactly the cost/irreversibility context an agent needs before committing an irreversible action.

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 write/irreversibility warning is front-loaded in the opening clause, followed by prerequisites and the confirmation requirement in a logical order. Every sentence carries non-redundant information; nothing repeats the schema or annotations verbatim.

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 8-required-parameter destructive tool with no output schema, the description covers consequences, prerequisite lookups, and the human-confirmation gate. It omits what a successful call returns (campaign uid?) and whether a scheduled campaign can still be modified or cancelled before send_at — the latter is directly relevant given the 'cannot be recalled' warning.

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 44% of the 9 parameters carry schema descriptions, so the description should compensate more than it does. It adds real provenance for the two UIDs (template_uid, list_uid via sibling tools) and clarifies segment_uid as an optional narrowing of list_uid, but leaves name, subject, from_name, reply_to, and from_email unexplained — those must be inferred from names alone.

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 campaign ... from an existing template and schedule it for send_at') plus the targeting scope (mailing list or one of its segments). This clearly separates it from read-side siblings like mailblaze_get_campaign and mailblaze_list_campaigns, and from mailblaze_send_transactional_email by emphasizing bulk delivery to a list.

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 concrete preconditions: a template uid from mailblaze_list_templates and a list uid from mailblaze_list_lists, plus an explicit instruction to confirm list, segment, subject, template and send time with the user first. It stops short of naming when to prefer an alternative route (e.g. transactional email for one-off messages), so it is clear context rather than a full when/when-not map.

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

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

Annotations already declare readOnly=false, destructive=false, openWorld=true; the description adds genuinely new context: the HTML is encoded before submission, Mail Blaze enforces an unsubscribe link, and no email is dispatched. Missing only an idempotency/duplicate-name note against the idempotentHint=false annotation.

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

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

Three compact clauses with the 'WRITE:' prefix front-loaded as an operation-type signal. Every sentence carries information; 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 2-parameter mutation tool with annotations but no output schema, the description covers the write semantics and a key validation constraint. It could say more about what the response contains (e.g., the new template id) and about the 'name' field, but it is sufficient to invoke 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 only 50%; the description compensates for the html parameter by reiterating the unsubscribe-link requirement and disclosing the base64 transformation (useful, schema-invisible behavior). The required 'name' parameter gets no semantic elaboration in either place, leaving a real gap.

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

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

States a specific verb and resource ('create an email template from HTML') and adds a mechanism detail (server-side base64 encoding). It is distinguishable from get_template/list_templates by the 'create' verb, though it doesn't explicitly name a sibling to route away from.

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?

'Sends nothing' implies this is a preparatory step rather than a send action, which loosely separates it from send_transactional_email or create_campaign. However, there is no explicit 'use X when you want to actually send' guidance or prerequisite statement.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral detail: it returns the subscriber object including its uid, and a missing match surfaces as a not-found error rather than an empty result — that shapes agent error handling.

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, no filler, and the lookup scope is front-loaded ahead of the return contract. 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, the description correctly takes on the return-value burden by naming the returned subscriber and its uid. What's missing is edge-case behavior (case sensitivity, whether a not-found error is distinguishable from an auth/list-not-found error), but for a 2-parameter read this is close to sufficient.

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%, but the two required parameters are self-describing by name and the description contributes the key semantic that list_uid scopes the lookup to a single list. It adds nothing about uid format, case-sensitivity of the email match, or duplicate match behavior within a list.

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 ('Look up a subscriber') plus the scoping constraint ('in one list by email address'), which cleanly separates it from get_subscriber (by uid) and list_subscribers. It never names those siblings explicitly, so the 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?

The phrase 'by email address' and 'in one list' implicitly cues when this is the right tool (you have an email, not a uid; you know the list), but there is no explicit when-to-use/when-not or named alternative. The agent must infer the routing decision from the sibling names.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the notable return fields, but does not discuss permissions, error behavior for an unknown UID, or other operational 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 with no wasted language. It states the operation, key input, and returned fields efficiently.

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

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

For a simple single-resource getter with annotations and one parameter, the description is mostly complete, especially since it lists the fields returned in the absence of an output schema. It could be slightly stronger by clarifying error behavior or the relationship to list campaigns.

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 only parameter is campaign_uid, and the description says the lookup is "by uid," which aligns with the schema name but adds little detail. With 0% schema description coverage, it does not explain UID format, source, or validation beyond what the schema pattern already enforces.

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 campaign by uid, and lists the main fields returned. It clearly implies the single-item counterpart to list_campaigns, though it does not explicitly differentiate itself from sibling tools like get_campaign_summaries.

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 "by uid" implies this tool should be used when the caller already has a campaign UID, but it does not explicitly say when to use it versus list_campaigns or get_campaign_summaries. Usage is therefore inferable but not fully guided.

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

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

The annotations already disclose readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful context about what the breakdown contains (inbox providers like Gmail, Outlook, Yahoo) but does not discuss authentication, rate limits, pagination, or 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?

The description is a single tight sentence with no wasted words. The core resource and scope are front-loaded 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 single-parameter read tool with no output schema, the description adequately states the return concept. However, it leaves gaps around parameter semantics and usage alternatives that an agent may need when deciding whether to call this versus other campaign tools.

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

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

Schema description coverage is 0%, and the single parameter campaign_uid is undocumented in the schema beyond its pattern and length constraints. The description mentions 'a campaign' but does not explain the parameter, its required status, or expected identifier format, so it does not compensate for the coverage gap.

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

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

The description states a specific resource return type: an inbox-provider breakdown of a campaign's delivery, with examples of providers. It distinguishes this from general campaign tools, though it does not explicitly name sibling alternatives such as mailblaze_get_campaign or mailblaze_get_campaign_summaries.

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 tool is used to inspect delivery by inbox provider, but it gives no explicit when-to-use guidance, prerequisites, or comparison to alternative campaign reporting tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds genuinely non-redundant context: the underlying API call is a POST that is semantically read-only purely because of the id list. That preempts an agent misreading a POST as a mutation. It doesn't cover return shape or partial-failure behavior for invalid uids, keeping it below 5.

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

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

Two short sentences, no waste, with the capability and the returned metrics front-loaded before the POST clarification. Every clause earns its place.

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

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

For a one-parameter read tool with no output schema, the description names the exact metrics returned and explains the misleading HTTP verb, which is what an agent needs to call and trust it. Minor gaps remain around error behavior for bad uids and ordering of results.

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

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

Schema coverage is 100% and the single parameter campaign_uids is fully documented including min/max item counts. The description reinforces the 50-item cap and the id-list nature but adds no syntax or format detail beyond the schema, 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+resource ('Bulk report summary ... for up to 50 campaigns in one call') and enumerates the returned metrics (sent, opens, clicks, bounces, unsubscribes). The word 'Bulk' and 'in one call' implicitly contrast with the single-campaign sibling get_campaign, though no sibling is named explicitly.

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

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

Usage is implied rather than stated: the 'up to 50 campaigns in one call' framing suggests this is the batching alternative to per-campaign calls, but there are no explicit when-to-use/when-not rules or named alternatives. An agent can infer the context but must do so 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine value by disclosing the shape of what comes back (general settings, default sender, company details, counts), which matters since there is no output schema. It says nothing about permissions or error behavior, keeping 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?

A single sentence that front-loads the action and identifier, then lists returned content. Every clause carries information; nothing is redundant.

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

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

For a one-parameter, read-only lookup with full schema coverage and annotations, the description supplies the missing piece — the return contents — which no output schema provides. The only residual gap is that it does not address error behavior for an invalid or missing uid.

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

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

There is only one parameter and schema coverage is 100%, with the schema itself noting the uid comes from mailblaze_list_lists. The description's "by its uid" merely echoes the schema, adding no format or validation detail beyond it.

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

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

States a specific verb and resource ("Get one mailing list") plus the lookup key (uid), which clearly separates it from the sibling mailblaze_list_lists. It also enumerates what the record contains, though it never names the list/plural 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: the singular "one mailing list by its uid" suggests it is for retrieving a known list rather than enumerating lists. There is no explicit when-to-use, when-not-to-use, or named alternative; the pointer to mailblaze_list_lists for obtaining the uid lives in the schema, not the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds that results are absent until the job finishes (a two-phase async pattern), but says nothing about status values, job/result expiry, or whether repeated polls are cheap.

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 what is returned and immediately anchored to the 202/job_id context. No filler and nothing that could be cut without losing meaning.

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 is the only source for return values, and 'status (and result when finished)' is thin for a polling tool — an agent does not know what a pending status looks like or how long results persist. With only one required parameter the coverage is adequate but not 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 0%, so the description must carry the parameter meaning, and it does: job_id is the identifier from a 202 reply, which tells the agent where to obtain it. It adds no format constraints beyond the schema's pattern, but the origin guidance is the key semantic.

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 (report job) plus the exact payload returned (status, and result when finished), which is clearly distinguishable from the campaign/template/subscriber getters among the siblings. It stops short of naming any sibling explicitly, but none overlaps enough to confuse an agent.

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 'as returned in a 202 reply with a job_id' supplies a concrete trigger condition: call this after an async request responds 202. It does not cover polling cadence, when to stop polling, or what to do if the job is unknown/expired, so it is clear context without 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered without the description. The description contributes the return shape hint ('status, fields, dates'), which is useful, but says nothing about not-found behavior or whether a subscriber outside the given list 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 short sentence with the lookup key front-loaded and a compact parenthetical enumerating returned attributes; nothing is redundant. It is slightly telegraphic 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 2-parameter read tool with no output schema, the description covers the basic operation and sketches the returned attributes. It leaves gaps on list_uid's meaning and on error/empty-result behavior, which matter for a lookup-by-identifier 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 50%: subscriber_uid is documented (including its source tools) but list_uid has no description. The description implies list scoping ('subscriber of a list'), confirming why list_uid is required, but adds no format or semantics beyond that. Baseline 3 fits given partial schema documentation.

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

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

The description gives a specific verb + resource ('Get one subscriber of a list') and adds the lookup key ('by subscriber uid'), which is enough to tell it apart from list-style siblings like mailblaze_list_subscribers. It stops short of explicitly naming mailblaze_find_subscriber_by_email as the alternative path, so it isn't a 5.

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

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

Usage is only implied: 'by subscriber uid' suggests you already have a uid, and the schema's parameter note points to list_subscribers/find_subscriber_by_email as uid sources. There is no explicit statement of when to pick this tool versus those siblings, nor any precondition about the list_uid scoping.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds useful behavior in 'Cursor-paged' and the activity-type enumeration, but says nothing about ordering, empty results, or what happens for an unknown email.

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 padding, with the core capability front-loaded and the pagination note trailing as a secondary attribute.

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 by naming the event types returned plus pagination behavior. Only the shape/ordering of individual activity records 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 coverage is only 50%, and the description compensates: 'by email address' identifies the required key and 'optionally limited to one list' gives list_uid its meaning, while limit and cursor are documented in the schema itself. Only the exact semantics of the list filter (origin list vs. membership) remains slightly vague.

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

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

Specific verb+resource: activity events (sends, opens, clicks, bounces) for exactly one subscriber identified by email. The enumerated event types clearly separate it from profile-oriented siblings like mailblaze_get_subscriber, though no sibling is named explicitly.

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

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

'Optionally limited to one list' implies the narrowing use case, but there is no explicit guidance on when to prefer this over get_subscriber or find_subscriber_by_email, nor when not to use it. Usage is inferable 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the response includes name and content, which is a small but genuine addition beyond the structured data; it says nothing about not-found handling or cost/rate behavior.

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

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

One short sentence with the identifier constraint front-loaded and the returned fields in parentheses. Nothing 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 one-parameter read with annotations and no output schema, the description covers the input key and the shape of the return (name and content). Only error/not-found behavior is missing, which is minor at this complexity.

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

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

Schema description coverage is 0% and the single parameter, template_uid, is undocumented in the schema beyond type/pattern. The description names 'uid' as the key, confirming it is a unique template identifier, but does not restate or add semantics beyond that — it partially compensates for the coverage gap.

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

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

States a specific verb (get) and resource (one email template) with the identifier used, and the word 'one' signals single-item retrieval as opposed to mailblaze_list_templates. It does not explicitly name the list sibling, so the differentiation is implied 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 only implied — fetch a known template by uid. There is no statement of when to prefer this over mailblaze_list_templates or mailblaze_get_campaign, nor any condition for when the call would fail (e.g., unknown uid).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set (recipient, subject, status, timestamps), but says nothing about behavior on a missing uid, uid aliasing, or permissions.

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 identifies the lookup key first and the return fields second, with no filler. Only the absence of any routing/qualifier clause keeps it from a 5.

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

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

For a one-parameter read tool with annotations covering safety and no output schema, the description supplies the shape of the return value (recipient, subject, status, timestamps), which is the main missing structured information. Error/not-found behavior is the remaining 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 0%, so the description must carry the load; 'by uid' links the single email_uid parameter to its purpose but adds no format or provenance details beyond what the schema pattern already enforces. Minimal but not misleading.

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 transactional email) plus the identifier used to retrieve it, and names the fields returned. It is implicitly distinguishable from mailblaze_list_transactional_emails by 'one ... by uid', though it 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?

The 'by uid' phrasing implies this is the single-record lookup versus the list tool, but there is no explicit when-to-use/when-not-to-use guidance and no alternative is named. An agent can infer the split, but must infer it.

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

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

Annotations already cover safety (readOnlyHint, destructiveHint false), yet the description still adds real behavior: cursor-pagination loop semantics and the 202-with-job_id async response path. It doesn't mention authorization or event payload shape, but the operationally risky case (large campaigns) is disclosed.

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 zero filler; the core purpose comes first, then paging, then the async fallback in order of likely need.

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 covers the key return-shape facts an agent needs (next_cursor, job_id). What an individual event object contains and whether the 202 case blocks the cursor flow are left unstated, a minor gap for a 4-param read 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 50%: limit and cursor already have descriptions, kind is an enum. The description restates cursor semantics rather than adding format detail, and campaign_uid is undocumented in both places. 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 ('List the individual events of a campaign') and enumerates the four kinds, which cleanly separates it from aggregate siblings like get_campaign_inbox_breakdown and get_campaign_summaries. An agent can identify it 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 operational guidance for cursor paging ('pass the reply's next_cursor back until it is null') and routes the large-campaign case to mailblaze_get_report_job by name. It doesn't explicitly contrast with the aggregate siblings, but the 'individual events' framing implies the distinction.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered; the description adds the useful disclosure of which fields are returned despite there being no output schema. It stops short of describing result volume, pagination in the description, or ordering, but the safety context is fully carried by 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?

Two short sentences, response fields front-loaded, followed by the natural next step. No filler and nothing important 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-only list tool with no output schema, the description is nearly sufficient: it names the returned fields and the follow-up path, with pagination fully handled by the schema. Minor gaps remain around result volume/ordering and how it differs from the campaign-events and summaries siblings.

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 `page` parameter is 100% documented in the schema, including pagination semantics (sets of 10, keep going until empty), so baseline 3 applies. The description adds nothing about paging or filtering beyond 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?

Specific verb ("List") plus resource ("the account's email campaigns") and even the fields returned (uid, name, status, dates), so the agent knows exactly what comes back. It distinguishes itself from detail-fetching siblings by pointing at the campaign uid as the gateway to "details and reports," though it does not name those sibling tools 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 implied rather than stated: the agent is told to obtain uids and then use them for details/reports, which suggests this is the discovery step preceding get_campaign / get_campaign_summaries. There is no explicit when-to-use, no exclusions, and no mention of the related list_campaign_events tool that an agent might otherwise confuse it with.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds useful cross-tool context about what the tags mean downstream, but says nothing about pagination behavior, result ordering, or empty-page termination beyond what the schema already documents.

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 operation and its return shape, followed by the one piece of downstream context that matters. No filler.

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

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

With no output schema, the description usefully enumerates the returned fields, and annotations carry the read-only profile. The remaining gap is list_uid semantics and whether the listing paginates — the latter is at least covered in 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 only 50%: the 'page' param is well documented in the schema, but list_uid has no description and merely a pattern constraint. The description's 'of a mailing list' only weakly implies list_uid's role, adding nothing about its format (UID vs. list name/ID).

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 fields of a mailing list') and even names the returned fields (label, tag, type, required), which separates it from list_lists and get_list. It stops short of explicitly naming which sibling to use when, but the resource 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 second sentence implies usage — the tags are the keys needed when adding or updating subscribers — so an agent can infer this is a discovery step before add_subscriber/update_subscriber. It never states that workflow explicitly, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful context beyond annotations by identifying returned fields (important because there is no output schema) and noting paged access, though it omits auth or rate-limit details.

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

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

The description is two short sentences, front-loaded with the purpose and return fields. Every phrase adds either scope, workflow guidance, or pagination information, with no wasted text.

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, the description gives enough: returned fields, pagination, and downstream use of the uid. It could say more about what 'defaults' contains or how pagination terminates, but the schema covers the latter.

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

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

Schema description coverage is 100%, so both parameters are already well documented in the schema. The description only restates 'page + per_page' and adds no syntax or behavioral detail beyond what the schema provides, making 3 the appropriate baseline.

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

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

States a specific verb and resource: list the account's mailing lists. It also names the returned fields (name, uid, subscriber counts, defaults), making it clearly distinct from siblings like get_list, list_segments, and list_subscribers.

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?

Provides clear workflow guidance: 'Use the list uid in the other tools,' which tells the agent why and when to call this tool first. It does not explicitly name alternatives or exclusions, so it falls 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, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds the returned fields (uid, name) and the downstream campaign use case, but says nothing about pagination behavior, result sets, or empty-page semantics that a caller must 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?

Two short sentences with no waste; the resource being listed and the returned fields are front-loaded, and the campaign-uid note follows logically.

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 usefully names the return fields (uid, name). Pagination is handled by the schema's page description. The main gap is not explaining how to obtain list_uid, which matters for a required parameter.

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

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

Schema coverage is 50%: the 'page' parameter is well documented in the schema, but 'list_uid' has no schema description, and the description only refers vaguely to 'a mailing list' without explaining the uid format or how to obtain it (e.g., from mailblaze_list_lists). Marginal compensation for the coverage gap.

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

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

States a specific verb ('List') and resource ('segments defined on a mailing list') and names the returned fields (uid, name). It is distinguishable from siblings like list_list_fields and list_lists, though it doesn't explicitly contrast with them.

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

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

'A segment uid can be used when creating a campaign' gives a downstream-use hint, which implies why an agent would call this. However, there is no explicit when/when-not guidance or mention of the alternative tools such as mailblaze_create_campaign or mailblaze_list_list_fields.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds real value beyond that: page size (10 per page), the continuation mechanism, and a PII disclosure ('Contains personal data (emails, names)'') that an agent should know before surfacing results.

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 a parenthetical; the resource is stated first and the pagination/PII caveats follow. Every element earns its place, though the pagination detail partially duplicates 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?

With no output schema, the description should say what a subscriber record looks like; it only hints at emails and names. The list_uid requirement and its source are unexplained, and there is no note on empty-page termination beyond what the schema page field already says.

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

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

Schema coverage is 50%: page is fully documented in the schema and echoed by the description, but list_uid has no description anywhere – only a pattern and length constraints. The description does not explain what a list_uid is or how to obtain one (e.g., via list_lists), leaving the required parameter semantically thin.

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 (subscribers of a mailing list), which is clearly distinct from get_subscriber, find_subscriber_by_email, and list_lists. It never explicitly contrasts itself with those siblings, 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 parenthetical 'use page to go on' gives procedural pagination guidance, but there is no statement of when to prefer this over find_subscriber_by_email or get_subscriber when hunting for a specific person. Usage is implied rather than routed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context about the fields returned, but says nothing about pagination behavior, result-set size, or error conditions beyond what the page schema already documents.

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 resource and returned fields front-loaded and the downstream use case stated last.

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 full schema coverage and no output schema, this covers the essentials: what is listed, what fields come back, and why it matters. Only the pagination condition and the get_template alternative are left to the schema and inference.

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?

With a single optional parameter and 100% schema coverage, the schema already explains page numbering and the 'keep going until a page is empty' termination rule in more detail than the description. The description adds no parameter-level meaning, which is the expected baseline here.

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

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

The description gives a specific verb and resource ('List the account's email templates') and even names the fields returned ('uid, name'). The singular sibling get_template is implicitly distinguished by 'List', though the description never says so 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 supplies a motive for calling it ('A template uid is needed to create a campaign'), which implies it should be used before mailblaze_create_campaign. However, there is no explicit when-not guidance and no mention of the alternatives get_template or create_template.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds only 'Paged', which is less detailed than the schema's own note about 10-result pages and stopping on an empty page. Field list is a modest addition.

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

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

Two short sentences, front-loaded with purpose and then the salient fields and pagination note. Nothing superfluous.

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, one-parameter list tool with full annotation coverage and a fully described schema, the description covers purpose, returned fields, and pagination. It could be slightly stronger by noting the singular sibling for detail lookups, but nothing critical is missing.

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

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

Only one parameter and schema description coverage is 100%, so the schema already fully documents 'page' including page size and the termination rule. The description's single word 'Paged' adds no meaning beyond what the schema provides; 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 the transactional emails sent through the account') and names the fields returned, which distinguishes it from its singular sibling mailblaze_get_transactional_email. However, the differentiation from that sibling is only implied through the verb, not called out.

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 name and verb: use this to enumerate transactional emails, use the get_ variant for a single one. There is no explicit when-to-use or when-not-to-use guidance, no mention of filters, or guidance about what to do with the returned uid.

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

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

The description adds meaningful context beyond the annotations by explaining the effect, campaigns reach them again, and the consent prerequisite. The annotations already cover the write/destructive/non-idempotent profile, so this is a strong but not fully exhaustive disclosure.

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

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

Two sentences, front-loaded with the WRITE marker and the core state change. Every sentence carries operational value, and the consent constraint follows 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 annotations covering safety and no output schema, the description is nearly complete. The main gap is that it does not explain the required list and subscriber identifiers.

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

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

Schema description coverage is 0%, so the description must compensate for the two required identifiers, but it does not mention list_uid or subscriber_uid at all. The parameter names are somewhat self-explanatory, but the description adds no guidance on what identifiers to supply.

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: set a previously unsubscribed subscriber back to subscribed. It distinguishes the operation from sibling tools like unsubscribe_subscriber and add_subscriber by making the prior unsubscribed state 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?

It gives a clear condition for use: only when the person asked to be re-added (consent). That also implies when not to use it, but it does not explicitly name alternatives such as update_subscriber or unsubscribe_subscriber.

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 flag destructiveHint=true and idempotentHint=false, and the description adds meaningful extra context: it sends immediately, consumes sending credit, and cannot be recalled. That is real value beyond structured fields, though it stops short of covering failures, rate limits, or verified-sender rejection behavior beyond what the schema notes.

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 action and scope, then constraints, then the guardrail and exclusion. Nearly every clause carries a distinct operational fact; there is no filler.

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

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

For a 10-parameter mutation with no output schema and a nested merge_tags object, the description covers the highest-risk decisions (mode selection, credit cost, irreversibility, user confirmation). Only minor gaps remain, such as reply_to semantics and what a success response contains.

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 60%, so the description partially compensates by adding the critical constraint the schema does not encode: give html OR template_id, not both, and merge_tags must cover every tag in the template. That prevents a real invocation error; reply_to params remain unaddressed but are optional and self-named.

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 and scope: 'send a single one-to-one email to one recipient through Mail Blaze.' Explicitly contrasts with campaign/bulk paths, so the agent can separate it from mailblaze_create_campaign 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?

States the negative case ('Not for bulk or marketing mail; use a campaign for that') and names the alternative. Also adds a procedural gate: 'Confirm the recipient and content with the user before calling.' Both when-not and a prerequisite are explicit.

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

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

Adds real context beyond the annotations: the default account-level local blacklist side effect and the fact that the subscriber record is retained rather than deleted. It does not explain whether that blacklist entry persists against a later resubscribe, nor why the call is flagged non-idempotent, so the behavioral picture is good but 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?

Four short sentences, front-loaded with the operation class and the core effect, then side effects, then the permission condition. No sentence 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 destructive, non-idempotent mutation with no output schema, the description covers the effect, side effect, and retention adequately, but leaves the two required identifiers totally unexplained and gives no hint of the response or of how to undo via resubscribe.

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 neither parameter is described anywhere. The description only alludes to them indirectly ('this list', 'subscriber') without saying what a list_uid or subscriber_uid is, where to obtain one, or whether the subscriber must already exist in that list.

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 ('set a subscriber's status to unsubscribed') and scopes it to 'this list', which separates it from mailblaze_update_subscriber (field changes) and mailblaze_resubscribe_subscriber (the inverse). The 'WRITE:' prefix makes the operation class immediately legible.

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?

'Do this only when the person asked to stop (or a data-protection request requires it)' gives an explicit when-to-use condition and a clear restraint. It does not name the sibling alternates (update_subscriber for other statuses, resubscribe to reverse), so it stops short of full 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?

Adds real context beyond annotations by disclosing partial-update semantics ("only the values to change") and the scope boundary around subscription status. However, annotations declare destructiveHint=true and the description never explains what that means here – e.g. that sending first_name/last_name overwrites existing values and blanking is not possible – so an agent could read this as a harmless patch.

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

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

Three short sentences with the operation type and mutable fields front-loaded, then the parameter rule, then the exclusion. No filler, and every clause carries distinct 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?

Covers the hello-world of the call – what can change and what cannot – for a tool with a nested custom_fields object and no output schema. It omits behavior when the subscriber or list_uid does not exist, what the response contains, and any mention of the destructive overwrite semantics, which is meaningful for a 6-parameter mutation.

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

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

Schema coverage is only 33%, and list_uid and subscriber_uid have no description in either the schema or the description, leaving two of three required parameters unexplained. The description does add the useful "only the values to change" semantics and reinforces the required-email rule (which the schema also states), partially offsetting the coverage gap.

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

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

Opens with an explicit "WRITE:" marker followed by a specific verb and resource ("update a subscriber's name or custom fields"), so the mutation type and editable surface are unambiguous. The closing clause "Does not change subscription status" separates it from mailblaze_unsubscribe_subscriber and mailblaze_resubscribe_subscriber without those tools being 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?

Gives a clear selection context: send only the fields to change, plus the email Mail Blaze requires. "Does not change subscription status" implicitly routes status changes elsewhere, but no sibling tool is named explicitly and no prerequisite (e.g. subscriber must already exist in the list) is stated.

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