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

No annotations are provided, so the description carries the full burden, and it does well: it discloses that the call mutates state (registers and saves the domain) and that verification is initiated immediately with a named checklist (MX, SPF, DKIM, DMARC, blacklists). It does not say whether verification is synchronous or async, what happens on duplicate domains, or whether the operation is reversible/removable, which keeps it short of a 5 for an unannotated mutation tool.

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

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

Front-loaded with the action, then the mechanics, then routing guidance — a logical order with no filler. The 'DO NOT' sentence is somewhat long, but each clause carries distinct routing information that an agent needs.

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

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

For a one-parameter mutation tool with no annotations and no output schema, the description covers the action, side effects, verification scope, and sibling routing well. The remaining gap is post-call behavior: nothing about duplicate-domain errors, verification latency, or what the caller gets back.

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%, so the description must compensate for the single 'domain' parameter, and it only partially does: it implies the value must be a domain the user owns and that gets added to the workspace, but gives no format guidance (bare apex domain vs. subdomain vs. URL, no protocol). The schema contributes only a maxLength constraint.

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 a new sending domain to the workspace') and immediately elaborates the concrete action: registering, saving, and kicking off DNS/deliverability verification. It explicitly distinguishes itself from check_domain and list_domains, so an agent can route correctly 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 explicit 'USE THIS when...' guidance for the intended scenario and two 'DO NOT use...' exclusions naming the correct alternative for each (check_domain for testing an external/unverified domain, 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?

With no annotations, the description carries the burden and does disclose meaningful partial-skip semantics: already-in-campaign, unsubscribed, bounced, suppressed, and invalid-address leads are skipped rather than erroring. However, it says nothing about permissions, idempotency, rate limits, or what the response reports about skipped leads.

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 stating the action, then the skip conditions. Slightly run-on with the trailing list of skipped categories, but no padding or repetition.

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

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

For a 4-parameter mutation tool with no annotations, no output schema, and 25% schema coverage, the description covers the core action and skip semantics but omits parameter interaction rules and the allLeads option — gaps an agent must guess at.

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% (just allLeads), so the schema leaves leadIds and listIds essentially undocumented. The description compensates partially by signaling that leads can come from lists or by id, but it never mentions the allLeads option, the 5000/50 item caps, or whether the source parameters are combinable.

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 indicates the two source modes (lists or by id). It is distinguishable from siblings like import_leads, though it never explicitly names or contrasts them.

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

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

No guidance on when to use this versus import_leads or add_suppressions, and no prerequisites or mutual-exclusivity rules for the four source parameters. The only usage-adjacent content is the skip behavior, which is about outcome rather than tool selection.

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

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

With no annotations, the description carries the full burden and does well: it discloses the precondition (SMTP and IMAP login are tested first), the conditional write ('saves only when both pass'), and provider-specific auth requirements. It omits failure/error behavior details and any auth requirements for the calling client itself.

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 the two provider caveats; every sentence earns its place. Minor deduction for the missing punctuation in the opening sentence ('Connect a mailbox Tests SMTP...'), which creates a run-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?

For a tool with a two-branch oneOf schema and no output schema, the description covers the key selection-relevant facts (provider auth differences, validation-before-save) but says nothing about what a successful connection returns or how validation failures surface to the caller.

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 effectively high and the oneOf variants fully enumerate required fields per provider, so the schema does the heavy lifting. The description only adds meaning for the Google password case (app password), matching the baseline of 3.

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

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

States a specific verb+resource ('Connect a mailbox') and adds the save semantics, so an agent knows this persists a mailbox rather than merely testing credentials. It reads clearly against the sibling list_mailboxes, though no sibling is named explicitly.

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

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

Provides concrete routing context: Google requires an app password, and Microsoft 365 must be connected via OAuth from the dashboard, which strongly implies this tool is not the path for M365. It stops short of naming an alternative tool or stating exclusions outright.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: a 10,000-value per-call ceiling and the side effect that matching leads are marked suppressed. It omits permission requirements, reversibility, idempotency, and any note on partial failures within a large batch.

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

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

Three short sentences, front-loaded with the core action and then the volume limit and accepted formats. Nothing is padded and the limits appear before the side-effect note.

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

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

For a simple two-parameter, no-output-schema tool the description is close to sufficient: it covers what gets suppressed and the batch limit. It falls short on the unexplained `reason` parameter and on what the caller should expect back, since no output schema exists to fill that 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 compensate. It fully explains the `values` parameter (emails or @domain format, up to 10,000), but the `reason` parameter is never mentioned, leaving one of two parameters undocumented in both the schema and the description.

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

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

States a specific verb (suppress) and specific resources (email addresses or whole domains), plus the accepted domain syntax. No sibling tool performs suppression, so the agent can distinguish it from add_leads_to_campaign or list_leads at a glance.

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 never says when to reach for this tool versus alternatives, nor does it state prerequisites (e.g., whether suppression applies retroactively to existing campaigns or leads). Usage must be inferred entirely from the verb.

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

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

With no annotations, the description carries the full burden and does well: it declares the operation is live and read-only, enumerates what is checked, mentions actionable fix instructions, and discloses a 10-minute result cache. It stops short of stating auth/permission needs or any rate limits beyond caching.

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

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

Three sentences, front-loaded with purpose, then capability detail, then routing guidance. Every sentence earns its place with no redundancy against the schema.

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

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

For a two-parameter read-only diagnostic tool with no output schema, the description covers what is examined and that fix instructions are returned. Return structure is only lightly implied, but an agent has enough to call it 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% (domain format and optional DKIM selector are documented in the schema), so the baseline is 3. The description adds no parameter-level detail beyond 'any domain 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 (inspect) and resource (DNS/deliverability health of a domain) and immediately clarifies scope with 'without adding it' and the listed checks (MX, SPF, DKIM, DMARC, blacklist, domain age). It is clearly distinguishable from add_domain and list_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?

Explicit USE THIS for arbitrary prospect/candidate domains without saving, and DO NOT use for configuring (add_domain) or viewing configured domains (list_domains). Both alternatives and their selecting conditions are 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?

Since no annotations are provided, the description carries the full behavioral burden. It discloses a critical initial constraint ('Starts with one empty email'), which is vital behavioral context that goes beyond simply setting the campaign name.

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 concise and efficient, front-loading the action and immediately providing necessary context regarding the campaign's initial state and subsequent workflow.

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 the minimal input structure (one parameter), the description provides high value by detailing the campaign's starting state and mapping out the entire setup workflow, making it largely 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?

Despite the input schema being minimal, the description adds no semantic value to the parameters. It focuses entirely on the post-creation workflow and behavior, failing to compensate for the 0% schema description 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?

The tool clearly states its purpose: creating a draft campaign. It is highly contextual, establishing a specific starting state ('Starts with one empty email'), which helps distinguish it from a generic campaign creation utility.

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 excels in guiding the agent's subsequent actions. It explicitly tells the user the required next steps: 'Use set_sequence to write the emails, then add leads and mailboxes,' effectively defining the usage workflow.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the scope of returned data, including that usage figures are period-scoped ('this period'), which is genuinely useful context. However, it says nothing about read-only safety, permission requirements, or how the billing period is defined, leaving real gaps for a no-annotation tool.

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

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

A single front-loaded fragment with no padding, and the most important concept (plan/subscription) comes first. It is arguably too terse as a fragment rather than a sentence, keeping it out of 5 territory.

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

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

No output schema exists, so the description must convey return contents, and it does list the main fields. But it omits any usage guidance relative to get_overview/whoami and any behavioral notes, leaving the definition only minimally complete for a billing endpoint.

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

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

The tool takes zero parameters, so the baseline is 4 by rule. The description correctly adds no parameter guidance because none is needed; the empty schema is self-explanatory.

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

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

The name supplies the verb (get_) and the description specifies the resource contents: plan, subscription status, and usage counters for email sends and AI drafts. That is enough for an agent to know this returns account/billing state. It stops short of naming a sibling, so it does not reach 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 indication of when to call this versus adjacent tools such as get_overview or whoami, which likely surface overlapping account context. No prerequisites, no conditions, no exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the shape of the returned data (sequence, schedule, settings), which is real value with no output schema present, but says nothing about permissions, behavior on an unknown id, or error cases for a read tool.

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

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

A single front-loaded sentence with zero filler; the verb leads and every clause adds information about the returned payload.

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

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

For a simple one-parameter getter with no annotations and no output schema, the description covers purpose and returned content adequately. The remaining gap is what happens when the id doesn't resolve, which is minor for this complexity level.

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

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

One parameter (id) at 0% schema description coverage; the description never mentions it. It is a self-evident campaign identifier in context, but no format (string vs numeric, UUID) or failure behavior on a bad id is given, so it only marginally compensates for the coverage gap.

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

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

Clear verb+resource ("Get a campaign") plus the payload it returns (sequence, schedule, settings), which quietly distinguishes it from siblings like get_campaign_stats and get_campaign_analytics. It does not explicitly name those alternatives, but the returned-content hint makes the scope legible.

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

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

No when-to-use guidance and no mention of alternatives such as get_campaign_stats, get_campaign_analytics, list_campaigns, or update_campaign. The agent must infer that this is the single-campaign configuration fetch from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return shape at a high level (aggregate metrics broken down by provider, mailbox, sentiment), which is genuinely useful, but says nothing about read-only nature, permissions, rate limits, caching, or result size limits. Adequate but incomplete for an unannotated tool.

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

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

Three tight sentences: what it returns, when to use, when not to use. The identifying scope is front-loaded and every sentence carries routing or return information 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?

There is no output schema, but the description compensates by stating the breakdown dimensions and that results are aggregate metrics. Nothing an agent needs to call it correctly is missing; only finer-grained return detail (limits, ordering) is absent.

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

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

Only one parameter (days) and schema description coverage is 100%, with the allowed values 7/30/90 already documented in the schema. The description adds no syntax, default, or format guidance beyond that, so this is the baseline case where the schema does the heavy lifting.

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: a multi-dimensional performance breakdown by provider, mailbox, and sentiment. It goes further by naming the two sibling tools it is not (get_campaign_stats, get_overview), so an agent can disambiguate without opening a schema.

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

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

Explicit routing: 'USE THIS to diagnose deliverability issues across providers or compare mailbox performance,' followed by two 'DO NOT use' exclusions with the correct alternatives named for each. When/when-not/alternative 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?

With no annotations, the description carries the full disclosure burden, and it does well: it names the five returned metrics (sent, replied, opened, bounced, positive), the day-by-day granularity, and the scope (specific campaign vs. all combined over the last N days). It stops short of stating the read-only nature explicitly, pagination/row limits, or auth requirements, which is why it isn't 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 sentences, front-loaded with the core purpose before the USE/DO NOT routing rules, and each sentence carries information. The opening pair ('Daily time-series email metrics...' followed by 'Returns daily time-series counts...') is mildly redundant but not wasteful enough to hurt usability.

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

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

For a 2-parameter read tool with no annotations and no output schema, the description supplies the return structure, the aggregation semantics, and sibling routing — enough to call it correctly. Missing only edge details like default-window behavior confirmation and response envelope shape, which are minor here.

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 has no schema description), so the description must compensate — and it does, explaining that passing campaignId scopes to one campaign while omitting it aggregates all campaigns, and that days bounds the window. It adds real semantics beyond the schema, though it doesn't restate or clarify the allowed days values (7/30/90) or what happens with a nonexistent campaignId.

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

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

The description states a specific verb and resource ('daily time-series email metrics for a campaign or all campaigns') and explicitly distinguishes itself from both get_overview and get_campaign_analytics, including the shape of what it returns. An agent can identify this tool 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?

It gives an explicit positive trigger ('USE THIS to plot charts or view daily performance trends over time') plus two named exclusions with the alternative tool for each case (get_overview for summary totals, get_campaign_analytics for multi-dimensional breakdowns). Nothing about tool selection is left to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful semantics: required items block launch while warnings are advisory. However, it omits whether this is a safe read-only operation, permission requirements, and whether the checklist is static or derived from live campaign state.

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

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

Two short sentences with no filler, and the core meaning of the returned data is front-loaded in the second sentence. The missing period and fragmentary first clause slightly hurt readability.

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 and no annotations mean the description must do more work. It explains item severity but not the return shape, the identity of the id parameter, or the read-only/permission profile, leaving meaningful gaps for an agent invoking 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?

There is one required parameter (id) at 0% schema coverage, and the description never mentions it. An agent cannot tell from the description whether this is a campaign id, account id, or something else, 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 description makes clear the tool returns a pre-launch checklist of items that must be fixed, which is a specific resource distinct from siblings like get_campaign or launch_campaign. It reads as a fragment ("What has to be fixed before launch") with no explicit verb, but the intent is unambiguous.

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

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

It implies the checklist is consulted before launching, but never says when to call it, what prerequisites exist, or how it relates to launch_campaign, which is the obvious sibling in the same workflow. No exclusions or alternatives 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?

No annotations are provided, so the description carries the full burden, and it does well: it discloses the aggregate nature of the data, the exact metrics returned, the comparison-against-prior-period behavior, and the supported windows. It omits auth/prerequisite context and whether results are cached or live, which keeps it short of a 5.

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

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

Three sentences, front-loaded with the core purpose, then the usage guidance — every clause adds routing or behavioral 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 read-only aggregate tool with one optional parameter and no output schema, the description supplies purpose, metric inventory, trend semantics, and sibling routing. Nothing an agent needs to select or invoke it correctly is missing.

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

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

Schema coverage is 100% and the sole parameter's description already states '7, 30 or 90 days'. The description restates the same three windows in prose without adding format, default, or edge-case meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Workspace-wide aggregate email outreach totals and trends') and immediately enumerates the exact metrics returned. It explicitly distinguishes itself from get_campaign_stats and get_campaign_analytics, so an agent can differentiate it from siblings without opening a schema.

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

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

Contains an explicit USE THIS directive ('high-level workspace executive summaries') plus DO NOT clauses naming the two alternative tools and the conditions that select them (single campaign vs provider/mailbox breakdowns). Routing is unambiguous.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints at return contents (messages, campaign emails, lead) but says nothing about read-only nature, permissions, error behavior, or pagination; 'get' weakly implies a read but this is not disclosed.

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

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

It is short and wastes no words, but it is an ill-formed fragment rather than a front-loaded statement of purpose. Brevity is achieved at the cost of clarity.

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 getter with one required param and no output schema, the description partially covers return contents but omits what 'id' refers to and offers no usage context. An agent lacks enough to confidently invoke it against the right identifier.

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

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

The single required parameter 'id' has 0% schema description coverage, and the description never explains that this is a thread identifier or its expected format. With one undocumented param, 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 description is a noun phrase ('A thread with every message, the campaign emails and the lead') that describes the resource's contents rather than stating a retrieval action. It implies what you get back but never uses a verb, and it does not distinguish itself from the sibling list_threads, so the agent could confuse the two.

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 list_threads or other retrieval tools. No prerequisites, no exclusions, no alternative named — the agent must infer usage entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden and mostly fails it: it does not say the operation is read-only, what permissions are needed, whether results are scoped to a time range, or anything about the response shape. It only hints at the grouping dimensions of the returned 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 fragment with no filler, so it is not verbose. However, given the complete absence of annotations and output schema, this level of terseness is more under-specification than disciplined conciseness.

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

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

For a zero-parameter read tool with no output schema, the description's mention of counts grouped by label, mailbox and campaign serves as the only return-value signal, which is useful. Still, it omits when to use it and any behavioral context, so it is only minimally 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description introduces no parameter-related confusion.

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 phrase names a resource and the grouping dimensions ('Unibox counts by label, mailbox and campaign'), which tells an agent roughly what data comes back. But there is no verb, and the name says 'filters' while the description says 'counts', so it is unclear whether it returns filter options or aggregated counts. That ambiguity leaves the purpose only vaguely pinned down.

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?

Nothing states when to call this versus siblings like get_overview, get_campaign_stats, or list_mailboxes, nor are any prerequisites or exclusions mentioned. The agent must infer usage 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?

With no annotations, the description carries the full burden and does well: it discloses dedup, suppressed-skip, invalid-count behavior, background ESP detection/verification triggered by the final chunk, and the 5,000-row cap. It stops short of permissions requirements, error behavior on partial failure, or whether an import can be rolled back.

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

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

Roughly four sentences, front-loaded with the resource and the protocol, then the side effects. Every sentence adds an operational fact; nothing is a restatement of the name or schema.

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

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

For a 9-parameter, no-output-schema, no-annotation mutation tool, the description covers the call protocol and post-import processing well, and noting that the first call returns an id substitutes for a missing output schema. Missing only error/partial-failure behavior and permission needs.

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 56%, so the description must compensate, and it does for the most consequential parameters: the importId/final interplay is spelled out as cross-parameter sequencing that the individual schema descriptions don't convey. It leaves list, existing, verify, fileName, and the client* counters to the schema, so coverage is good but not 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 opening line states a specific verb and resource ('Import leads in chunks') and immediately adds the defining constraint of the tool: the chunked, multi-call protocol. An agent can distinguish this from sibling add_leads_to_campaign without opening the schema, since the chunking/final semantics are unique to this tool.

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 procedural guidance: 5,000 rows per call, omit importId on the first call, pass the returned id on subsequent chunks, and set final:true on the last. What it does not do is contrast this with the sibling add_leads_to_campaign, so the when/when-not routing 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?

With no annotations, the description carries the full burden and does meaningful work: it discloses that the lead gets the label for the thread's campaign and that the label's triggers fire (suppress, stop in campaign, pause campaign, move to list). That is real side-effect disclosure. It still omits permission requirements and reversibility.

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?

Compact and front-loaded with the core action, but it has a run-on structure and a missing sentence break ('a thread's label The lead...'), and 'null clears it' partially restates the 'or clear' already in the opening 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?

With no output schema and no annotations, the description still conveys the essential mutation semantics and its cascading side effects, which is the critical information for a write tool. It stops short of documenting permissions, error behavior, or what the call returns.

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%, so neither parameter is documented in the schema. The description compensates for labelId by explaining that null clears the label and by describing the tool's effect on the lead; however, the 'id' parameter (presumably the thread ID) is never explained, leaving half the parameters 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?

States a specific verb pair and resource: 'Set or clear a thread's label.' This is clear and distinguishable, but it does not contrast itself with any sibling tool (e.g. pause_campaign, add_suppressions) even though the described trigger effects overlap with those 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?

The description explains how to clear ('null clears it') but gives no guidance on when to use this tool versus siblings like pause_campaign or add_suppressions, which perform some of the same downstream actions. Usage context is only implicitly derivable from the trigger list.

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

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

With no annotations, the description carries the full burden and does well: it discloses a precondition (launch checklist runs first), a failure mode (refuses when a required item fails), and a timing constraint (sends inside the schedule window). It still omits permissions/auth requirements and whether the tool is idempotent or reversible.

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

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

Three short sentences, front-loaded with the core action, then preconditions and timing. Every sentence adds distinct information with 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?

Behavioral context is strong for a mutation tool with no annotations and no output schema, but the definition is silent on the required 'id' argument (format, meaning) and on what the caller gets back. Adequate but with clear gaps for a launch action.

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 explains it. The agent must guess whether it is a campaign ID, what format it takes, or what happens with an invalid ID, so the description 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?

States a specific verb and resource ('Launch or resume a campaign') and even captures the dual semantics (first launch vs. resume) that separates it from create_campaign and pause_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?

The dual launch/resume semantics and the checklist precondition imply when to call it, but there is no explicit when-to-use or when-not-to-use guidance relative to siblings like pause_campaign, preview_campaign, or get_launch_checklist. Usage must be inferred.

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

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

With no annotations, the description carries the full burden: it does disclose two real behavioral traits, sort order (newest first) and that each row is enriched with lead counts by progress. However, it says nothing about pagination, result limits, auth needs, or how the status filter affects results.

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

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

One short sentence with the key information front-loaded and zero filler. The phrasing 'List campaigns Newest first' is slightly clipped/awkward but costs nothing in clarity.

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 list tool this is thin: no output schema exists, no annotations exist, and the only parameter's filtering behavior is left unexplained. An agent knows what it will get back vaguely (campaigns with lead counts) but not how to scope the call or what the result envelope looks like.

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

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

Schema description coverage is 0% and the single parameter (status, an array of draft/running/paused/completed) is never mentioned in the description. The enum values give partial self-documentation, but the description does not explain filtering semantics or whether status is an OR/AND filter, 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?

States a specific verb+resource ('List campaigns') and adds scope detail: newest-first ordering and lead counts by progress. It is clearly distinguishable from get_campaign (singular) for an agent, but it does not explicitly name or differentiate itself from any sibling.

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 statement about when to prefer get_campaign or get_campaign_stats, and no prerequisites mentioned. Usage is only implied by 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?

No annotations exist, so the description carries the full burden; it discloses the return contents (mailbox count, deliverability scores, verification history) and that it operates on currently registered domains. It does not explicitly state that this is a side-effect-free read or mention pagination/size limits, so it falls just short of full coverage.

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

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

Three sentences, front-loaded with the action before the routing guidance. The middle sentence is slightly long but each clause adds distinct return-value information rather than 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 present, the description compensates by describing the returned fields, and with zero parameters there is nothing else an agent needs to invoke it correctly. Coverage is complete for this tool's complexity.

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

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

The tool takes zero parameters, so the schema has nothing to document and the description has no parameters to explain; baseline is 4 by the rules.

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 ('List all connected sending domains') with explicit scope, distinguishing it from add_domain and check_domain by name so an agent can route correctly 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 when-to-use ('review existing sending infrastructure') paired with two explicit when-not-to-use cases, each naming the correct alternative sibling tool. 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?

No annotations are provided, so the description carries the full behavioral burden. 'With counts' hints that counts are included in the response, but nothing is said about whether this is a read-only listing, whether results are paginated, whether it requires authentication/account scope, or how the counts are scoped.

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 four-word fragment with zero waste, but that is under-specification rather than true conciseness. A full sentence could have added the verb and scope at minimal cost.

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 zero-parameter listing tool with no output schema, the description only needs to convey what is returned, and 'with counts' gestures at that. Still, it does not say whether all lead lists are returned or what a 'lead list' contains, leaving the agent to infer the payload shape without an output schema to fall back on.

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 and schema coverage is 100%, so there is nothing for the description to document and no parameter ambiguity to resolve. Baseline 4 applies for a parameterless tool.

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

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

The fragment 'Lead lists with counts' identifies the resource (lead lists) and hints at the return content (counts), which distinguishes it somewhat from siblings like list_leads or list_campaigns. However, it is a bare noun phrase with no verb and no explicit statement that it lists lead lists, so the purpose is only implied.

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 about when to use this tool, when not to, or which sibling to prefer (e.g., list_leads vs list_lead_lists, or list_campaigns). The agent must infer usage 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose two useful traits — results are paged and default to newest-first ordering — but says nothing about the read-only nature of the call, the page/pageSize relationship, the 200-item pageSize ceiling, or the return shape.

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

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

Two tight sentences with the core capability front-loaded and no filler. Minor awkwardness in "List leads Paged" capitalization, but every clause carries information.

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

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

For a 10-parameter list tool with no annotations and no output schema, the description is thin: it never explains pagination bounds (page up to 100000, pageSize 10–200) or what a returned lead record looks like. It is adequate to start calling the tool but leaves meaningful gaps.

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

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

Schema description coverage is only 20%, so the description must compensate. It maps conceptually to six parameters (listId, labelId, status, verify, esp, search) and implies the sort default via "newest first," but leaves dir, page, and pageSize entirely 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?

States a specific verb and resource ("List leads") plus the default ordering and pagination behavior, which is more than a bare restatement of the name. It is distinguishable from sibling list_lead_lists and list_threads by resource, though it never explicitly names or contrasts them.

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

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

The description enumerates the available filter dimensions, which implicitly tells the agent this is the retrieval tool for lead browsing. However, it gives no when-to-use guidance relative to siblings (e.g., list_lead_lists for list metadata, import_leads for writes) and states no exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it omits whether the operation is read-only, requires auth, how results are paginated, or whether it is scoped to a workspace. It does reveal the returned data (limits, ramp-up, DNS health), which is the only behavioral signal present.

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, but the phrasing 'List mailboxes Connected sending mailboxes...' reads as two concatenated fragments and the front-loaded purpose is slightly garbled. It is compact but not cleanly structured.

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

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

With no parameters and no output schema, the description partially compensates by naming the fields returned. However, it says nothing about ordering, pagination, or scope, which an agent would need for a listing 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

The description names a specific verb ('List') and resource ('mailboxes') and enumerates the returned fields (today's limit, ramp-up, DNS health), which distinguishes it from siblings like list_domains or list_leads. It is clear, though it never explicitly contrasts itself with the other list_* tools.

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

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

There is no guidance on when to use this tool versus alternatives such as list_domains, check_domain, or get_launch_checklist, all of which touch overlapping domain/mailbox concepts. The agent is left to infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the sort order ('newest first') and the pagination contract ('Page with cursor from the previous answer'), but says nothing about permissions, result caps, or what a thread record contains.

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

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

Two short sentences with the purpose front-loaded and no filler. The missing sentence break between 'newest first' and 'Filter' makes it read as a run-on, slightly hurting scanability.

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

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

For a 6-parameter list tool with no annotations and no output schema, the description covers filtering and pagination but omits the shape of returned threads and any limits on result size. It is adequate to invoke the tool 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 33% (search and labelId documented). The description partially compensates by naming four filter dimensions that map to view, labelId, mailboxId and campaignId, and it clarifies cursor usage. It does not explain the 'all' vs 'unread' enum or the 'none' label sentinel, so the compensation is incomplete.

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 ('Reply threads') and adds the ordering ('newest first'), which distinguishes it from the sibling get_thread (singular retrieval). It does not explicitly name any sibling, so it falls short of 5.

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

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

The filter list ('unread, label, mailbox or campaign') implies when the tool is useful, but there is no statement of when to prefer get_thread instead or any prerequisite/exclusion. Usage is inferred rather than declared.

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

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

With no annotations at all, the description carries the full burden and does add genuinely non-obvious behavior: queued sends stop, and emails already handed to the provider still arrive (an irreversible side effect). It does not cover auth/permission requirements or whether the pause is reversible beyond relaunching.

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

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

Two short sentences, front-loaded with the action, and the non-obvious provider caveat is placed second where it is most needed. The first and second sentences run together without punctuation, a minor readability flaw.

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

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

For a one-parameter mutation with no annotations and no output schema, the behavioral disclosure is solid but the description omits any reference to the required identifier and to return/error behavior on an already-paused or nonexistent campaign.

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

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

The single required 'id' parameter has 0% schema description coverage and the description never mentions it, so the agent gets no guidance on what identifier is expected (campaign id vs. something else). With low schema coverage the description is supposed to compensate and does not.

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) with the precondition that it is 'running'. It implies the counterpart action ('until it is launched again') which maps to the sibling launch_campaign, though it never names that tool explicitly.

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

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

Usage is implied rather than stated: the phrase 'until it is launched again' tells the agent resumption goes through launch, and the sibling list contains launch_campaign for that. There is no explicit when-to-use or when-not-to-use framing and no named 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: it renders rather than mutates, spintax is resolved the way it will be for that lead, and the lead defaults to the first in the campaign. It does not state permission requirements or describe the response shape, but the read-only preview nature is clear from 'render' and 'shows'.

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?

Short, front-loaded, and every sentence adds information; the default-lead rule is placed at the end where it belongs. The only flaw is a missing sentence break after 'one lead', which makes the first two clauses run together.

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 preview tool with no output schema and no annotations, the description covers purpose, output nature, and default behavior adequately. The remaining gap is the unexplained `id` parameter and the absence of any note on what the rendered preview contains structurally.

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

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

Schema description coverage is 0%, so the description must compensate. It explains leadId's semantics (optional, defaults to the first lead in the campaign) but never says what the required `id` parameter refers to (presumably the campaign), leaving one of two parameters 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 (render/show) and resource (every step and variant for one lead), and clarifies the rendering semantics (spintax resolved as the lead would see it). It is clearly distinguishable from siblings like get_campaign or set_sequence, though it never names an 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?

The description implies a preview/inspection use case and explains the default-lead fallback when leadId is omitted, which is genuinely useful routing information. However, it gives no explicit when-to-use vs when-not-to-use guidance against siblings such as get_campaign or get_campaign_analytics.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose genuine behavior beyond the schema: the reply is sent from the conversation's mailbox, uses In-Reply-To/References headers, targets the last writer, and quotes the previous message below. It omits error handling, permission requirements, and whether the send is reversible, so it is helpful but incomplete for a mutation tool.

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

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

Two compact sentences that front-load what the tool does and then add threading mechanics, with almost no wasted words. The unpunctuated clause 'Answer a thread Sends from the mailbox' slightly hurts readability but the structure is efficient.

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-required-parameter mutation tool with no annotations and no output schema, the description explains the send/threading behavior but leaves parameter semantics and side-effect/error information unspecified. It does not provide enough for an agent to invoke the tool confidently beyond guessing that 'id' is the thread identifier.

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 two required parameters. It only hints that 'id' identifies the thread being answered; the meaning, format, and constraints (e.g., text length limit, plain vs. HTML body) of 'text' are entirely undocumented in both schema and description, so the description 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 states a specific verb ('Answer a thread') and resource (thread), and distinguishes itself from read-only siblings like get_thread and list_threads by making clear it sends a message. It is clear what the tool does, though the fragment 'Answer a thread Sends from the mailbox...' is grammatically awkward and slightly blurs the verb.

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 implicitly tells the agent that this is for replying within an existing conversation and that the reply goes to whoever wrote last, which is useful context. However, it never states when to use this versus the other thread/message tools nor any prerequisites (e.g., the thread must exist), leaving usage mostly 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?

With no annotations the description carries the full burden, and it does disclose the two most important behavioral facts: the operation replaces the entire step list (destructive scope) and is restricted to draft/paused campaigns (state prerequisite). It omits permissions/auth, reversibility, and rate limits, so it is strong but not complete.

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

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

The destructive scope is front-loaded in the first clause, content-syntax rules follow, and the state restriction closes. Every sentence carries information; there is no filler.

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

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

For a destructive, nested-payload mutation tool with no annotations and no output schema, the description covers replacement semantics, allowed states, and body syntax well. It still leaves the per-step scheduling fields (waitDays, sameThread) and the campaign `id` unexplained, which is a real gap for a tool this structured.

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 0% schema coverage the description must compensate, and it does add rich meaning for the `steps` body content (ordering, 1-5 variants, plain text vs HTML, {{var}}/{{var|fallback}}, spintax, mandatory {{unsubscribe}} in the first email). It says nothing about `id`, and the nested subject/active/weight/waitDays/sameThread fields are undocumented in both description and schema.

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

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

States a specific verb+resource: 'Replace the whole sequence Steps in order, each with 1 to 5 variants,' which makes the full-replacement semantics clear. However, it never distinguishes itself from the sibling write_sequence, leaving the agent unable to tell the two apart from the description alone.

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 one real gating condition, 'Only drafts and paused campaigns,' which tells the agent when the tool is legal. It names no alternative and gives no when-not guidance (e.g., versus write_sequence or update_campaign), so the routing decision is only half-supported.

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

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

No annotations are provided, so the description carries the full burden for a mutation tool. It does not disclose permissions, side effects, replacement semantics for mailboxes, reversibility, or what happens when the campaign id is invalid, leaving important behavioral context unstated.

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

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

The description is a single front-loaded sentence with no redundant wording. Its brevity is appropriate structurally, though the content is too thin for a 17-parameter update tool.

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

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

For a mutation tool with no annotations, no output schema, and 17 parameters, the description is substantially incomplete. It omits update semantics, validation behavior, return expectations, and guidance on how the many options interact.

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 are 17 parameters with only 59% schema description coverage, and the description adds little parameter-level meaning beyond broad categories like schedule and mailboxes. It does not explain required id, replacement behavior for mailboxIds, date semantics, or the many boolean scheduling and tracking options beyond what partial schema descriptions already say.

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

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

The description names the resource and the main update categories: rename, schedule, mailboxes, and options. It is clear enough to identify an update operation on an existing campaign, but it does not contrast itself with siblings such as create_campaign, launch_campaign, or pause_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?

It implies use on an existing campaign by saying 'a campaign,' but gives no explicit when-to-use or when-not-to-use guidance. It also does not direct the agent to launch_campaign, pause_campaign, create_campaign, or set_sequence for related operations.

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

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

No annotations exist, so the description carries the full burden, but the burden is light for a zero-argument identity probe. It discloses what is returned (user, workspace, plan) yet never states that it is a read-only, side-effect-free lookup with no auth beyond the key/session already in use. That omission keeps it at a minimum-viable 3.

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 clause ('Who am I:') followed by the exact scope of the answer. Every word earns its place and there is no restatement of the title or name.

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

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

With zero parameters and no output schema, the description usefully enumerates the three things returned (user, workspace, plan), which is exactly the detail an agent needs to decide whether this call answers its question. It could go one step further by noting the answer reflects the calling credential, but the gap is minor.

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 and the schema is trivially complete, so the baseline is 4. Nothing in the description is needed to explain inputs, and it correctly makes no attempt to document nonexistent parameters.

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

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

The description names a specific resource set: the user, workspace and plan behind the current key or session. That is unambiguous and distinguishes it from every sibling, which all deal with campaigns, mailboxes, domains or threads rather than credential identity. It would need a verb form (returns/resolves) to reach 5, but the intent is clear.

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 it is the tool to call when it needs to know which account the credential belongs to. There is no explicit when-to-use, no prerequisites, and no statement that it is the cheap first call before other operations. Adequate but with a clear gap.

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

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

With no annotations, the description carries the full burden and does well: it discloses that output is saved as new variants and never overwrites existing text, that an empty campaign receives the drafted steps, and that each email is validated against a content checklist with failures returned in 'problems'. It omits any statement about permissions or rate limits, but the mutation semantics and side effects are well covered.

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

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

Dense but front-loaded: the core verb and mode branching come first, then side effects, then the precondition. Every sentence contributes information, though the paragraph is slightly long with the checklist and profile caveats packed into the tail.

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 mutation tool with no annotations and no output schema, the description covers the essential ground: what is produced, that nothing is overwritten, that validation results come back as 'problems', and the prerequisite profile configuration. Only the shape of the returned variants/steps is left 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?

Schema description coverage is 83%, so the enum and field descriptions already explain mode, angle, steps, persona and variantId. The description restates the mode meaning but adds no format, constraint, or interaction detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Write emails with AI from the offer profile') and immediately enumerates the four operating modes (sequence, rewrite, shorter, angle), so an agent knows exactly what it produces. The non-overwrite behavior also implicitly separates it from sibling tools like set_sequence that replace sequence content.

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?

Clear context for each mode: sequence drafts every step, rewrite/shorter/angle produce a new version of one variant, and the description flags the variantId requirement for the latter. It also names the precondition (offer profile must be configured, or updated via update_offer_profile). It does not explicitly say when NOT to use it versus alternatives such as set_sequence.

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