Ballast - Cold Email

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

Annotations only say it is a non-read-only, non-destructive, closed-world write. The description goes further by disclosing the side effect chain: the domain is registered, saved, and verification is immediately initiated across MX, SPF, DKIM, DMARC and blacklists. It stops short of stating whether the call is idempotent, what happens if the domain already exists, or what auth/plan is required.

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

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

Front-loaded with purpose, then verification detail, then routing rules — a sensible order. The verification acronym list is a little dense but is genuinely informative; overall only minor redundancy between the title sentence and the first description sentence.

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-param mutation tool with no output schema and thin annotations, the description covers the critical unknowns: what it creates and what verification it kicks off. What's missing is the failure/duplicate-domain behavior and whether the response contains the DNS records the user must publish.

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 with 0% schema description coverage, so the schema provides no format guidance at all. The description never says what 'domain' should look like (bare hostname vs. URL, subdomain handling, max length), leaving the agent to guess. Baseline 3 is the most this earns given the description adds nothing about the parameter.

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

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

States a specific verb+resource (connect/register a sending domain) plus the immediate consequence (DNS and deliverability verification). It explicitly separates itself from check_domain and list_domains, so an agent can pick it without opening any 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?

Contains an explicit USE THIS trigger ('setting up a new custom domain to send cold emails from Ballast') and two explicit DO NOT cases with named alternatives (check_domain for testing external/unverified domains, list_domains for listing). Nothing 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?

Annotations already declare a non-read-only, non-destructive, closed-world write, so the bar is lower; the description still adds genuinely useful behavior: leads already in the campaign, unsubscribed, bounced, suppressed, or failing address verification are silently skipped. It does not disclose the 5000/50 batch caps (left to the schema) or any permission 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 tight sentences with the core action front-loaded and the skip behavior second. No padding, though the title largely duplicates the first 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 batch mutation tool with no output schema, the skip semantics are the most valuable thing and they are present, but the description omits batch limits, the meaning of the required id, and whether adding a lead triggers any downstream send.

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 25%, so the description must carry weight: it maps 'from lists' to listIds and 'by id' to leadIds, which helps. It never explains that the required `id` is the campaign identifier, nor the allLeads mode, leaving two of four parameters 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 (add) and resource (leads to a campaign), and clarifies the two input modes ('from lists (or by id)'). It does not explicitly differentiate itself from the nearby sibling import_leads, so an agent must still infer which is appropriate.

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 says what happens but never when to use this tool versus import_leads or the various list_leads/list_lead_lists tools. No prerequisites, no exclusion conditions beyond the automatic skip rules.

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

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

Annotations only declare the safety profile (not read-only, not destructive, not open-world). The description adds real behavior beyond that: credentials are validated against both SMTP and IMAP before anything is persisted, implying partial failures do not create a mailbox. It stops short of covering storage of the password, duplicate-mailbox handling, or failure reporting.

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. The action and its validation gate come first, then the provider-specific credential caveats, which is the right ordering for an agent scanning before invocation.

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 dual-branch oneOf tool with no output schema, the description covers the essential decision inputs: validation semantics and provider-specific auth. It omits the shape of the smtp/imap configuration requirement and what a failed validation returns, leaving the agent to rely entirely on the schema for those.

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 high, and the schema itself carries const values, enums, patterns, defaults and length bounds, so the baseline is 3. The description contributes one meaningful mapping - Google requires an app password for the password field - but says nothing about dailyLimit, displayName, or the smtp/imap host, port, security and user fields.

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

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

States a specific verb and resource ('Connect a mailbox') and immediately adds the operational specifics of connecting (SMTP/IMAP test, save-on-pass). It clearly differs from the read-only sibling list_mailboxes, though it does not name any 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?

Provides concrete provider prerequisites: Google requires an app password, and Microsoft 365 is implicitly out of scope for this tool because it 'connects with OAuth from the dashboard.' That steers the agent away from an unsupported path, but there is no explicit statement of when to use this versus other mailbox-related siblings.

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

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

Annotations already establish write-but-not-destructive semantics; the description adds the important consequence that "Matching leads are marked suppressed" and the 10,000-value per-call cap. It does not, however, clarify whether existing suppressions are merged, whether invalid values cause the whole batch to fail, or what happens beyond the cap.

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

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

Two compact sentences, front-loaded with the action and followed immediately by the actionable format and limit details. Nothing is redundant or wasted.

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

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

With no output schema, the description does convey the effect on leads and the batch limit. It is nearly complete for a simple two-parameter write, though the omission of the reason parameter and any batch-failure semantics leaves a small 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. It explains the values parameter thoroughly (email vs. @domain format, 10,000 maximum), but the reason parameter is never mentioned anywhere, leaving its purpose unexplained.

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

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

States a specific verb ("Suppress") and resource ("addresses or whole domains"), and elaborates with the accepted value format ("emails, or domains written as @acme.com"). This clearly separates it from the similarly named add_domain, which concerns sending domains.

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 use case (blocking recipients/domains so matching leads stop being contacted) but never states when to use it versus alternatives, nor any prerequisites. There are no direct siblings in the list for managing suppressions, so nothing is actively misleading, but no explicit guidance is offered.

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 the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower, but the description still adds real value: it discloses a live external check, the specific record types inspected, that fix instructions are returned, and a 10-minute cache. It doesn't discuss rate limits or failure modes, 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?

Three tightly packed sentences: capability, behavioral detail, then routing guidance. Front-loaded and waste-free, though the opening sentence repeats the title verbatim, which is mild redundancy.

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

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

With no output schema, the description carries the burden of describing returns and does so by enumerating MX, SPF, DKIM, DMARC, blacklist status, domain age, and actionable fix instructions. An agent knows what it will get and when to reach for it.

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

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

Schema description coverage is 100%, so both parameters are already documented (domain accepts URLs/emails, selector is an optional custom DKIM selector). The description's mention of DKIM records loosely relates to the selector but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (inspect) and resource (DNS/deliverability health of a domain) plus the distinguishing constraint 'without adding it'. This lets an agent separate it from add_domain and list_domains without opening any 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?

Explicit USE THIS case (testing/grading arbitrary prospect or candidate domains without saving them) and two explicit DO NOT cases with named alternatives: add_domain for configuring, list_domains for viewing configured domains. Nothing 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?

Annotations already declare this is a non-destructive write. The description adds genuinely useful behavioral context beyond them: the campaign starts in draft (not launched) and begins with exactly one empty email, which sets expectations about initial state. It omits what the call returns and whether the campaign id is needed for the follow-ups.

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

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

Three short sentences, front-loaded with the action and then the next steps. No filler, and the sequencing instruction is placed where it is most useful.

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

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

For a simple one-parameter create with no output schema, the description covers purpose, initial state, and follow-up workflow. The one missing piece is what the tool returns (presumably a campaign id) that the named follow-up tools would need.

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

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

Schema description coverage is 0% for the single 'name' parameter, so the description could have explained it but does not. The parameter is self-evident and carries a default ('Untitled campaign'), which limits the harm, but by the rule for low coverage the description fails to compensate.

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 draft campaign') and the word 'draft' implicitly separates it from launch_campaign and update_campaign among the siblings. It does not explicitly name a sibling, so it stops short of full differentiation.

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 real workflow guidance: 'Use set_sequence to write the emails, then add leads and mailboxes,' which tells the agent the ordering of follow-up tools. It does not state when to avoid this tool or when update_campaign would be preferred, so it is not 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, and openWorldHint=false, covering the safety profile. The description adds essentially nothing beyond that: no auth requirements, no indication of what 'this period' means (billing cycle? month?), and no return or pagination behavior. With annotations carrying the burden, the description's lack of any added behavioral context caps this low.

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 noun phrase with no filler or redundancy. It is front-loaded and wastes no words, though it is a sentence fragment rather than a properly structured statement of purpose.

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 zero-parameter read tool with no output schema, the description partially compensates by listing the returned items (plan, subscription status, emails, AI drafts used). However, it never states the verb, never clarifies the time window, and gives no sense of the response shape, leaving it only minimally adequate.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter syntax for the description to clarify, and it introduces none.

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 is a verbatim restatement of the tool title, with no verb stating that it retrieves data. It does enumerate the resources involved (plan, subscription status, emails, AI drafts used), which hints at content, but an agent gets this same information from the title alone, making it a tautology rather than a distinct statement of purpose.

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 call this tool versus siblings such as get_overview or get_campaign_stats, nor any prerequisites or exclusions. The only contextual hint is the phrase 'this period,' which is not enough to route an agent between 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds only the scope of returned content (sequence, schedule, settings), with nothing about not-found behavior, permissions, or 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?

A single short sentence with no filler, and the resource is front-loaded. It is efficient, though the brevity is partly under-specification rather than discipline.

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 get-by-id tool with annotations and no output schema, the description is minimally adequate: it identifies the resource and the rough shape of the response. It omits identifier expectations and failure modes, which the empty schema descriptions do not cover.

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

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

There is a single required parameter, 'id', and schema description coverage is 0%, so the description carries the burden of clarifying it. It says nothing about which identifier is expected (campaign id format, where it comes from), leaving the parameter documented only by its bare name.

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

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

The description names a verb (Get) and resource (campaign) and hints at returned content (sequence, schedule, settings), so the purpose is inferable. However, it is a verbatim restatement of the title and does nothing to separate this tool from siblings like list_campaigns, get_campaign_stats, or get_campaign_analytics.

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 at all. With siblings such as list_campaigns, get_campaign_analytics, get_campaign_stats, and get_launch_checklist, the agent gets no signal about when a single-campaign fetch is appropriate versus those 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?

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context by specifying that results are granular aggregates partitioned by provider (Google Workspace, Microsoft 365), individual mailboxes, and reply sentiment. It stops short of describing response shape, sorting, or any latency/limit behavior, which keeps it out of the top band.

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

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

Three sentences, each doing distinct work: identity/dimensions first, return semantics second, routing rules last. Front-loaded with the payoff and free of filler or restated name 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 one-parameter, read-only analytics tool with no output schema, the description supplies enough to call it correctly and interpret roughly what comes back. It does not clarify the granularity of the returned aggregates (e.g., ordering, nesting per dimension) or the fact that the numeric 'days' field only meaningfully accepts 7/30/90, leaving minor gaps.

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

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

Only one parameter exists and schema description coverage is 100%, so the schema already defines 'days' with its 7/30/90 guidance. The description adds no range, default, or semantics beyond that, which is the expected baseline for a single fully-documented parameter.

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

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

Names a specific analysis resource and enumerates the three breakdown dimensions (provider, mailbox, sentiment), which is far more precise than the generic name suggests. It explicitly distinguishes itself from get_campaign_stats and get_overview, so an agent can route correctly without opening sibling schemas.

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

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

Contains an explicit 'USE THIS to diagnose deliverability issues across providers or compare mailbox performance' trigger plus two 'DO NOT use' exclusions that each name the correct alternative tool and the condition selecting it. Nothing about when to prefer this tool 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?

Annotations already establish read-only, non-destructive, closed-world behavior. The description adds value beyond them by enumerating the returned metrics and the time-window scoping, which matters because there is no output schema. It stops short of describing granularity guarantees, timezone/day-boundary handling, or behavior when campaignId is omitted versus invalid, so it is not 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?

Three tightly packed sentences, front-loaded with purpose and return contents, followed by usage routing. No filler and every clause carries selection-relevant 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 takes on the burden of describing return values and does so (day-by-day sent/replied/opened/bounced/positive), plus scope and access pattern (campaign vs all). Annotations cover safety. Nothing essential for correct invocation is missing.

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

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

Schema coverage is only 50% (campaignId is undescribed in the schema), so the description must compensate. It does: 'pass campaignId' implies a specific campaign versus omitting it for all campaigns combined, and 'over the last N days' explains the days window. It does not explain valid range, non-7/30/90 values, or invalid-ID handling.

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 resource and scope: daily time-series counts (sent, replied, opened, bounced, positive) for one campaign or all campaigns over N days. It explicitly names the two sibling tools it is not (get_overview, get_campaign_analytics), so an agent can disambiguate without opening schemas.

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

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

Explicit USE THIS case (plotting charts, viewing daily trends over time) and explicit DO NOT cases with named alternatives for both workspace-level totals and multi-dimensional breakdowns. When/when-not/alternatives are all covered.

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

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

Annotations already establish readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description usefully discloses severity semantics (required items block launch, warnings are advisory), which is genuine behavioral context beyond the annotations, but it says nothing about permissions, what entity the checklist applies to, or result format.

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

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

Two tight sentences with no filler, and the key constraint (required items block the launch) is front-loaded after a brief purpose statement.

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

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

There is no output schema, so the description should carry more of the return-value burden. It explains the two severity tiers but omits pagination/shape, and the undocumented required 'id' parameter leaves an agent unable to call it correctly — a significant gap for a 1-param 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 description coverage is 0% for the single required 'id' parameter, and the description never mentions it. The critical ambiguity — whether 'id' is a campaign, domain, or user id — is left entirely to inference, so the description fails to compensate for the schema 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 first sentence is a verbatim restatement of the title rather than a description of the operation, so the agent must rely on the tool name ('get_launch_checklist') to infer that it retrieves a checklist. The second sentence adds real meaning by defining what the returned items mean (required vs. warning), which lifts it above pure tautology, but the resource queried is never 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?

No indication of when to call this versus launch_campaign or preview_campaign, nor any prerequisite (e.g., 'call before launch_campaign'). The description only characterizes the output, never the usage context.

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=false, and destructiveHint=false, so the safety profile is covered. The description adds relevant behavior beyond that: it returns macro-level aggregate counts across the entire workspace, compares against the prior period for trend analysis, and constrains results to 7, 30, or 90 days. It does not cover permissions, rate limits, or response structure, but it adds meaningful context for a read-only aggregate.

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 three sentences and front-loads the purpose, then return details, then routing guidance. There is minor redundancy between the first sentence and the title, and between 'aggregate totals' and 'macro-level aggregate counts,' but no wasted instruction and the structure is easy to scan.

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 must describe the result, and it does: workspace-wide macro aggregates, the metric list, the time windows, and prior-period comparison. Combined with annotations that cover safety and a fully documented single parameter, an agent has enough information to call the tool correctly.

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

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

Schema description coverage is 100%, and the single 'days' parameter is already documented with its allowed values. The description reinforces the 7/30/90-day window but adds no new semantics such as default behavior, format, or filtering effects. This is the expected baseline when the schema carries the parameter 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 states a specific verb-resource: returns workspace-wide aggregate email outreach totals and trends. It lists the exact aggregate counts (total sends, replies, positive replies, bounces, won deals) and the 7/30/90-day windows, and names the two sibling alternatives it should not replace. This clearly distinguishes it from get_campaign_stats and get_campaign_analytics.

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 explicit when-to-use guidance: 'USE THIS for high-level workspace executive summaries.' It also gives explicit when-not-to-use guidance and names alternatives: 'DO NOT use for a single campaign (use get_campaign_stats instead) or for provider/mailbox breakdowns (use get_campaign_analytics instead).' No inference is required.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description only gestures at return contents ('every message, the campaign emails and the lead') and says nothing about pagination, ordering, or what happens with an invalid id — minimal added value beyond structured data.

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

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

It is a single short sentence with no filler, which is good, but the brevity stems from under-specification rather than economy — nothing is front-loaded because there is nothing to order.

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 is the only place return shape can be described, and it gives just a bare enumeration. It omits how to source the id, relationship to sibling list/read tools, and any detail about message volume or ordering.

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 0% and the single parameter 'id' is undocumented in both schema and description; the text never states that id refers to a thread id or where to obtain one (e.g., from list_threads). With one required param the gap is small but entirely unaddressed.

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 text is a verbatim repetition of the title and is a noun phrase rather than a verb+resource statement; it never says it retrieves a thread by id. It does hint at payload contents (messages, campaign emails, lead), but an agent still can't distinguish it from list_threads or get_campaign on the strength of this line.

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 indication of when to use this tool rather than list_threads, get_campaign, or label_thread, and no prerequisites or exclusions are given. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds nothing beyond that: no mention of scoping, rate limits, or what the counts represent/whether they are live or cached.

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, but it is also the entire content and duplicates the title, so brevity here reflects under-specification rather than disciplined editing.

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 parameters, the description carries the burden of explaining what comes back. 'Counts by label, mailbox and campaign' gestures at the return shape, which is the minimum viable, but nothing about ordering, time window, or scope is stated.

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. The three grouping dimensions mentioned align with the (empty) input and prefigure the response shape.

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 is a verbatim restatement of the title ('Unibox counts by label, mailbox and campaign'), so it adds no new signal. It does hint that this is an aggregation/counting resource with three grouping dimensions, which keeps it above a pure tautology, but there is no distinguishing detail versus the many other 'get_*' siblings.

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, when-not-to-use, or alternative is named. With siblings like get_overview, get_campaign_stats and list_threads all plausibly returning aggregate views, an agent gets no help deciding between them.

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?

Goes well beyond the destructiveHint/openWorldHint annotations: it discloses dedup, suppression skipping, invalid counting, background ESP detection and verification, and — importantly — the two-step confirmation returning a preview and confirm_token. This tells the agent the exact state machine and side effects of a destructive operation.

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

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

Front-loads the core purpose then layers the protocol efficiently in five sentences. Dense but nearly every sentence earns its place; no significant padding.

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

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

For a destructive 10-parameter batch import with no output schema, the description covers the full lifecycle including the confirmation gate and background processing. Minor gaps remain around error recovery or how previews are structured, but it is complete enough 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?

With 60% schema coverage, the description meaningfully augments the coordination parameters: importId, final, and confirm_token are all given workflow semantics that the schema alone doesn't fully convey. It doesn't cover every parameter, but the critical ones are explained well beyond schema text.

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 (import) and resource (leads) along with the chunked batch protocol, which clearly separates it from siblings like add_leads_to_campaign. An agent can identify the operation 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?

Explains when the chunking protocol applies (first call creates the import, subsequent calls pass importId, last passes final: true) and the confirmation flow. It doesn't name an alternative tool or explicit when-not-to-use condition, so it stays at 4.

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

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

Annotations only supply generic hints (readOnlyHint=false, destructiveHint=false), so the description carries most of the burden and does well: it discloses that the lead inherits the label and that the label's triggers fire (suppress, stop in campaign, pause campaign, move to list). That side-effect chain is exactly the consequential behavior an agent needs before mutating state. It stops short of 5 by omitting auth requirements or failure 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?

Three short sentences, front-loaded with the action and then the consequences, with no filler. The only inefficiency is that sentence one repeats the title word-for-word before adding new 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 two-parameter mutation tool with no output schema and only hint-level annotations, the description covers purpose, the null-clear mechanism, and the trigger side effects. The remaining gap is parameter identity for 'id' and any error/permission expectations.

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 explain both parameters. It does explain labelId well (null clears the label, and the lead receives it), but the 'id' parameter is never disambiguated as thread id versus lead id, and the mention of both 'thread' and 'lead' in one sentence adds confusion. Partial compensation warrants a 3.

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

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

The opening sentence names a specific verb (set/clear) and resource (a thread's label), and the description goes on to explain both modes, including that null performs the clear. It is clear but the lead sentence duplicates the title verbatim and adds no sibling context, so it falls just 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?

Usage is only implied: the reader learns that passing null clears the label, which is a usable instruction, but there is no explicit when-to-use, when-not-to-use, or named alternative. No sibling tool overlaps this function, so the missing guidance is low-risk but still absent.

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 mark this as destructive and non-read-only, and the description earnestly adds context beyond them: checklist validation that can refuse the call, sending constrained to the schedule window, and a mandatory preview/confirm_token confirmation gate. It doesn't say whether the launch is reversible or what permissions are required.

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

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

Four short sentences, front-loaded with the action, then the gating rule, then the confirmation mechanic. Every sentence carries distinct information with no repetition or 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 responsibly covers return behavior (a preview plus confirm_token on the first call) and failure behavior (refusal on a failed checklist item). It leaves some gaps: whether the id is a campaign identifier, and whether the confirmed call returns a success status or job handle.

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?

At 50% schema coverage, the description should compensate. The confirmation-flow sentence maps onto confirm_token, but that same behavior is already spelled out in the schema description, so it adds little; the required 'id' parameter is never characterized in either place. Baseline 3 is warranted.

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 ('Launch or resume a campaign') and adds scope detail (checklist gating, schedule window). It doesn't explicitly contrast with close siblings like pause_campaign or preview_campaign, though the two-step preview flow implies the distinction.

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

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

Explains the operating context clearly: the launch checklist runs first and the call refuses on a failed required item, and the call is a two-step confirm flow. It stops short of naming alternatives (e.g., get_launch_checklist to pre-verify, preview_campaign for a read-only view) or stating 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds genuinely useful behavioral context, sort order and the presence of lead counts per progress stage, but says nothing about pagination, result limits, or the shape of the response.

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 terse sentences with no filler, and the ordering/output detail is front-loaded right after the core statement. The phrasing is fragmentary but every clause carries information not available in the structured fields.

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 signals that results are sorted newest-first and include lead counts. However, for a list endpoint it omits the status filter explanation, pagination/limit behavior, and what an omitted status means, so an agent cannot determine the default result set.

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 description never mentions the one available parameter, an array-based status filter accepting draft/running/paused/completed. The description therefore does not compensate for the coverage gap, leaving the filter's semantics (multi-value OR filtering vs. something else) undocumented 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 names a specific verb and resource ("List campaigns") and adds scope detail with result ordering and included aggregates ("Newest first, with lead counts by progress"). It does not, however, differentiate itself from siblings like get_campaign or list_leads, so the reader must infer the distinction.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no naming of alternatives such as get_campaign for a single campaign. The only hint at a filter is the undocumented status parameter, so usage must be inferred entirely from the schema.

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=false, so the safety profile is covered. The description adds genuine value beyond that by enumerating what the call returns (mailbox count, latest deliverability scores, verification history). It does not mention result size limits or ordering, which is the only 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?

Three tightly written sentences with no filler: purpose and return payload first, then the usage directive and its exclusions. 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?

For a zero-parameter read tool with no output schema, the description compensates by naming the fields returned and cleanly delineating it from both adjacent siblings. Nothing an agent needs in order to select or invoke it 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 all connected sending domains') plus the scope of what is returned, which distinguishes it immediately from the sibling tools add_domain and check_domain. Title and description are aligned and non-tautological.

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 says 'USE THIS to review existing sending infrastructure' and then excludes two adjacent cases by name, routing to add_domain for registration and check_domain for testing external domains. Both when-to-use and when-not-to-use are stated with the alternative tool named.

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=false, so the safety profile is covered. The description adds nothing beyond the title, contributing no context about return shape, pagination, or data scope.

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 words is technically concise and front-loaded, but this is under-specification rather than conciseness. The single fragment carries almost no information an agent can act on.

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?

The tool is simple (no params), but with no output schema the description should at least hint at what a 'lead list' contains or what the counts represent. As written, an agent cannot tell what it will receive or why this differs from list_leads.

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

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

The tool takes zero parameters, so the baseline for this dimension is 4. There are no parameter semantics to add or omit; the schema is trivially complete.

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 is a verbatim restatement of the tool title ('Lead lists with counts'), making it a tautology rather than a statement of what the tool does. It does hint that counts are returned, which weakly separates it from the sibling list_leads, but no verb or scope is given.

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 call this tool versus alternatives such as list_leads, list_campaigns, or list_domains. The agent must infer the intended context entirely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the default ordering and paging behavior, but says nothing about result shape, size limits, or pagination bounds beyond the schema defaults.

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, purpose front-loaded, and every clause earns its place by enumerating a distinct filtering axis. No filler or restated title.

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

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

For a 10-parameter tool with no output schema, the description covers the calling semantics well but omits pageSize, the meaning of individual enum values, and any hint about the returned lead structure. Adequate for invocation but not fully complete.

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

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

Schema coverage is only 20%, so the description must compensate — and it does, mapping nearly every parameter to a human concept: list (listId), label (labelId), status, verification (verify), ESP (esp), and search scope (email, name, company), plus sort direction. Only pageSize semantics and enum values are left undocumented.

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

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

States a specific verb+resource ('List leads') and immediately scopes it with paging, default ordering, and the filter/search dimensions. It's clear enough to separate from list_lead_lists or list_campaigns, though it doesn't explicitly name a sibling it is not.

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 useful context on how to use it (paging, newest-first default, filter-by-field-or-search), which implies the filtering usage pattern. However, it never states when to prefer this over an alternative or any prerequisites / exclusion, so guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description's added value is naming the returned data (today's limit, ramp-up, domain DNS health), which tells the agent this is live operational status rather than a static config list. It says nothing about ordering, pagination, or auth requirements, so it adds some but not rich context.

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

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

Two short sentences, zero filler, with the resource named first and the returned data front-loaded immediately after. Nothing redundant and nothing that could be cut 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?

With no output schema present, the description carries the burden of explaining returns and does so at a high level (limit, ramp-up, DNS health). Combined with zero parameters and read-only annotations, an agent has enough to call it correctly, though the exact response shape for each field is still unspecified.

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

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

The tool takes no parameters, so the baseline is 4 and there is no schema semantics to compensate for. The description instead characterizes the shape of each returned mailbox entry, which is useful but belongs to return content rather than parameter meaning.

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

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

States a specific verb and resource ('List mailboxes') and then scopes it: connected sending mailboxes with today's limit, ramp-up, and domain DNS health. This distinguishes it from list_domains, list_campaigns, and list_leads in the sibling set. It stops short of naming a sibling to contrast against, which keeps it off a 5.

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

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

There is no explicit statement of when to call this versus alternatives, nor any prerequisites or exclusions. Usage is only implied by the returned fields (limits, ramp-up, DNS health), which suggests an operational health-check context. Adequate but leaves the agent to infer the trigger condition.

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 the safe read-only profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds two genuinely useful behaviors beyond that: results are sorted newest-first, and pagination is driven by a cursor token returned in the previous answer.

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 that front-load the resource/ordering before filters and paging. The only waste is the opening 'Reply threads, newest first', which repeats the title verbatim rather than adding 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 six-parameter list tool with no output schema and 33% schema coverage, the description is only minimally complete. Cursor semantics ('from the previous answer') are vague, and mailboxId/campaignId/cursor have no explanation in either the schema or the description.

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%, so the description must compensate. It maps five of six parameters to concepts (unread->view, label->labelId, mailbox->mailboxId, campaign->campaignId, cursor), but adds no format or syntax detail and omits the search parameter entirely.

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 the resource ('reply threads') and its ordering ('newest first') precisely, and names the filter dimensions. It clearly differs from the singular get_thread sibling, though it does not name that alternative 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?

Gives useful invocation context: filter by unread/label/mailbox/campaign and page with cursor from the previous answer. However, there is no guidance on when not to use it or when to prefer get_thread or another sibling, so usage is implied rather than fully 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 is a non-read-only, non-destructive operation. The description adds meaningful operational context beyond annotations: no more sends until relaunch, and emails already handed to the provider still arrive.

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

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

Three short sentences, front-loaded with the action and followed by two precise consequences. Every sentence adds value with no filler.

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

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

For a simple one-parameter mutation, the behavioral consequences are fully covered and annotations carry the safety profile. The only missing piece is explicit identification of the required id 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?

The sole parameter 'id' has 0% schema description coverage, and the description never identifies it as a campaign ID or states its format. With no schema prose, the parameter's meaning is only implied by the tool name.

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 ('Pause') and resource ('campaign') scoped to a 'running campaign'. The purpose is clear, though it does not explicitly contrast with sibling tools like launch_campaign or update_campaign.

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 supplies clear usage context: pausing stops further sends until relaunch. It does not state when not to use it or explicitly name launch_campaign as the resume alternative.

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

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

Annotations already establish the safe read-only profile, and the description adds genuine context beyond them: spintax is resolved as it will be for that lead, and omitting leadId defaults to the first lead in the campaign. It still does not state that nothing is sent or how the rendering is returned, but it adds meaningful behavioral detail.

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 the core action front-loaded, followed by the rendering behavior and the default. Every sentence adds information and there is no padding.

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

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

For a low-complexity, read-only preview with no output schema, the description covers what is rendered, how spintax is handled, and the fallback when leadId is absent. The main gap is not identifying the 'id' parameter's target resource.

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% with two parameters, so the description must carry the load. It usefully explains the leadId default ('first lead in the campaign') but never clarifies what the required 'id' refers to (campaign vs. lead), leaving half the parameters ambiguous.

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: 'Render every step and variant for one lead,' which clearly separates it from plain readers like get_campaign or get_campaign_stats. It does not name any sibling tool to route against, so it falls short of the top band's explicit differentiation.

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

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

Usage is only implied — an agent can infer this is for previewing how a campaign looks to a specific lead, likely before launch. There is no statement of when to prefer this over get_campaign or set_sequence, and no prerequisites or exclusions are given.

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

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

Annotations declare the safety profile (destructiveHint=true, readOnlyHint=false, openWorldHint=false), and the description adds substantial behavior beyond them: mailbox selection, threading headers, reply target, quoting of the prior message, and the mandatory two-step confirmation gate. This is exactly the kind of context a write tool benefits from.

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 purpose, followed by precise operational details and the confirmation flow. Four short sentences, none 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?

No output schema exists, so the description must cover the interaction model, and it does via the preview/confirm_token flow. Minor gap: id and the exact effect of text/quoting behavior could be stated explicitly, but overall an agent can call this 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 33% (confirm_token is documented in the schema). The description reinforces confirm_token semantics and implies text is the reply body and id is the thread, but it never explicitly defines id or text, so it only partially compensates for the low coverage.

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 ('Answer a thread' / 'Sends...') and rich scoping detail (sends from the conversation's mailbox, in-thread via In-Reply-To/References, to the last writer). This clearly separates it from the read-oriented siblings like get_thread and label_thread.

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?

Describes the confirmation workflow in detail (first call previews + returns confirm_token; call again with the token to send), which is the key usage pattern an agent needs. It does not, however, advise when to prefer this over e.g. get_thread first to read context, so it stops short of explicit alternatives/exclusions.

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

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

Annotations only declare readOnly=false, openWorld=false, destructive=false; the description adds the meaningful state precondition (drafts/paused only) plus content-format rules (plain text blank-line paragraphs, simple HTML, template/spintax syntax, mandatory {{unsubscribe}} in the first email). That is real behavioral context beyond the structured fields, though it says nothing about what happens to the prior sequence or about validation failures.

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 replacement semantics are front-loaded, followed by the nested-shape rules and then the templating vocabulary; each clause adds information no other field supplies. The templating sentence is dense but still readable, and there is no padding.

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

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

For a two-parameter but deeply nested write tool with no output schema, the description covers structure and templating well but omits the meaning of `id`, the timing fields (waitDays, sameThread), variant weighting/activation, and confirmation of what happens to the previously stored sequence. It is adequate to attempt a call but not to call it confidently in edge cases.

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 carries the documentation burden, and it does explain the shape of `steps`: ordered, 1–5 variants each, body as text or HTML. However it never explains `id`, nor the per-step `waitDays`/`sameThread` or per-variant `subject`/`active`/`weight`, leaving several parameters undocumented in both schema and description.

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

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

The description opens with a concrete verb+resource ('Replace the whole sequence') and the title reinforces it, so an agent immediately knows this is a full overwrite rather than an incremental edit. It does not name the sibling write_sequence, which is the natural alternative for non-replacement edits, so sibling differentiation is only implied by the word 'whole'.

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 eligibility condition ('Only drafts and paused campaigns'), which tells the agent when the call will succeed versus fail. It stops short of naming write_sequence as the alternative for already-launched campaigns, so the routing guidance is incomplete but still actionable.

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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered, but the description adds no behavioral context whatsoever: no note that changes are applied immediately, whether they are reversible, or that replacing mailboxes alters live sending. With annotations already doing the safety work, the bar is lower, yet the description still contributes nothing beyond the title.

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 a single front-loaded sentence with zero filler, which is structurally clean. But for a 17-parameter mutation tool the brevity crosses from concise into under-specified, so the sentence does not really earn its place as the tool's only guidance.

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?

Given a 17-parameter mutation tool with no output schema, minimal annotations, and only 59% schema description coverage, the one-sentence description is far too thin. An agent cannot infer partial-update semantics, side effects on live campaigns, or the meaning of the undocumented parameters from this definition.

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 59%, leaving roughly seven parameters (name, windowStart/windowEnd, trackOpens, trackClicks, espMatching, stopOnReply) with no documented meaning in either the schema or the description. The description mentions 'schedule, mailboxes and options' at such a high level that it adds no semantic detail beyond what the schema already encodes, so it fails to compensate for the coverage gap.

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

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

The description names a verb (rename/change) and a resource (campaign) plus rough field groups (schedule, mailboxes, options). However, it is a verbatim restatement of the title and 'options' is a catch-all that tells an agent nothing about the 17 mutable fields. It also does nothing to distinguish this tool from siblings like pause_campaign, set_sequence, or launch_campaign, which also alter campaign state.

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

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

There is no guidance on when to use this tool versus pause_campaign, launch_campaign, set_sequence, or write_sequence, and no statement of prerequisites (ownership, permissions, campaign state). Critically, it never says whether this is a partial update (omitted fields preserved) or a full replacement, which is the single most important routing decision for a 17-parameter mutator.

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=false, so the safety profile is covered. The description adds only mild context via 'behind this key or session,' hinting that either credential type resolves to the same identity, but there is no detail on rate limits, caching, or auth failures.

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 words. It is arguably too short to carry usage guidance, but nothing is padded or repetitive.

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 must hint at return values — and it does by naming user, workspace, and plan. For a trivial zero-param read tool this is close to sufficient, though exact field shapes remain unknown.

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, which is the baseline-4 case. The description correctly implies no inputs are needed, and there is nothing further to document.

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 clarifies what the tool returns — the user, workspace, and plan — which 'whoami' alone does not convey, so it is more than a pure name restatement. However it is verbatim the title and lacks a clear action verb, leaving the purpose 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?

There is no guidance on when to use this tool versus any sibling. For a zero-argument identity probe the use case is largely self-evident, but the description does not state it (e.g., 'call first to resolve the active workspace before other calls').

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 substantial context beyond the annotations: results are saved as new variants and never overwrite existing text, an empty campaign receives the drafted steps, each email is validated against a content checklist, and failures are returned in 'problems'. It also discloses the offer-profile configuration prerequisite and the update_offer_profile path, which annotations alone do not convey.

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

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

Front-loads the core action, then layers mode meaning, safety behavior, validation, and prerequisites in logical order. Length is justified by the tool's complexity, though the opening sentence partially repeats the title.

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

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

With no output schema, the description carries the burden and does so reasonably: it explains what gets produced (new variants, drafted steps for an empty campaign) and what comes back on failure (problems list). A short note on how the produced variants relate to the campaign id would make it 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 83% and the schema already documents mode, angle, steps, persona, and variantId, so the description's restatement of the modes adds little. It does clarify that drafts draw 'only on facts from the offer profile and lead fields', but the naming overlap between the 'angle' mode and the 'angle' notes parameter is left to the schema to disambiguate.

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 ('Write emails with AI from the offer profile') and immediately enumerates the two operational modes (draft a full sequence vs. a new version of one variant). It does not explicitly contrast itself with the related sibling set_sequence, but the scope 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?

Gives clear context for each mode ('sequence = draft every step; rewrite, shorter, angle = a new version of one variant') and states a prerequisite: the workspace's offer profile must be configured, otherwise use update_offer_profile. No explicit when-not-to-use beyond the prerequisite.

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