MailBeast.ai

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is known. The description adds behavior beyond that: deduplication by email within the campaign and malformed addresses being counted as `invalid` rather than rejected. It leaves ambiguous whether dedup applies against existing campaign leads or only within the 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?

Two tight sentences with no filler; the batch limit and retry instruction are front-loaded before the dedup/invalid caveats. Every clause carries information an agent needs.

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

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

With no output schema, the description carries the burden of explaining the response, and it only implies result counters by saying malformed addresses are 'counted as invalid' without saying what counts are returned (added/duplicates/invalid). The call-critical facts (batch cap, dedup key, invalid handling) are present, but the result contract is left to inference.

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

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

Schema description coverage is 50%, and the description only touches the email field (the dedup key and the malformed-address case). It adds nothing about campaignId or the optional lead fields (tags, customFields, customFieldTypes), so it neither fully compensates for the coverage gap nor falls below the baseline for a schema that documents most 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 ('Add ... leads to a campaign') with an explicit scope ('1-100') and keys on the identifying field (email). It is clearly distinguishable from siblings like bulk_add_lead_tags, update_lead, and delete_leads.

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?

'call again for more' gives concrete batching guidance that tells the agent how to handle more than 100 leads. It does not name an alternative tool or a when-not-to-use condition, but the batch size cap plus the retry instruction covers the main usage decision an agent faces here.

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=false, destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral detail by clarifying the operation is additive ('Tags the lead already has are kept'), which explains why it can be destructive to state while still idempotent.

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 with zero filler, and the scope/cap is front-loaded ahead of the additive-semantics note. Every clause carries information the 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 bulk mutation with no output schema, the description covers scale and additive behavior but omits what happens on unknown/invalid lead ids, whether partial success is possible, and what the response reports. It is adequate but leaves operational gaps for a 1000-item write.

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

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

Schema description coverage is 100%, so the schema already documents campaignId, ids, and tags. The description only echoes the ids cap ('up to 1000') and says nothing about the tags array limit of 50 or the UUID formats, so it does not go meaningfully beyond the schema. 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 ('Add tags to ... leads of a campaign') plus a batch scope (up to 1000), which clearly separates it from the singular add_leads and from add/remove operations that touch different resources. It does not explicitly name siblings such as bulk_remove_lead_tags, so differentiation is inferable rather than spelled out.

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

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

The 1000-lead and campaign scoping implies this is the batch path for tagging leads within a single campaign, but there is no explicit when-to-use, when-not, or named alternative (e.g. single-lead update_lead). Usage must be inferred from the name and scale limit.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the 1000-lead batch cap and the no-op rule that leads lacking the tags are left unchanged, which reinforces idempotency semantics.

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 with the core action and scope front-loaded and no filler. The second sentence carries the no-op semantics rather than 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 3-parameter batch mutation with full schema coverage and annotations covering safety, the definition supplies what an agent needs to call it correctly. It is silent on what the response reports (e.g. how many leads were changed), which prevents a top score given there is no output schema.

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

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

Schema description coverage is 100%, so ids, tags, and campaignId are already documented structurally, with the same 1000-item cap appearing in maxItems. The description adds no format, constraint, or meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource (remove tags) plus the scope (leads of a campaign) and the batch ceiling of 1000. The verb 'remove' inherently separates it from the sibling bulk_add_lead_tags, though no sibling or alternative 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?

The bulk nature and 1000-lead limit imply when this tool is appropriate, but the description never states when to use it versus bulk_add_lead_tags or update_lead, nor any prerequisites. Usage is inferable rather than guided.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond that — it doesn't say whether the new status overwrites an existing one, how prior statuses are affected, or whether the change is reversible or notifies anyone.

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

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

A single sentence with the operation and its scale front-loaded and zero filler. Nothing needs trimming and nothing is buried.

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

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

For a destructive bulk mutation with annotations covering safety and a fully documented schema, the definition is minimally adequate. However, with no output schema and no usage guidance, an agent still lacks direction on when to prefer this over update_lead and what side effects on existing lead state to expect.

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%, including the full enum and the replied-lead constraint on lead_replied_* statuses, so the schema carries the parameter burden. The description only restates 'the same status' and the 1000-item cap, adding no semantics beyond the structured fields; baseline 3 applies.

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

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

States a specific verb ('Set'), resource ('status'), and scope ('the same status on up to 1000 leads of a campaign'), making the bulk nature explicit. It is distinguishable from single-record siblings like update_lead or add_leads, though it never names an alternative to sharpen the contrast.

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

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

No when-to-use guidance, no exclusions, and no named alternative such as update_lead for a single lead. The prerequisite that statuses like lead_replied_* and lead_converted require an already-replied lead lives only in the schema, not in the description.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, lowering the bar. The description still adds real behavioral context: which mailboxes get silently skipped and listed, and that patch only touches shared settings with no credentials. It does not describe partial-failure or return behavior, keeping it short of a 5.

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

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

A single dense sentence that front-loads the core operation and packs the exclusivity rule, skip behavior, and sibling routing without a wasted clause. Every fragment earns its place.

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

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

For a destructive bulk mutation with no output schema, the description covers the key gaps: skip semantics, mode exclusivity, and credential scope. It leaves unspecified what a partial failure or the response payload looks like, which is a minor remaining gap given annotations carry the safety profile.

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?

Top-level schema coverage is 0% (ids, status, patch have no descriptions), so the description must compensate and largely does: it explains the status enum values, scopes patch to 'shared settings, no credentials', and enforces the mutual-exclusivity rule that the schema itself does not encode via oneOf. The ids array's cardinality is only implied, not restated.

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 ('Apply ONE change to up to 1000 mailboxes') and enumerates the two mutation modes (status vs patch). It also names the sibling resume_mailbox as the correct tool for failed/revoked/checking mailboxes, so an agent can separate this from update_mailbox and resume_mailbox 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?

Gives explicit when-to-use (bulk one-change across up to 1000 mailboxes), when-not (failed/revoked/checking mailboxes are skipped; use resume_mailbox instead), and the selection constraint ('Exactly one of the two'). The alternative tool is named, not implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds valuable semantics beyond that: the three terminal/intermediate states and what payload accompanies connected (accountId) and failed (error), which is exactly the behavioral context an agent needs.

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

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

A single sentence with the state machine front-loaded and zero filler; every clause earns its place.

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

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

With no output schema, the description correctly supplies the return-value contract (pending/connected/failed plus accountId/error), which is the key missing piece. Only polling cadence or timeout guidance is absent, a minor gap for such a simple tool.

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

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

Schema coverage is 50%: state is documented in the schema and reinforced by 'started with start_oauth_connect', while provider is an enum that is largely self-explanatory. The description adds little beyond the schema, so baseline 3 is appropriate for a two-param 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?

States a specific verb (Poll) and resource (OAuth connect) and links to the sibling start_oauth_connect that originates the flow. An agent can immediately distinguish it from start_oauth_connect and other 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?

Makes clear it is used after start_oauth_connect to poll status, implicitly the follow-up to that tool. It does not state polling cadence, when to stop polling, or state expiry, so guidance is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing behavioral on top: not what is counted (messages vs threads), not whether filters intersect or union, not any workspace/auth scoping or rate-limit context.

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

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

A single short sentence with the core metric front-loaded and no filler. It is a fragment rather than a full sentence, but nothing is wasted.

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

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

For a two-optional-parameter counter with full annotation coverage and no output schema, the definition is minimally viable. It still leaves the agent guessing about filter interaction semantics and the counting unit, which is the main 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 carries the full burden for the two filters. It gestures at both (mailboxes, campaign) but never explains the expected format for mailboxes, the campaignId meaning, or what happens when both filters are supplied — the most important ambiguity for this 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 description names a concrete resource and metric (unread email count) with an optional scoping dimension, so the agent knows exactly what is produced. It stops short of distinguishing itself from nearby siblings like list_emails or get_workspace_analytics, which also surface email/count information.

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

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

'optionally for some mailboxes or one campaign' is a parameter hint, not usage guidance. There is no statement of when to reach for this instead of list_emails, get_mailbox, or get_workspace_analytics, and no note about the workspace/user scope the count applies to.

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

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

Annotations already flag this as a non-readonly, non-idempotent, destructive mutation, but the description goes further by scoping that risk: nothing is sent until start_campaign, so creating is safe from a sending standpoint. It also discloses defaults beyond the annotations, notably that the campaign sends from ALL connected mailboxes unless `accounts` plus settings.useAllAccounts = false are used. It does not cover side effects like whether a duplicate name is rejected or what permissions are needed.

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 most important fact (draft, does not send) is front-loaded in the first clause, followed by optional payload areas, then the sending-source default, then the lifecycle pointer. Four sentences with no filler, though the second sentence packs a lot of list-like material.

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

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

For a 7-parameter, deeply nested creation tool the description covers lifecycle (draft to start_campaign), mailbox selection defaults, lead ingestion and A/B step limits. The main gap is that there is no output schema and the description never says what comes back (presumably a campaign id) or what state the created campaign has, which an agent needs for the follow-up start_campaign call.

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 86% schema description coverage, the schema already documents nearly every parameter, including the accounts/useAllAccounts interaction and the variants logic. The description restates the 1000-lead cap, the 5-variant A/B limit and the mailbox default rather than adding new semantics. Baseline 3 is appropriate because the schema is doing the explanatory work.

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

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

The description opens with a specific verb+resource+state: 'Create a campaign as a DRAFT — it does not send.' That single clause separates it from update_campaign, start_campaign and create_subsequence without the agent needing to open 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?

It routes the agent to explicit alternatives: use add_leads for full lead details, start_campaign to actually launch, send_test_email to preview a step. It also states the condition for `accounts` (settings.useAllAccounts = false). It stops short of an explicit 'use update_campaign instead when the campaign already exists' exclusion, which is the one realistic confusion.

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

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

Adds real behavior beyond the annotations: inherits campaign mailboxes, tracking and stop rules; emails from the same mailbox and thread; a lead is in one subsequence at a time and enters each once; entering ends its main sequence. What is missing is the destructive/irreversible side the destructiveHint implies (whether the subsequence can be deleted, plan or count limits) and the fact that it returns the new subsequence for follow-up calls.

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

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

Two sentences, no filler, and the most consequential fact (created off, sends nothing) is front-loaded. Every clause adds operational meaning rather than restating the name.

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

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

For a deep nested create tool with 4 top-level parameters and no output schema, the description covers inheritance and the off state but not the return value (the new subsequence id, needed for update_subsequence or enroll_in_subsequence) or error conditions. Adequate, but an agent must still infer the follow-up path.

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 75%, so the schema already explains the bulk of parameter meaning, and the description adds nothing further about campaignId, name, sequence or settings. It does explain that unlisted settings are inherited from the campaign, which slightly clarifies what the caller does not need to supply.

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

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

States a specific verb and resource ("Create a subsequence of a campaign") plus a decisive qualifier ("turned OFF"). It is clearly separable from list_subsequences, update_subsequence and enroll_in_subsequence because it makes creation, not listing, editing or enrollment, the action.

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

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

"Turned OFF - it sends nothing until it is turned on in the MailBeast dashboard (or with the REST API)" gives the operating context and prerequisite an agent needs before calling. It stops short of naming sibling tools such as update_subsequence for editing an existing one, but the context 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?

Annotations already carry destructiveHint=true and idempotentHint=true, but the description goes further by disclosing the cascade (leads are deleted alongside the campaign) and the required campaign state before deletion. It does not cover permissions, error behavior, or how deletions are reported, so it stops short of a 5.

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

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

Two short sentences: the destructive scope is front-loaded and the prerequisite follows immediately. Every clause carries actionable 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?

For a one-parameter destructive tool with full annotation coverage and no output schema, the description supplies what annotations cannot: the cascade effect on leads and the pause-first requirement. Nothing an agent needs to call it safely 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?

There is a single parameter with 100% schema description coverage (id as a UUID), so the schema already does the work. The description adds no syntax or format detail beyond it, which is the expected baseline here.

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

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

States a specific verb (delete) plus resource (campaign) and the cascade scope (with its leads), which distinguishes it from delete_leads and delete_mailbox in the sibling list. An agent can identify the operation and its blast radius without opening the schema.

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

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

Gives an explicit precondition (an active campaign must be paused first) and names the exact sibling to use (pause_campaign), so the when-not and the alternative path are both spelled out. 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 destructiveHint=true and idempotentHint=true, so safety is covered. The description adds genuine non-obvious behavior: leads that finished their sequence are not deleted but reported in errors, and it caps ids at 1000. It does not mention permission requirements or confirmation flow.

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

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

A single dense sentence that front-loads the verb and scopes the selector constraint before the edge-case caveat. Every clause carries information; nothing is redundant.

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

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

For a destructive mutation with no output schema, the description covers the selection modes and the notable error-reporting behavior. It stops short of describing reversibility or required permissions, leaving a minor gap for a destructive operation.

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

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

Schema coverage is only 50%, so the description meaningfully compensates by spelling out the mutual exclusivity of ids/filter/all, the 1000-item cap, and the requirement that filter carry at least one non-empty field. This is real added meaning beyond the raw schema for the nested filter object.

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 (Delete) and resource (leads) with scope (from a campaign), which cleanly distinguishes it from the sibling delete_campaign that removes the campaign itself. An agent can tell immediately that this operates on the lead set inside a 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?

Gives explicit selection semantics — EXACTLY ONE of ids, filter, or all — which is strong operational guidance on how to invoke it. It does not, however, state when to prefer this over alternatives like bulk_update_leads or delete_campaign, so exclusions are 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 declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real value beyond that: it discloses the side effect (campaigns stop sending from the mailbox) and the reversibility path (reconnect the same address to restore), which the annotations 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?

Two short sentences with the core action front-loaded and no filler. Every clause earns its place: the first states the action, the second states the consequence and the reversal.

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 full annotation coverage and a complete schema, the description supplies the operational context an agent needs: what the tool does, the immediate effect on sending, and that removal is recoverable. No output schema exists, so nothing further about return values is required.

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 parameter with 100% schema description coverage ('Mailbox id (UUID)'), so the schema fully carries the semantics. The description adds nothing about the id beyond what the schema states, making the baseline 3 appropriate.

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

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

States a specific verb and resource: 'Remove a mailbox from the workspace.' The agent can distinguish this from list/get/update_mailbox. However, it does not name the closest soft alternative (pause_mailbox), so the boundary between delete and pause relies on the reader's inference.

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

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

Usage is implied rather than stated. The note that campaigns stop sending and that reconnecting restores the mailbox hints at when this is safe or reversible, but there is no explicit 'use this instead when X' and no mention of pause_mailbox as the non-destructive route.

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 destructiveHint=true and idempotentHint=false, but the description adds substantial behavioral context beyond them: remaining main-sequence emails are canceled, the subsequence sends real email from the same mailbox and in the same thread, and off/paused subsequences queue leads rather than rejecting them. It also discloses the shape of the result (who entered, who was skipped and why, who is not a campaign lead), which is the key side-effect information for a destructive move.

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

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

Three dense sentences, front-loaded with the action and scope, then the consequences, then the edge cases. No filler, though the long dash-joined clauses make it slightly harder to scan than an ideally structured description.

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

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

For a destructive, non-idempotent bulk mutation with no output schema, the description covers side effects, eligibility, limits, and result contents. The remaining gap is small: no mention of permission/mailbox-connection requirements and no clarification of how `start` interacts with an already-paused subsequence.

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

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

Schema coverage is 100%, so the parameters are already well documented, and the description only adds the mutual "by `leadIds` or `emails`" framing plus the 1000 limit. It says nothing about the `start` parameter (now/delay/date), which is the one field whose interaction with a paused subsequence an agent might want clarified. Baseline 3 is appropriate given 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?

"Move leads of the main campaign ... into a subsequence" gives a concrete verb, resource, and direction of movement, and immediately distinguishes the operation from add_leads or list_subsequences. It even names the input modes (`leadIds` or `emails`) and the 1000 cap, so an agent knows exactly which operation is being requested.

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 real selection criteria: leads must be from the main campaign, must already have been emailed, and can enter a given subsequence only once. It also explains the paused-subsequence case, so an agent can decide whether the call is appropriate. It does not compare against siblings such as add_leads or list_subsequences, which keeps it from 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond that: results are capped at 10 matches and each match includes its campaign, which shapes how the agent should interpret 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 short sentences, front-loaded with purpose and immediately followed by scope and result shape. Every clause adds useful 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?

For a simple one-parameter lookup with complete schema coverage, rich annotations, and no output schema, the description supplies the key missing return-shape behavior: up to 10 matches and campaign association. Nothing critical for correct invocation appears to be 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 schema has 100% description coverage and fully documents the single email parameter, including that it accepts an email fragment. The description's '(or part of it)' largely repeats that, adding no syntax, matching rules, or additional parameter meaning, so the baseline 3 is appropriate.

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

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

The description gives a specific verb and resource (find leads by email) and states the search scope (across ALL campaigns) plus partial-match behavior. It helps distinguish a broad email-based lookup from single-lead tools like get_lead, but it never explicitly differentiates itself from sibling search/list tools such as get_lead_search or list_leads.

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: use this when searching by email or an email fragment across campaigns. There is no explicit when-not guidance, no named alternatives, and no prerequisites, so an agent must infer when to choose this over get_lead, get_lead_search, or list_leads.

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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description still adds real behavior beyond that: that a sent email cannot be recalled (confirming irreversibility) and that a duplicate forward within 24h is delivered only once — a non-obvious delivery rule. The 24h de-dup note reads slightly at odds with idempotentHint=false but refers to delivery de-duplication rather than tool call semantics, so it is not a contradiction.

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

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

Two tight sentences with the action front-loaded and no filler; the composition detail and delivery rule each carry weight. Slight density from semicolon-chained clauses, but nothing is wasted.

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

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

For a 6-parameter, nested-body mutation tool with no output schema, the description covers the action, the quoting behavior, irreversibility, and duplicate-delivery handling. It does not address the cc/bcc dimensions or confirm what the call returns, leaving small 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 coverage is 50% (id, body, subject are documented; to, cc, bcc are not). The description corroborates "recipients" (to) and an "optional note" (body), but adds no syntax, limits, or explanation for cc/bcc or the subject override — which the schema does partially cover for subject. Baseline 3 is appropriate given the mixed 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?

States a specific verb and resource ("Forward an email to the given recipients, from the mailbox that owns it") and clarifies the composition shape (original quoted below an optional note). It is distinguishable from reply_to_email by the word "forward", though it never names or contrasts that sibling explicitly.

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

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

Usage is implied: this is the tool for forwarding an existing message identified by id. There is no explicit when-to-use/when-not guidance and no mention of the obvious alternative (reply_to_email) or when forwarding is preferable to replying.

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/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavioral semantics beyond that: sendStatus.isWithinSchedule is computed from the schedule and start/end dates for any status, and a draft or paused campaign still does not send, plus the next-window timing. It does not cover auth/rate limits or pagination, but for a read lookup this is unusually substantive.

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 payload summary, and every clause carries information (return contents, cross-tool field mapping, schedule semantics). The second half is a single dense sentence with nested parentheticals, which is slightly heavy but not padded.

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 must convey the return shape — and it does, enumerating the major payload sections and one key nested field path. Combined with the schedule/send-window semantics, an agent has everything needed to call and interpret this tool.

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

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

Only one parameter (id, UUID) and schema description coverage is 100%, so the schema fully documents it. The description adds no format or lookup guidance for the id beyond what the schema states, 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 ('One campaign') and enumerates exactly what is returned: schedule, settings, metrics, attached mailboxes, and the sequence with steps/variants. It is immediately distinguishable from list_campaigns (plural collection) and from 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?

Gives a concrete cross-tool usage cue by naming the field to consume ('sequence[].variants[].id is the variantId for send_test_email'), which tells the agent when to reach for this tool. It stops short of explicit alternatives or exclusions (e.g. use list_campaigns to find ids, use analytics for time-series metrics).

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 that this is a safe read-only, idempotent operation, but the description adds meaningful behavioral detail: default inclusion of subsequences with each email and person counted once, optional breakdown tables, and optional time-series output. These aggregation semantics go beyond the safety profile and help the agent understand how results are computed.

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 front-loaded with the core metric list, then proceeds to scoping, breakdown, and interval behavior in compact sentences. It is dense but efficient, with no wasted framing 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 an eight-parameter analytics tool with no output schema, the description is quite complete: it names the metrics returned, explains default aggregation, and describes optional breakdown and time-series additions. It could be stronger if it clarified the response shape when breakdown and interval are combined, but overall it covers what the agent needs 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 coverage is high at 88%, so the baseline is 3, but the description adds useful meaning beyond the schema by explaining that breakdown produces per-mailbox, per-step/variant, or per-bounce-type tables. It also clarifies that subsequenceId narrows to one subsequence and overrides scope, though several of those details are already present in the schema.

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

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

The description clearly states that this returns campaign performance metrics for a period and enumerates the metrics included. It distinguishes campaign-level analytics from broader workspace analytics only implicitly, and does not directly name sibling tools like get_workspace_analytics or get_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 explains how to adjust scope using the default family aggregation, `scope: "main"`, and `subsequenceId`, which gives useful conditional guidance. However, it does not explicitly say when to choose this tool over `get_campaign` or `get_workspace_analytics`, so the usage guidance remains 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 the safe read profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds real behavioral detail on top: bodies over 25000 characters are truncated and flagged via `bodyTruncated`, and the html fallback behavior is explained. These are non-obvious traits the agent could not learn from the annotations.

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

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

A single dense sentence with a semicolon and one parenthetical; it is front-loaded with the primary return value and every clause carries information. No filler, though the packed parenthetical slightly reduces scannability.

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

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

With no output schema, the description must sketch what comes back, and it does: body as plain text, optional html, and the truncation flag. It stops short of describing the remaining email fields the agent will receive, but covers the parts that vary by request.

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

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

Schema description coverage is 100%, so the 3 baseline applies, but the description adds genuine semantic value: `includeHtml` is not merely 'also return html' — it explains that html is returned anyway when the email has no text part. That fallback nuance is beyond what the schema states.

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

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

The description states a specific resource and scope: 'One email with its body as plain text', which implicitly distinguishes it from the sibling list_emails by returning a single item. The title supplies the verb 'Get'. It is clear, though it never explicitly names an alternative.

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 and no mention of alternatives such as list_emails or reply_to_email. The use case (retrieve a single email by id) is only implied by the resource noun, leaving the agent to infer 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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description's only added behavioral value is noting the payload includes custom fields and sequence progress, which is modest but non-redundant context.

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

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

A single short sentence with no wasted words, front-loading the returned entity and its notable contents. It is efficient, though its brevity comes at the cost of substance rather than being a model of dense, front-loaded 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?

There is no output schema, so the description carries part of the burden of describing the return value; it gestures at custom fields and sequence progress but is otherwise thin. With two required UUID parameters fully documented in the schema, the tool is callable, but the returned shape and error behavior remain unclear.

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% — both leadId and campaignId are documented as UUIDs in the schema — so the baseline is 3. The description adds no format, scoping, or lookup semantics beyond what the schema already states.

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 ('One lead of a campaign, with custom fields and sequence progress') rather than a verb+resource statement, relying on the name/title for the retrieval verb. It does convey what the tool returns — a single lead with its custom fields and sequence progress — but it does nothing to distinguish it from siblings like get_lead_search, find_lead_by_email, or list_leads.

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 tool versus the many adjacent lead-retrieval siblings (find_lead_by_email, get_lead_search, list_leads). The agent must infer that this is the direct lookup-by-id path from the required campaignId/leadId parameters 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description contributes the content shape of the record (including that an error field exists on failure), but says nothing about behavior when the id is unknown, pagination, or freshness of a running search.

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 telegraphic sentence with zero waste, and the identifying noun phrase ('One Lead Finder search') is front-loaded before the field list.

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 full annotations and 100% schema coverage, and no output schema to describe, the definition is workable for a simple read. It still omits the sibling-routing guidance and any not-found/error semantics, which are the only things an agent genuinely needs beyond the schema.

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

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

Schema description coverage is 100% for the single id parameter (documented as a Lead search UUID), so the schema carries parameter semantics. The description adds no format or lookup-key detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description names the resource precisely (one Lead Finder search) and enumerates what it contains: query, status, discovery/enrichment progress, and failure error. It does not explicitly contrast itself with the sibling list_lead_searches, so the singleton-vs-list distinction is inferred from the name 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 when-to-use guidance and no mention of list_lead_searches as the alternative for enumerating searches. The agent must infer from the name and the required id that this is a fetch-one-by-id operation.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint false, openWorldHint false), so the bar is lower. The description still adds real value by disclosing the response contents — status, failure reason, health score, warmup, limits, signature — which matters because there is no output schema.

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

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

Two sentences, no filler, and the payload content is front-loaded before the optional-parameter note. Every clause earns its place.

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

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

For a read-only single-resource fetch with no output schema and no nested objects, enumerating returned fields plus the optional verification flag is sufficient. Only error behavior for an unknown id is unaddressed, a minor omission.

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

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

Schema coverage is only 50%: 'id' is documented in the schema, but includeVerification has no schema description. The description compensates by explaining exactly what that flag adds (the latest SMTP/IMAP connection test result), so the parameter gap is closed.

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 'One mailbox: status, why it last failed, health score, warmup, limits, signature' makes clear this retrieves a single mailbox and enumerates what comes back. The singular framing implicitly distinguishes it from list_mailboxes, but no sibling is named outright, so an agent must infer the id-based lookup shape.

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

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

There is no explicit when-to-use-this vs list_mailboxes or update_mailbox guidance; the id-required schema implies lookup-by-id. The one conditional instruction — 'Set includeVerification to also get the latest SMTP/IMAP connection test result' — is genuine usage guidance for the optional parameter, which lifts it above a bare 2.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful detail of which counters are returned, but says nothing about authentication requirements, whether usage is real-time or cached, or behavior when the connection is missing.

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 em-dash sentence that front-loads the resource and then the fields, ending with the practical implication. There is no filler or repetition of 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 and no parameters, the description carries the return-value burden and discharges it by enumerating the returned data groups explicitly. It is nearly complete for a simple read tool, missing only edge-case behavior such as a disconnected or unauthenticated workspace.

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 zero parameters, so the baseline is 4. The description correctly implies no inputs are needed, beyond that it carries no parameter semantics to elaborate.

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 and enumerates exactly what comes back: workspace id/name/timezone, subscription plan, and usage against each plan limit. It is not differentiated from the sibling get_workspace_analytics, however, so an agent must infer whether 'usage' here overlaps with that 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 supplies concrete use context — 'what is left before adding leads, starting campaigns or sending replies' — which tells the agent this is a pre-flight capacity check. No explicit alternatives or when-not conditions are given, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that the result is aggregated totals and rates rather than raw records, which is mild added value, but says nothing about retention clipping, timezone handling, or response shape beyond that.

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

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

A single, front-loaded sentence with no filler; the scope and return content come first. It is arguably too terse for a tool with non-obvious date semantics, but nothing is wasted.

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

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

With three optional parameters and no output schema, the description partly compensates by naming the return content ('totals and rates'). However, it omits any note about the default 7-day window or plan retention clipping, which are behavioral facts an agent should know before calling.

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

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

Schema description coverage is 100%; the schema fully documents startDate/endDate defaults and the excludeOOO flag. The description contributes no parameter semantics of its own, 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?

The description states a specific verb (roll-up) and resource (all campaigns, workspace-wide), with scope ('across the workspace') that implicitly separates it from the per-campaign sibling get_campaign_analytics. It never names that sibling explicitly, so differentiation is left partly to inference.

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

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

Usage is only implied: the workspace-wide framing suggests this tool when you want an aggregate rather than a single campaign's numbers. There is no explicit 'use this instead of get_campaign_analytics when...' guidance or mention of prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds two genuinely useful traits beyond that: result ordering ('newest first') and which fields come back ('status and lead count'). It does not mention pagination behavior or what happens when filters match nothing, so it stops short of rich behavioral disclosure.

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

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

A single front-loaded sentence with zero filler; the returned fields and sort order come before any optional detail. It is efficient, though the terseness leaves room that a second short clause about filtering could have filled.

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 names the two returned fields and the sort order, which is the right compensation. However, for a 4-parameter filterable list tool it omits how the status and tagIds filters combine and any hint about pagination, leaving the agent to infer behavior from the schema alone.

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

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

Schema coverage is 75%, close to the point where the schema carries the load; limit and cursor are fully documented there. The undescribed status enum and tagIds filter are not explained in the description either — 'with status' refers to a returned field, not the filter — so the description adds almost no parameter meaning beyond the schema.

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

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

States a specific verb and resource ('List campaigns') plus the fields returned ('status and lead count') and the ordering ('newest first'). It does not explicitly distinguish itself from get_campaign or list_subsequences, but the collection-vs-single split is obvious from the name pairing.

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 get_campaign (single campaign detail) or the subsequence/mailbox list tools, and no mention of when the status or tagIds filters should be applied. Usage is only implied by the tool 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 cover readOnly/idempotent/non-destructive safety, so the description adds value by disclosing default ordering ('newest first') and the fact that bodies are omitted from results — return-shape behavior not present in the schema. It stops short of describing pagination/response envelope 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?

Two sentences, front-loaded with the core behavior and the get_email pointer before the filter enumeration. The filter list is dense but each item corresponds to a distinct capability and none is filler.

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

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

For a 14-parameter read tool with no output schema, the description covers the identity, default ordering, body omission, and most filter axes. Gaps remain around the pagination envelope and sortOrder interaction, which the schema only partially documents.

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 only 50% schema description coverage across 14 parameters, the description carries real weight: it maps filter dimensions to mailboxes, campaignId, threadId, leadId, isUnread, type ('sent'/'received'), folder, search, date range and latestOfThread. It omits limit, cursor, and the existence of sortOrder (which could override the stated 'newest first').

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 with scope ('across all mailboxes (unified inbox)') and immediately distinguishes itself from get_email by declaring it returns items 'without bodies'. An agent can tell exactly what this tool returns and how it differs from the retrieval 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?

Explicitly routes body retrieval to get_email and explains that latestOfThread collapses to one row per conversation, which is actionable selection guidance. It does not mention when to prefer siblings like count_unread_emails for counting, so it stops short of full alternative coverage.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that engagement and last open/click data are returned, which is useful context absent an output schema, but says nothing about pagination behavior or result limits.

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

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

Two tight sentences: the primary purpose and returned data are front-loaded, and the sibling routing hint follows. Every clause carries information; no filler.

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

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

With 7 parameters but 86% schema coverage and no output schema, the description does enough by naming the returned status/engagement fields and pointing to get_lead for detail. It could still mention pagination or result-size expectations, but the essential calling information is present.

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 86%, and the schema documents tags, limit, cursor, search, status and engagement thoroughly. The description only alludes to status/engagement as returned fields, adding no filtering syntax or semantics beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb and resource (list leads of a campaign) plus the scope of returned data (status and engagement: emails opened/clicked, last open/click). It explicitly differentiates itself from get_lead, so an agent can pick between the list and the detail tool without reading 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?

Provides a clear routing rule: use this for listing leads with status/engagement, use get_lead for a lead's progress through the sequence. It gives no exclusions or edge-case guidance (e.g., very large campaigns, when to prefer filtering), but the alternative is named explicitly.

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 readOnly, idempotent, non-destructive, closed-world behavior. The description adds useful context by saying searches originate in the dashboard and that status/progress are returned, though it does not discuss pagination behavior beyond the schema.

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

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

The description is short and front-loads the resource and returned fields. The first sentence is grammatically a fragment, but it remains efficient and wastes little space.

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

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

For a simple read-only list tool with complete parameter documentation and rich annotations, the description covers purpose, origin of searches, and returned status/progress. No output schema is needed for an agent to 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 description coverage is 100%, so limit and cursor are already fully documented in the schema. The description adds no parameter-specific meaning, which is acceptable at baseline 3 when the schema does the work.

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

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

The description identifies the resource concretely ('Lead Finder searches of the workspace') and the data returned ('status and progress'), which is enough to distinguish it from mutation siblings like add_leads or get_lead_search. It is a noun phrase rather than a verb-led statement, 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?

The sentence 'Searches are started in the dashboard' usefully signals that this tool only lists existing searches and does not create them. However, it does not explicitly compare with get_lead_search or state when to use this versus that sibling.

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 readOnlyHint, idempotentHint and destructiveHint, so the safety profile is done. The description adds useful domain context beyond that — what the returned fields are and how to interpret negative statuses, which the agent cannot infer from the enum alone.

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

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

Two tight sentences, front-loaded with what is listed and immediately followed by the operative status interpretation. No filler or repetition of 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?

There is no output schema, yet the description enumerates the returned fields (status, health score, warmup, limits) and names `statusMessage`, covering the essentials for a paginated read tool whose safety annotations are already 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?

With 80% schema coverage the baseline is 3, but the description adds real interpretive value for the `status` enum: it explains that `failed` or `revoked` means the mailbox cannot send and points to `statusMessage`. That meaning is not present in the schema's unlabeled enum.

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

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

States a specific verb (List) and resource (connected sending mailboxes) plus the fields returned (status, health score, warmup, limits). The plural verb implies a collection read that contrasts with the sibling get_mailbox, though it doesn't explicitly name that alternative.

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 — this is the tool for enumerating mailboxes — but there is no explicit guidance on when to use it versus get_mailbox or when to filter by status/tagIds. No exclusions or prerequisites 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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds meaningful content beyond that: it enumerates the returned payload (trigger, start and sending settings, emails with steps and A/B variants, enabled/state flags, and entered/in-progress/replied/positive counters), which substitutes for the absent output schema. It does not mention pagination or ordering, which keeps it off a 5.

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

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

A single dense sentence, front-loaded with the resource and then the return contents; every clause (trigger, settings, emails, enabled state, counters) conveys information an agent would otherwise have to discover by calling. It is long but not padded, though splitting the return-field list from the definition would improve scannability.

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

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

For a single-parameter, read-only list tool with no output schema, the description does the heavy lifting by describing return structure, which is exactly what an agent needs. Gaps are minor: result ordering, pagination, and behavior for an unknown or empty campaign are unstated.

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

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

Schema description coverage is 100% and campaignId is documented as a UUID, so the schema carries the parameter meaning. The description only implies scoping via 'of a campaign' and adds no format or constraint detail beyond the schema. 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?

The description names the resource (subsequences of a campaign) and defines it precisely as 'follow-up flows that start on a lead status, a reply, an open, a click or a finished main sequence,' which lets an agent distinguish this from the campaign-level siblings get_campaign and list_campaigns. It reads as a noun phrase rather than an explicit verb, so the 'list' action comes mostly from the name and title, 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?

There is no when-to-use guidance: nothing says whether to call this instead of get_campaign (which may also surface subsequence data) or before enroll_in_subsequence / update_subsequence. No prerequisites, no empty-state behavior, and no indication of what happens if the campaign has no subsequences.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description's one added fact — that the write applies to *every* email of the conversation, not just one — is genuinely useful scope disclosure. However, it is silent on whether the change is reversible, whether it clobbers any existing state, and what gets returned.

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

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

A single front-loaded sentence with zero filler or redundancy. The scope qualifier ('every email of a conversation') is placed where it matters most.

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, low-complexity mutation with rich annotations and no output schema, the description is nearly sufficient. A note on irreversibility or the all-or-nothing nature of the thread-level write would close the remaining gap.

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

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

Schema description coverage is 100%, and the schema already explains that 'threadId' may be any email in the conversation plus its UUID pattern. The word 'conversation' in the description loosely maps to threadId but adds no format or resolution detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('mark ... as read') and resource ('every email of a conversation'), which is unambiguous. It does not explicitly differentiate from any sibling (no bulk_update_emails exists), but no sibling would be confused with it either, so this is clear rather than exemplary.

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

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

The description gives no when-to-use context, prerequisites, or alternatives — e.g. whether it should follow get_email or list_emails, or how it relates to count_unread_emails. The agent must infer all usage conditions 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?

Annotations already declare idempotentHint=true, destructiveHint=true and readOnlyHint=false, so safety is covered; the description adds the meaningful behavioral fact that no further messages are sent until resume_campaign, which tells the agent the effect and its reversibility. It does not describe error behavior (e.g., pausing an already-paused or nonexistent campaign), keeping it below a 5.

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

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

Two sentences, no filler, front-loaded with the action and immediately followed by the consequence. Every clause earns its place.

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

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

For a one-parameter, annotation-rich, output-schema-less tool, the description covers action, effect, and reversal path. It omits any error or prerequisite behavior for paused/nonexistent campaigns, which is a minor but real gap.

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

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

Schema coverage is 100% with a single documented UUID parameter, so the schema fully carries parameter meaning and the description adds nothing about it. Baseline 3 is appropriate.

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

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

States a specific verb and resource ("Pause an active campaign") and implicitly contrasts with delete_campaign/update_campaign by naming resume_campaign as the reversal path, so an agent can distinguish a temporary halt from a permanent removal 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?

The word "active" scopes when the tool applies, and naming resume_campaign gives the agent a clear counterpart for restarting. It stops short of explicit when-not guidance (e.g., use delete_campaign when the campaign should never resume), so it is clear context rather than full routing.

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

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

Annotations already cover safety (readOnlyHint=false, destructiveHint=true, idempotentHint=true), so the bar is lower. The description still adds real value by disclosing the downstream effect (campaigns skip the mailbox) and the state precondition, though it doesn't say whether the pause is reversible or how it interacts with running campaigns.

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, zero filler, with the effect front-loaded before the precondition. Every clause earns its place.

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

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

For a single-parameter mutation with annotations covering the safety profile and no output schema, the description supplies the essential effect and precondition. It is nearly complete, missing only reversibility/resume guidance.

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 (`id`) with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about the id beyond what the schema states, making the baseline 3 appropriate.

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

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

States a specific verb ('Stop') and resource ('mailbox') plus the operational effect ('campaigns skip it'). It does not explicitly contrast with the sibling resume_mailbox, so it falls just 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?

Gives a clear precondition — only an `active` mailbox can be paused — which tells the agent when the call is valid. It stops short of naming the alternative (resume_mailbox) or stating when pausing is preferred over other mailbox 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?

Beyond the annotations (destructive/openWorld/not-idempotent) the description adds real context: sender is derived from the owning mailbox, only the body plus optional cc/bcc are supplied, a sent email cannot be recalled, and duplicate replies within 24h are delivered once. That is meaningful behavioral disclosure the annotations do not carry; only error/rate-limit behavior is left 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?

Front-loaded with the purpose, then four tight sentences that each earn their place: derived-field behavior, the irreversibility warning, and the 24h dedup rule. No filler or restatement of the name.

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

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

With no output schema the description should ideally say something about the result, and it does not; error behavior is also absent. Otherwise it is complete enough to call correctly given the annotations and partial schema.

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

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

Schema coverage is 50% (id and body are documented; cc/bcc are not). The description compensates by clarifying that the caller supplies only the body with optional cc/bcc, and that to/from are derived from the conversation and owning mailbox — non-obvious semantics not present in the schema.

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

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

States a specific verb and resource ('Send a real reply within the email's conversation') and pins the scope to the owning mailbox. The word 'reply' and 'within the conversation' behaviorally separate it from forward_email and send_test_email among the 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?

Usage is only implied: the agent can infer this is for responding to an existing email it owns. It never says when to use it versus forward_email or send_test_email, and gives no when-not conditions or prerequisites.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description goes beyond them by explaining what that destruction means in practice: real emails resume going out on the existing schedule. It does not address the non-idempotent hint (i.e., that repeated calls or double-resume may be problematic), so it is good but not complete.

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

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

One sentence, front-loaded with the action, zero filler. It is a little thin for a mutation tool, but nothing is wasted and the key consequence is stated immediately.

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

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

For a simple one-parameter state-change tool with annotations covering the safety profile and a fully documented schema, the main missing piece an agent needs — the real-world effect of resuming — is present. Remaining gaps (idempotency, auth requirements) are 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?

Single parameter with 100% schema description coverage ('Campaign id (UUID)'), so the schema fully documents it. The description adds no additional meaning about the id, which is expected — baseline 3 applies.

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

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

Specific verb 'resume' plus resource 'campaign', and 'a paused campaign' implicitly separates it from start_campaign (which begins a new send) and pause_campaign. It stops short of naming those siblings explicitly, so an agent must infer the routing.

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

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

The phrase 'a paused campaign' implies the precondition (the campaign must currently be paused), which is useful context. However, there is no explicit statement of when to prefer this over start_campaign, nor any note about required permissions or failure modes if the campaign is not paused.

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 readOnly=false, idempotent=true, openWorld=true and destructive=true, so the safety profile is largely given. The description still adds real value beyond them: the asynchronous nature of the `failed` recovery and the caveat that the response may keep showing `failed`/`checking` until the test settles. It does not address why the operation carries a destructive hint (resuming may start outbound sending).

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 front-loaded sentence opens with the action, then branches cleanly on mailbox state, with the only parenthetical reserved for a genuinely surprising async caveat. No filler 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 one-parameter state-change tool with no output schema, the description supplies the essential pieces: what it mutates, the two state branches, and why the observed result may lag. The remaining gap is that it never explains the destructive/idempotent implications an agent might weigh before invoking.

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 parameter and schema description coverage is 100% (the schema documents `id` as a UUID mailbox id), so the schema carries the semantics. The description adds no format, constraint, or identifier nuance beyond it; baseline 3 applies.

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

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

States a specific verb and resource ('Bring a mailbox back') and elaborates the two exact state transitions it performs (`inactive` → sending, `failed` → connection test → service). The reversal of pause_mailbox is implicit in the verb, but no sibling is named, so an agent gets clarity without 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?

It effectively defines the trigger conditions by describing exactly which mailbox states it applies to (paused/inactive, failed), which tells the agent when this tool is the right call. It stops short of naming alternatives, e.g. check_oauth_connect or delete_mailbox, or saying when NOT to resume.

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 non-obvious behavior beyond the annotations: a 12/day per-workspace cap and a 24h dedup window where a repeated call will not resend unless a fresh `resend` value is passed. The annotations only supply coarse flags (readOnly=false, destructive=true, idempotent=false); the description explains the actual dedup semantics that nuance that flag. It does not say what the call returns or whether it affects campaign analytics.

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

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

Three dense sentences, front-loaded with what the tool does before the identifier sourcing and the rate-limit/dedup caveats. Every sentence earns its place and nothing is repeated.

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

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

For a 7-parameter, 4-required mutation tool with no output schema, the description covers the operational risks (rate limit, dedup, forced resend), which is the main thing an agent needs. Minor gap: it never clarifies whether a test send consumes production quota or pollutes campaign statistics, and the destructiveHint=true annotation is left unexplained.

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

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

Schema description coverage is 100%, and the schema already documents variantId provenance, resend ('never sent to the API'), personalization enum behavior, and leadId. The description largely restates the variantId/accountId sourcing already present in the schema, adding no new syntax or format detail. Baseline 3 is correct when the schema carries the weight.

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

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

States a specific verb and resource (send one rendered preview of a sequence step variant) plus the exact scope: single address, chosen mailbox, rendered as a lead would see it. An agent can immediately distinguish this from campaign-sending tools like start_campaign or from get_campaign, which merely supplies the variant id.

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

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

Gives concrete provenance guidance ('Take variantId from get_campaign', 'accountId from list_mailboxes') and the resend condition, which is genuinely actionable routing. It stops short of stating explicit exclusions (e.g. 'do not use for real sends' or how it differs from actually launching the campaign), so it is clear context without formal when-not guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description adds exactly the context that matters: emails are sent on the schedule, already-sent emails cannot be recalled, and pause_campaign is the only lever over the rest. That is concrete irreversibility detail beyond the annotation flags.

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

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

A single dense sentence that front-loads the action, then the consequence, then the escape hatch. Every clause earns its place; only the parenthetical placement slightly interrupts the flow.

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 output schema and rich annotations, the description covers the key risks (irreversibility, preconditions, stopping mechanism). It falls short only on sibling disambiguation against resume_campaign, which is the main remaining ambiguity.

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 (id) with 100% schema description coverage, so the schema fully documents it. The description's lead/sequence requirement describes campaign state rather than the id argument, adding no syntax or format meaning beyond the schema.

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

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

States a specific verb and resource ("Start sending a draft campaign") and clarifies the effect is real emails going to leads. Implicitly differentiates from resume_campaign by scoping to a draft, but never names resume_campaign as the sibling that handles paused campaigns, so an agent must infer that 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?

Gives a concrete precondition ("Needs at least one lead and a sequence") and points to pause_campaign as the way to stop remaining sends. However it offers no explicit guidance on when to use this versus resume_campaign, leaving the draft-vs-paused choice 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?

Adds substantial context beyond annotations: two return fields (authorizationUrl, state), the hand-off to the user's browser, and a 10-minute link expiry. It does not explain why destructiveHint is true (e.g. whether re-connecting replaces/revokes an existing mailbox connection), which is the one remaining behavioral 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 tight sentences, front-loaded with the action, then the return contract, then the follow-up loop and expiry. No filler; every clause carries information the caller 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?

With no output schema, the description covers the return payload, the required user interaction, the polling procedure, and the expiry window. For a 1-param initiation tool this is 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 0% for the single 'provider' param, but the description compensates by spelling out that the two enum values correspond to Google Workspace and Microsoft 365 mailboxes. That gives the enum contextual meaning beyond the bare values.

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 ('Start connecting') plus resource ('Google Workspace or Microsoft 365 mailbox by OAuth') and explicitly distinguishes itself from the sibling it hands off to (check_oauth_connect). The '(no password)' note sharpens what kind of connection this is.

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

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

Gives explicit sequencing: call this, hand authorizationUrl to the user, then poll check_oauth_connect with the returned state every few seconds until 'connected' or 'failed'. Names the follow-up tool and the terminal states, leaving nothing 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?

Goes well beyond the annotations by disclosing that sequence/accounts/tagIds replace wholesale, that steps and variants receive new ids, and that a running campaign's sequence update is rejected atomically. However, several of these replacement semantics are already documented in the schema field descriptions, so the marginal value is real but partly duplicated.

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 rule — only passed sections change — then layers the replacement caveats in order of risk. It is dense and readable, though the long compound sentences demand careful parsing.

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 partial-update tool with a deeply nested schema and no output schema, it covers the highest-risk behaviors: replacement, id churn, and rejection when a campaign is running. Permissions or auth requirements are not mentioned, which 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 86%, so the schema already documents parameters thoroughly, including REPLACES semantics on tagIds, accounts and sequence. The description reinforces the variant/step shape but adds little that the nested field descriptions do not 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?

"Change a campaign" states a specific verb and resource, and the surrounding sentences make clear this is a partial-update tool rather than a creation or deletion one. It never names create_campaign or get_campaign as the alternatives explicitly, so sibling differentiation is implied rather than stated.

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

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

Gives concrete when-to-use context: pass only the sections you want changed, pause a running campaign before replacing its sequence, and re-read get_campaign before send_test_email. It lacks explicit when-not-to-use guidance (e.g. versus update_subsequence or create_campaign), which keeps it below 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 a non-read-only, idempotent, destructive mutation, so the safety profile is covered. The description adds a genuine behavioral constraint not present in the annotations or schema: the email field is only mutable before first contact. It does not explain what 'destructive' means for field overwrites, but the annotation carries that.

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

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

Two sentences, zero waste, and the core action is front-loaded ahead of the constraint. Nothing could be trimmed without losing information.

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

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

For a 15-parameter destructive mutation with nested objects and no output schema, the description is thin. It omits whether omitted fields are left unchanged, how customFieldTypes/customFieldLabels interact with customFields, and any permission requirements, though annotations and the partial schema cover some ground.

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 47%, so the description must compensate. It names the parameter categories (fields, tags, custom fields, status, email) and flags the email precondition, which maps to several of the 15 parameters, but adds no format or syntax detail for the many undocumented scalar fields (website, jobTitle, location, etc.).

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 ('Change a lead's fields, tags, custom fields or status') and enumerates the updatable categories. The singular 'a lead' implicitly separates it from the bulk_* siblings, 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?

The precondition 'The email can only change before the lead is first contacted' is usage-relevant, but there is no explicit guidance on when to prefer this over bulk_set_lead_status, bulk_add_lead_tags, or update_campaign. Usage is implied rather than stated.

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

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

Annotations already declare this is a non-readonly, idempotent, open-world, potentially destructive mutation. The description adds substance beyond that: it confirms PATCH-style partial semantics (supporting the idempotency hint) and warns that credential fields are rejected server-side, which the annotations cannot convey. It says nothing about what 'destructive' means here or about reversibility, so it is helpful 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?

Three short sentences: the change scope is front-loaded, then the partial-update rule, then the exclusion. Every clause earns its place and nothing is padding.

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

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

For a 13-parameter mutation with nested warmup/tracking objects, no output schema, and annotations covering the safety profile, the description supplies the key missing behavior: partial updates and the credential rejection. It could still say more about reset/clear semantics and error behavior, but it is sufficient 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 77%, so the schema already documents most parameters including constraints and the empty-string clears replyToAddress. The description names parameter groups in prose but adds no format, unit, or default detail beyond the schema's own text. Baseline 3 for a high-coverage 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 ('Change') on a specific resource ('one mailbox') and enumerates the editable attribute families (sender name, campaign cap, sending gap, signature, reply-to, BCC, tracking domain, warmup, language). The phrase 'one mailbox' also separates it from the sibling bulk_update_mailboxes, so an agent can route without opening either schema.

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

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

Gives real usage context: partial-update semantics ('Only the fields you pass change') and an explicit when-not ('SMTP/IMAP credentials are not accepted here ... the user changes them in the MailBeast dashboard'). It does not state when to choose this over bulk_update_mailboxes or note prerequisites/permissions, so it stops short of full routing guidance.

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

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

Annotations already flag destructiveHint=true; the description adds the non-obvious mechanics: section-level replacement rather than merging, regenerated step/variant ids, and atomic rejection ("the whole call is then rejected and nothing changes"). This is exactly the behavior an agent could not infer from the schema. Minor tension worth noting: the annotation claims idempotentHint=true while the text says ids are regenerated on each replacement, though the resulting data state is equivalent.

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 patch semantics, and each clause carries information. The second sentence is long and semicolon-heavy, requiring a careful read to parse the replacement rule and the id-regeneration consequence.

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 deeply nested mutation schema with no output schema, the description covers the critical semantics: partial update scope, replacement granularity, and the blocking precondition. It does not mention permissions/ownership requirements or what is returned after a successful update, which leaves a small gap given the 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?

Schema coverage is 80%, so the baseline is 3, but the description adds real meaning by explaining the replace-vs-patch contract for `sequence` and the `settings` sub-objects, which the schema does not state. It does not describe the required `id` or the inheritance behavior of mailboxes/tracking beyond the schema's own note.

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?

"Change a subsequence" gives a clear verb plus resource, and the opening word "Change" plus the PATCH-style explanation makes it distinguishable from create_subsequence and update_campaign. It does not explicitly name sibling tools for routing, so it stops 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?

It clearly states the operating context: only supplied fields change, but each settings section and `sequence` are full replacements. It also gives an explicit when-not — emails of a running subsequence cannot be replaced — without naming an alternative tool, so it is clear context rather than full alternative routing.

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