Emailchaser

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

Annotations cover idempotency, non-destructiveness and closed-world scope, and the description adds genuinely new behavior: skipped existing/invalid values, per-value type inference, and the main-workspace-only constraint on global scope. It does not say what the call returns (counts of added vs skipped), which is the main remaining gap.

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

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

Front-loads the core action and batch ceiling, then layers constraints in a compact block with no filler. The final sentences are slightly dense and chain multiple clauses, but every sentence carries load-bearing information.

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

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

For a two-parameter write tool with no output schema, the description covers input rules, scope semantics, skip behavior and retry safety well. The one omission is the shape of the response (e.g., how many were added vs skipped), which an agent would want to know for verification.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: how each value's type is inferred from the presence of "@", and that scope defaults to workspace while global requires the main workspace. This exceeds what the enum description conveys.

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

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

States a specific verb (adds) and resource (suppression/blocklist entries) with the batch size ceiling, and is instantly distinguishable from siblings like remove_blocklist_entries, get_blocklist_entry and add_leads. The per-value type inference rule further pins down exactly what the tool accepts.

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 use case (carrying over a suppression list from another sending platform) and a retry-safety condition, plus the scope default and the restriction that "global" only works from the main workspace. It stops short of naming the sibling tools (remove_blocklist_entries, update_blocklist_entry) an agent might confuse it with, so not a full 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 description discloses far more than annotations: costs per person, metered email verification, non-idempotent repeat behavior ('repeating the same add adds the NEXT count people and charges again'), concurrency limits, and response fields like estimatedCredits and importId. It also explains skip conditions and edge cases such as catch-all addresses.

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 extremely long and dense, covering many edge cases without visual structure (no headings or bullets). While each sentence adds value, the sheer length makes it harder for an agent to parse quickly. Some details, such as verifyEmails behavior, are repeated from the schema, and the opening warning is front-loaded but the rest is a wall of text.

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

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

With no output schema, the description fully covers return values, errors, prerequisites, and follow-up actions. It names related tools for polling (get_lead_finder_import), filter limits (get_lead_finder_filters), and credit purchases (purchase_credits), making it complete for correct invocation.

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 baseline is 3, but the description adds critical behavioral semantics beyond the schema: mutual exclusivity of refs and filters, how repeat filters adds walk from the top and skip already-leads, and verification details for verifyEmails. It also clarifies that duplicates are dropped, which is not fully explicit 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 opens with a specific verb and resource: 'Adds people from the Lead Finder contact database to a campaign as leads, revealing their contact details, in the background.' It clearly differentiates this from sibling tools like add_leads by tying it to Lead Finder and credits.

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 explicitly describes two usage modes and when to use each: 'Pass refs ... to add exactly those people, or pass filters and count ... to add count people matching the filters.' It also provides strong anti-retry guidance ('Never repeat an add to retry: after an error or a timeout, call list_lead_finder_imports') and prerequisites ('Check get_credit_balance first').

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=false, and openWorldHint=false, so the safety profile is covered; the description adds substantive behavior beyond that: dedup-by-email upsert semantics, the return payload ('the id of every lead written'), and how customVariables become merge tags. It doesn't discuss permissions, rate limits, or partial-failure behavior for a 1,000-item batch, which keeps it from 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?

Four front-loaded sentences, each carrying distinct information (capacity, upsert rule, return value, custom attributes) with no filler. The closing customVariables sentence mildly overlaps with the schema, so not a perfect 5.

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

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

With no output schema, the description compensates by stating the return value (lead ids for subsequent fetch/update). Batch limits, dedup behavior, optional campaign attachment, and custom attribute handling are all present, leaving no material gap for correct invocation.

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 email, the named fields, customVariables, and campaignId. The description restates the customVariables merge-tag concept and explains campaignId's purpose, but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Creates or updates ... leads') with scope ('up to 1,000 in one request') and an optional side effect ('adding them to a campaign via campaignId'). This cleanly separates it from single-record siblings like update_lead and read-only siblings like list_leads/get_lead.

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

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

Explains the upsert rule clearly ('Existing leads (matched by email) are updated instead of duplicated'), which tells the agent when this tool is the right choice for existing contacts, and notes campaignId is optional. It stops short of explicitly naming alternatives (update_lead for one record, list_leads to discover leads), so it's clear context without explicit 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 are minimal (openWorldHint, destructiveHint) and do not mention the real-money impact. The description fully compensates by detailing financial implications: 'CAN SPEND REAL MONEY,' cost per credit, order placement conditions, and limits on domains/mailboxes. It also specifies that nothing happens before the call and that sending starts after. This is exemplary transparency beyond 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?

The description is lengthy but every sentence carries critical information: purpose, financial risk, conditions, and prerequisites. It front-loads the core purpose and then layers constraints. While not terse, the density is justified given the high-stakes nature of the operation.

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

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

Given the complexity (monetary transactions, conditional behavior, caps), the description covers all necessary details: what happens, what fails, the need to show the plan first, and the irreversible nature after the call. There is no output schema, but the description does not need to explain return values for a confirmation action. It is complete for correct invocation.

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

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

The single parameter 'id' is fully documented in the schema with description and constraints. The tool description does not add new semantics about the parameter, but the schema covers it 100%. Since the schema does the heavy lifting, the baseline of 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 states a specific verb, resource, and context: 'approves an autopilot run that is awaiting approval — the one human gate in the flow.' It clearly distinguishes this from siblings like start, pause, resume, and kill by focusing on the approval action. The purpose is immediately clear without confusion.

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 provides clear usage context: it is the human-gate step, and it instructs to 'Show the user the plan from the start_autopilot_run response before calling this.' It also clarifies the consequences (sending starts without further confirmation). It does not explicitly name alternatives but implies its unique role in the flow, making it distinguishable from related tools like kill_autopilot_run.

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 (idempotentHint, destructiveHint=false), the description discloses three substantive traits: the idempotent merge behavior (existing senders untouched, only missing ones added), the all-or-nothing refusal when any sender is invalid, and the side effect of rescheduling a running campaign. These are exactly the behaviors an agent needs before invoking a mutating attachment.

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

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

Four tight sentences, front-loaded with the core action, then escalating to idempotency, atomicity, and side effects. No filler, and each sentence carries distinct decision-relevant information.

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

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

For a two-parameter mutation tool with annotations covering the safety profile and no output schema, the description covers purpose, idempotency, failure mode, and side effects. An agent has everything required to call it correctly.

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

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

Schema description coverage is 100% and both parameters are documented there, so the baseline is 3. The description reinforces the constraint that every sender must be a connected workspace sender, but that validation rule is already in the schema; the added value (whole-call refusal) is more behavioral than parameter-specific.

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

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

The description opens with a specific verb and resource ('Attaches connected sender email accounts to a campaign') and immediately clarifies the effect ('this call decides which mailboxes it uses'). It is trivially distinguishable from the sibling detach_campaign_sender_email by direction of the operation. Nothing about the purpose is left ambiguous.

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

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

It gives clear operational context ('a campaign only sends through the senders attached to it') that tells the agent why and when this call matters. It does not, however, explicitly name alternatives or state when-not to use it (e.g., how it relates to connect_sender_email or create_campaign), so it stops short of full when/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 idempotent and non-destructive hints. The description adds valuable behavioral context about billing and result retention: already-verified addresses remain billed and in results, while unprocessed ones are never charged. This goes beyond what annotations convey and helps the agent understand side effects.

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

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

The description is two sentences with no wasted words. The primary purpose is front-loaded, and the second sentence concisely explains the billing and results consequences. Every sentence 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 simple one-parameter tool with no output schema and annotations covering idempotency and non-destructiveness, the description provides the necessary purpose and side effects. It does not mention response format, but that is not critical for a cancellation action.

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

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

The schema covers the only parameter (jobId) with a minimal description 'The job ID', so baseline is 3. The tool description adds no extra information about the parameter itself, but the parameter is self-explanatory given the tool name.

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

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

The description states a specific verb ('Stops') and resource ('a running verification job'), clearly distinguishing it from creation, listing, or retrieval of verification jobs. The billing note further clarifies the scope of action, making the purpose unambiguous.

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

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

The description implies the tool is for stopping a running verification job, which is clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the sibling context and action verb make the use case obvious.

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?

Even though annotations already mark this as destructive and idempotent, the description adds crucial behavioral detail: written batches are still added and charged, screened/verified batches may still incur billing, credits are released, people already added stay, and status fields can change until finishedAt is set. This goes well beyond the annotations and warns about real side effects.

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 dense but every sentence adds necessary operational nuance: cancellation timing, billing implications, credit handling, status uncertainty, permanence, and the no-op case. It is front-loaded with the core action and then layers detail in a logical order without fluff.

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 asynchronous destructive operation with billing side effects and no output schema, the description covers all decision-relevant behavior: what is dropped, what is charged, what happens to credits, eventual status changes, permanence, and alternative next steps. Nothing an agent needs to invoke it correctly is missing.

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

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

The only parameter, id, is fully documented in the schema with 100% coverage, including its source (importId from add_lead_finder_prospects or list_lead_finder_imports). The description does not need to repeat parameter semantics, so the baseline score of 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 opening sentence states a specific verb and resource: "Stops a running Lead Finder add." It is clearly distinct from sibling tools like add_lead_finder_prospects (which starts imports) and get/list_lead_finder_imports (which monitor them), so an agent can tell exactly what this tool does.

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 explicit when-to-use context (only a running add can meaningfully be stopped), a when-not-to-use signal ("Stopping one that already finished changes nothing"), and an alternative ("start a new add_lead_finder_prospects instead" since a stopped add cannot be resumed). This fully routes the agent.

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 idempotency and non-destructiveness, but the description adds real behavioral context: it writes the assistant name and timestamp onto the key, that record is what the app's API & MCP page surfaces to the user, it completes an onboarding step, and it works with read-only keys. That permission and side-effect disclosure goes well beyond the annotation set.

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

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

Front-loaded with the core effect, then trigger conditions, then side effects and the idempotency caveat. It runs slightly long and the idempotency clause partially duplicates the annotation, but every sentence carries actionable information.

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

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

For a zero-required-parameter, no-output-schema tool, the description covers purpose, timing, side effects and permission compatibility. It does not describe the shape of the confirmation response (e.g. what 'confirms the API key works' returns on failure), which is the only meaningful 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 single 'agent' parameter is thoroughly documented in the schema (free-form name, normalization, echo behavior). The description does not mention the parameter at all, so it adds no value over the structured field; 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 effect: confirms the API key works and registers which AI assistant connected. No sibling tool does anything comparable, so the agent can distinguish it immediately from the read/write tools in the list.

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

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

Gives explicit triggers: 'call it as your first action after connecting' and 'whenever the user asks you to confirm or check the Emailchaser connection'. It also defines the state it completes ('the Connect your AI onboarding step'), removing any ambiguity about timing.

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

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

Annotations only declare openWorldHint and destructiveHint=false, and the description adds substantial context: the app-password requirement, provider exclusions, domain rejection behavior, and that the returned account's healthScore stays null until warm-up scans 20 emails. It stops short of covering auth prerequisites for the API or failure/error modes, so a 4 rather than 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?

Four front-loaded sentences that each carry a distinct constraint (mechanism, provider exclusion, domain rule, return semantics). No filler, though it is denser than strictly necessary for a short 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 7-parameter creation tool with no output schema, the description covers the key behavioral surprises: eligibility rules, the non-automatable providers, and the null healthScore return value. An agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all seven parameters including app-password and business-domain semantics are already documented in the schema. The description reinforces the business-domain constraint but adds no syntax or format detail beyond what the schema provides, 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 (connects) and resource (SMTP/IMAP mailbox to workspace) with the mechanism (app password, no browser). It explicitly distinguishes itself from siblings by naming get_sender_email and contrasting with the in-app flow for Google/Microsoft.

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-not-to-use (Google and Microsoft mailboxes require interactive consent and must be connected in the app) and a hard eligibility rule (business domain only, gmail.com rejected). The agent can route correctly without further 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 cover the safety profile (destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds real behavior beyond that: nothing is sent, the campaign remains a draft until reviewed, and it returns a campaign id plus a lead-finding job id when finding starts.

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

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

Four tightly packed sentences, front-loaded with the core action and constraint ('Nothing sends'). Every sentence adds information: mode branches, the safety guarantee, and return values.

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

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

No output schema exists, yet the description documents the return shape (campaign id, optional lead-finding job id). Combined with 100% schema coverage of the nested sequence object and the annotation safety profile, an agent has what it needs 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 coverage is 100%, so the baseline is 3. The description goes further by explaining the conditional relationship between the LinkedIn search and lead-finding: salesNavSearchUrl's presence/absence changes behavior, and lead finding only runs when the session payload is supplied.

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 ('Creates a DRAFT campaign from a sequence') and immediately scopes what it does not do ('Nothing sends — the campaign stays a draft'). This disambiguates it from the sibling launch_campaign, which presumably does send, despite the 'copilot_launch' name.

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 explains the two operating modes: with a Sales Navigator search it starts lead finding; without one the draft holds only emails, and leads come from Lead Finder or CSV. It does not explicitly say when to prefer this over sibling create_campaign or when to call copilot_plan first, so it stops short of full when/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 cover openWorldHint and destructiveHint, but the description adds behavioral context: 'Read-only — creates nothing' clarifies persistence semantics that readOnlyHint alone might not convey, and it discloses the return payload (ICP fields plus a draft sequence). It stops short of stating latency or cost, which is fine given the annotation baseline is met.

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 input and output, then a behavioral note and a routing pointer. Every sentence carries information an agent needs; nothing is repetitive with 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?

For a 2-param planning tool with annotations covering safety and no output schema, the description specifies the input, the produced artifacts, and the downstream handoff. What's missing is whether the output is persisted or ephemeral and whether re-running overwrites anything, but overall an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so both 'website' and 'context' are documented in the schema with examples. The description adds no syntax or format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource ('builds an ideal-customer-profile and a suggested cold-email sequence') with the input that drives it ('given a company website'). It names the sibling consumers ('pass to copilot_launch'), so it is distinguishable from create_icp, plan_autopilot, and copilot_launch despite those siblings' similar names.

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?

Implies when to use it — planning before launch — and names copilot_launch as the downstream step, giving context. It doesn't explicitly state exclusions (e.g., 'use create_icp instead if you want a persisted ICP'), but the planning-to-launch flow is clear.

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

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

Annotations only declare openWorldHint=false and destructiveHint=false; the description adds real behavioral context beyond them — the new campaign is a non-sending DRAFT with no emails, and launch is blocked until sequence and sender are added. It does not describe return values, but the state/lifecycle disclosure is meaningful added value.

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 core action, then the resulting state, then the prerequisite chain, then where settings live. Every sentence earns its place with no redundancy.

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

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

For a 20-parameter creation tool with full schema coverage and no output schema, the description supplies the key lifecycle and prerequisite information an agent needs to sequence these calls correctly. It does not mention what the call returns, but with no output schema that is a minor gap against otherwise strong coverage.

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 all 20 parameters in detail. The description only groups them loosely ('sending limits and deliverability settings can be set here'), adding no per-parameter meaning 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 ('Creates a campaign in the workspace') and distinguishes it from siblings by naming replace_campaign_sequence and update_campaign in context. The DRAFT lifecycle statement further clarifies what this tool specifically does.

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

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

Gives clear prerequisites and lifecycle context: the campaign starts as a DRAFT, sends nothing, and cannot be launched until a sequence is written and a sender email attached. It names the follow-up tools (replace_campaign_sequence, update_campaign) but does not phrase explicit when-to-use/when-not conditions, so it falls just 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?

Beyond the annotations, the description discloses the significant financial impact ('SPENDS REAL MONEY'), pricing details, immediate acceptance with background provisioning, and the redirection behavior of purchased domains. It also explains the refusal condition. This is substantial behavioral context the annotations do not provide.

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 longer than typical but every sentence carries critical information: the money warning is front-loaded, then pricing, then workflow, then validation rule. The structure is logical and scannable, with the most important warning in caps first. It is 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?

For a tool that spends money and has 3 parameters, the description covers prerequisites, costs, validation rules, and post-creation polling. The only minor gap is the exact return shape, but since the description points to get_dfy_order for progress, an agent can proceed safely. Given the absence of an output schema, this is complete enough.

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 input schema already provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds value by quantifying costs for domains and mailboxes, and by re-emphasizing the domain-mailbox relationship and the option to attach mailboxes to earlier order domains. While some info duplicates the schema, the cost and process details go beyond it.

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

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

The description clearly states the action ('Places a real order'), the resources (domains and mailboxes), and distinguishes itself from siblings by directing to search_dfy_domains first and get_dfy_order after. It leaves no ambiguity about what the tool does.

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 explicitly instructs to use search_dfy_domains first to confirm availability and price, and to poll get_dfy_order for progress. It also details the hard precondition (every domain must have a mailbox) and the consequence (order refused). This gives the agent concrete when-to and when-not-to 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?

The description extensively discloses behaviors beyond the annotations: it spends money and adds metered usage to the invoice, does not use prospect credits, bills only valid verdicts, removes duplicates, returns unparseable entries separately, requires an active subscription, and handles quota exhaustion gracefully. This fully compensates for the lack of a readOnlyHint and clarifies the openWorldHint/idempotentHint 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?

The description is long but every sentence carries material operational or financial information. The 'SPENDS MONEY' warning is front-loaded, and the structure flows from cost, to behavior, to subscription requirements, to job lifecycle, making it easy to scan despite its length.

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 money-spending async job with no output schema, the description covers prerequisites, pricing, edge cases, failure modes, and the full polling/retrieval flow. An agent has everything needed to decide whether to call it, budget for it, and retrieve the results 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 100%, and the schema already documents both parameters, so the baseline is 3. The description adds meaningful value by explaining the billing implications of the emails parameter, noting that duplicates and unparseable entries are removed before charges, and that the response total is what gets billed. This goes beyond the schema's wording and helps the agent reason about cost.

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 action: it verifies a list of email addresses and returns a per-address verdict downloadable as CSV. It also explicitly distinguishes this from a campaign and from using prospect credits, so an agent can tell it apart from sibling tools like create_campaign and get_email_verification_rates.

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 an explicit workflow: call get_email_verification_rates first to budget, then create the job, poll get_email_verification_job until state is done, and finally read results with list_email_verification_results. It also states what the tool does not do (no campaign, no prospect credits), providing clear routing among alternatives.

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

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

Annotations only declare openWorldHint=false and destructiveHint=false, so they carry little behavioral weight. The description adds real context: the profile is persisted to the workspace and makePrimary demotes any existing primary. It does not cover permissions, limits on profile count, or what happens to the profile's computed audience, leaving a modest 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?

Two sentences, no filler. The what-it-stores content leads and the routing/alternate-tool guidance follows, which is the correct front-loading for selection decisions.

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 9 parameters all fully described in the schema and no output schema to explain, the description's job is selection and behavioral framing, which it covers well. The one meaningful omission is guidance on the relationship to update_icp, get_icp, and set_primary_icp, which a sibling-aware agent would benefit from.

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 every parameter, including makePrimary, is documented in the schema itself. The description restates the criteria categories and the makePrimary effect but adds no format or syntax detail beyond what is already structured, so the baseline 3 applies.

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

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

States a specific verb and resource ("Stores a manually-authored Ideal Customer Profile") and immediately defines what that resource contains (titles, seniorities, industries, sizes, locations, keywords). The word "manually-authored" pre-emptively distinguishes it from the AI-driven sibling, so an agent can tell the two apart without reading 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?

Explicitly routes the agent to copilot_plan "when you want the AI to build the ICP from a website," which is a clear alternative-plus-condition pair. It also notes that makePrimary should be set to activate the profile. It stops short of stating when not to create one (e.g. duplicates of an existing ICP), so it falls just short of a full 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 state openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful delivery semantics (a POST request fires on each event) but omits auth/permission requirements, rate limits, whether a secret/signature is issued, or what happens on duplicate URLs.

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 the core action first and the event enumeration trailing. It is efficient and waste-free, though the parenthetical list is long enough to slightly blunt the opening statement.

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

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

For a 3-parameter creation tool with a fully documented schema and no output schema, the description conveys purpose and event scope adequately and the schema carries the parameters. It is only slightly thin on create-time specifics such as response contents and required-field behavior.

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

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

Schema description coverage is 100%, so the schema fully documents url, name and type. The description's event list mirrors the type enum but adds no format or constraint detail (e.g., HTTPS-only enforcement, name length) beyond structured data, 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 gives a specific verb+resource ('Registers a webhook endpoint') and even enumerates the subscribable events, so an agent immediately knows this creates an event subscription. It is distinct from update_webhook/delete_webhook/list_webhooks by verb, but it never explicitly names or contrasts those siblings, so it falls just short of a 5.

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

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

There is no when-to-use guidance and no mention of alternatives or exclusions (e.g., use update_webhook to modify an existing one, or list_webhooks to inspect). The behavior of the created webhook is described, but nothing routes the agent to or away from this tool.

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

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

Adds substantial context beyond the annotations: the API key's fullKey is returned exactly ONCE and cannot be retrieved again, the key never outlives the calling key, sub-workspace keys are rejected, and a plan requirement applies. These are operationally critical facts an agent cannot infer from openWorldHint/idempotentHint/destructiveHint.

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

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

Three sentences, each carrying distinct load: what is created, the one-time key disclosure hazard, and the authorization/plan constraints. Front-loaded with the core action and 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?

No output schema exists, so the description properly carries the return-value burden by explaining fullKey's one-time disclosure. For a two-parameter creation tool with full schema coverage, nothing needed for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by stating the key is minted by default and is read & write bound to the new workspace, clarifying the generateApiKey side effect beyond the schema's brief wording.

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 (creates) and resource (sub-workspace under the account's main workspace) with a concrete use case ('one per client, for an agency'). It also implicitly distinguishes itself from the sibling create_workspace_api_key by explaining what the creation produces.

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

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

Gives clear context and prerequisites: must be called with the main workspace's key, sub-workspace keys are refused, and it is a Professional-plan feature. It does not explicitly route to sibling tools like create_workspace_api_key for separate key minting, so it stops short of full alternative 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 only indicate openWorld=false, idempotent=false, destructive=false, leaving behavioral disclosure to the description. It openly warns that fullKey is returned exactly once and cannot be recovered, notes that the new key never outlives the calling key, and states authorization scope plus revocation path. This is exactly the kind of critical behavioral context the 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?

The description is compact yet information-dense: core action, recovery use case, one-time retrieval warning, authorization scope, and revocation location all fit into four purposeful sentences. Warnings are front-loaded after the main verb, making the critical 'only once' instruction immediately visible.

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 three-parameter tool with no output schemaebur, the description covers the full behavioral picture: what the tool does, when to use it, critical irreversibility, scope limitations, lifecycle relative to the calling key, and how to revoke. No essential contextual gap remains for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, with id, name, and readOnly each already well documented, including defaults and behavior. The description does not add parameter-level details beyond what the schema provides, so it meets the baseline without compensating for any schema gaps.

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?

Description opens with a specific action, 'Mints a new API key bound to a workspace', and clearly differentiates from siblings like create_workspace by emphasizing it is tied to an already-owned workspace and specifically designed for key recovery. The relation to sub-workspaces and main workspace keys adds precise scope.

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 states the concrete scenario: recovering a lost workspace key without UI intervention wheelchair. It may not explicitly list alternatives, but the scenario strongly implies this is the specialized tool for that case, while other create_* siblings serve different purposes. Clear context, though no explicit exclusions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description adds genuinely new context beyond the annotations: the cascade scope (emails, sequences, scheduled tasks) and the irreversibility warning, which is exactly what an agent needs before invoking a destructive call.

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 tightly written sentences with zero redundancy; the cascade scope and the irreversibility warning are both front-loaded rather than 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 single-parameter destructive tool with no output schema, the description covers the essentials: what is removed, that it is permanent, and that it cascades. It omits any note on permissions or whether related resources (e.g. leads) survive, which is a minor gap rather than a critical one.

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

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

Schema description coverage is 100% and the single 'id' parameter is fully documented in the schema, including its provenance ('from list_campaigns'). The description adds no parameter detail, 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 ('Permanently deletes a campaign') and immediately scopes the blast radius ('all associated data, including its emails, sequences and scheduled tasks'). This clearly distinguishes it from siblings like pause_campaign, update_campaign, or delete_icp.

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

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

Usage is implied by the verb and the irreversibility warning, but the description never says when to choose this over the non-destructive alternative pause_campaign, nor does it state prerequisites such as permissions or whether a campaign must be stopped first.

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, so the safety profile is known, but the description adds substantive context beyond them: irreversibility ("This cannot be undone") and the workspace-level side effect that deleting the primary leaves no active profile. It omits what happens to campaigns or other entities referencing the ICP, but for a single-ID delete this is solid added value.

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, no filler, with the core action and the most important warning (irreversibility) front-loaded. Every sentence 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 single-parameter tool with full annotation coverage and a fully documented schema, the description covers action, irreversibility, and the primary-profile edge case. Only unresolved downstream effects (e.g., impact on campaigns using the ICP) keep it from a 5.

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

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

Schema coverage is 100% and the schema already documents the single required id parameter, including its source (list_icps). The description adds nothing about the identifier, so baseline 3 is appropriate.

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

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

States a specific verb (deletes) and resource (Ideal Customer Profile) in the first sentence, which cleanly separates it from sibling deleters like delete_campaign, delete_lead, and delete_webhook. An agent can identify the target entity without opening the schema.

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

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

The description explains a consequence of deleting the primary ICP but gives no when-to-use guidance, no prerequisites, and never points to alternatives such as update_icp (to modify instead) or set_primary_icp (to reassign primacy first). The agent must infer usage entirely.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the destructive profile is structured data. The description's contribution is 'Permanently ... cannot be undone,' which clarifies that there is no soft-delete or restore path — a real addition, but thin given how much the annotations already carry.

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 zero filler: the action and its permanence are front-loaded. Nothing could be removed without losing information.

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

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

For a single-parameter destructive tool with annotations covering the safety profile and a fully documented schema, the description is nearly sufficient. It could add a note on behavior for a nonexistent ID or whether related records (e.g., conversation history) are affected, which keeps it short of a 5.

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

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

Schema coverage is 100% and the single 'id' parameter is fully documented, including its origin ('returned when the lead was created'). The description adds only the phrase 'by ID' and no format or validation detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Permanently deletes') and resource ('a lead'), with the identifier form ('by ID'). It is trivially distinguishable from siblings like delete_campaign, delete_icp, and update_lead, so an agent can select it without ambiguity.

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 alternatives (e.g., update_lead to change status, or whether a soft-delete/archive path exists). The irreversibility warning hints at caution but is not usage routing, and no prerequisites or preconditions are stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds the consequential effect ('stops receiving events'), which tells the agent what is actually disrupted, though it does not address reversibility or whether delivery history is retained.

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 and resource, with the purpose clause appended for value. 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 single-parameter delete with annotations covering destructiveness and idempotency, the description is nearly complete. The only residual gap is whether the deletion is permanent and what happens to already-queued events, which is minor given the annotation coverage.

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 id parameter is fully documented in the schema including its origin (from list_webhooks). The description only restates 'by ID', adding no syntax or constraint detail beyond the structured field, 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 (Deletes) and resource (registered webhook endpoint) with the selection key (by ID), and the purpose clause distinguishes it from list_webhooks and update_webhook 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?

Usage is implied by the name and the 'stops receiving events' rationale, but there is no explicit when-to-use/when-not guidance and no mention of the alternative update_webhook for disabling rather than removing a webhook.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description goes well beyond them by enumerating exactly what is destroyed (unsent follow-ups are canceled and do not return on re-attach), what is preserved (already-sent emails untouched), and what happens to a live campaign (rescheduled onto remaining senders). This is precisely the operational detail an agent cannot infer from the hints.

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

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

Front-loaded with the core action and consequence; the destructive side effects follow in a tight clause chain, and the idempotency note closes it out. No filler sentences.

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

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

For a two-parameter destructive mutation with no output schema, the description covers side effects, reversibility (do not come back on re-attach), and idempotency, which is everything an agent needs to call it safely.

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

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

Schema description coverage is 100% and both parameters (campaign id, senderEmailId) carry source pointers in the schema itself. The description adds no additional parameter-level meaning, 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?

Specific verb (detaches) plus resource (sender email from a campaign) with a clear outcome clause ('so the campaign stops sending through that mailbox'). The counterpart sibling attach_campaign_sender_emails is implied by 're-attach', making the direction of the operation unambiguous.

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

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

Usage context is implied by describing the effect of detaching, and the idempotent no-op clause tells the agent it is safe to call blindly. However, it never explicitly states when to choose this over the sibling attach_campaign_sender_emails or what an agent should do instead when it wants to swap mailboxes.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description reinforces this by stating 'without saving anything' and 'Free — searching never spends credits; only revealing contact details is metered.' This adds valuable behavioral context about credit usage and side-effect-free operation beyond 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?

The description is compact and front-loaded with the core purpose, then adds the credit/read-only context and usage guidance. The read-only key sentence is slightly tangential to the tool's core function but still useful for access decisions.

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 counting tool with no output schema, the description covers purpose, cost behavior, and usage context. It doesn't describe the return format (e.g., whether it returns a single number or a breakdown), but the tool's simplicity and the annotations reduce the need for that detail.

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 all six parameters with examples. The description adds the overall semantic that these are ad-hoc targeting criteria, but doesn't add per-parameter meaning beyond what the schema provides. 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 clearly states the tool counts matching prospects for ad-hoc targeting criteria without saving anything, distinguishing it from lead sourcing and ICP creation tools. It names the specific resource (audience size) and the verb (counts), making the purpose unmistakable.

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 explicitly says to use it to validate targeting before creating an ICP or sourcing leads, and clarifies when not to use it (not for revealing contact details). It also notes that a read-only key may call it, which is a clear access guideline.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds that it returns the full audit trail and that the budget plan is absent, which is useful behavioral context. However, it doesn't describe pagination, size, or other runtime traits; with annotations covering safety, a 3 is appropriate.

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 concise sentences with zero waste. It front-loads the core return value, then clarifies exclusions, then states the use case. Every sentence 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 tool with a single fully documented parameter and no output schema, the description is nearly complete: it covers the return (full audit trail) and an important omission (budget plan). It could mention return format nuances, but the annotations and schema cover the rest adequately.

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%, with the 'id' parameter fully documented as the numeric run ID from list_autopilot_runs. The description adds no additional parameter meaning beyond what the schema provides, 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?

Specific verb and resource: 'Returns one autopilot run including its full audit trail.' It also distinguishes the tool from siblings by explicitly scoping out the budget plan, which comes from start_autopilot_run and plan_autopilot. An agent can identify what this tool does and what it doesn't without opening the schema.

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

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

The description gives clear usage context: 'Use it to check progress.' It also distinguishes behavior from start_autopilot_run and plan_autopilot regarding the budget plan. However, it does not explicitly state when not to use it versus list_autopilot_runs or other status-related siblings like get_inbox_placement_run.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the 404-until-configured failure mode and the semantic purpose of the data (registrar filing vs CAN-SPAM footer). No return format/pagination detail, but not needed for a fixed-profile read.

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 return content and ending with the error precondition. Dense but every clause carries meaning; the em-dash gloss is slightly elaborate but informative rather than wasteful.

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

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

With no output schema, the description carries the burden of describing return values, and it does so by naming both data categories and their purpose. Combined with the failure-mode note, an agent has enough to call it correctly; only a precise field list/typing is absent.

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

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

Zero parameters, so the baseline is 4. The description correctly implies no input is needed by describing a fixed per-workspace lookup, adding nothing misleading about parameters.

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

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

Names a specific verb+resource ('Returns the registrant and postal contact details held for the workspace') and enumerates the returned fields, which distinguishes it clearly from the sibling set_billing_profile and from generic workspace lookups like get_workspace_details.

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 an explicit precondition — 'Errors with 404 until set_billing_profile has been called' — which routes the agent to the sibling setter before invoking this. It does not, however, state when to prefer this over other workspace-info tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious semantics: entries inherited from the account-wide list are visible from a sub-workspace and report scope "global", which an agent could not infer from schema or annotations.

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

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

Two sentences, front-loaded with the core purpose and return payload, then a scoping caveat. Minimal waste, though the clause structure of the first sentence is slightly dense.

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 compensates by naming the returned fields and the scope field's possible value, which is enough for a single-ID lookup tool. Error behavior for a nonexistent ID is the only notable 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?

Only one parameter exists and schema description coverage is 100%, and the schema already explains the ID's numeric nature and its source tool. The description adds no syntax or format detail beyond that, 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 (returns) and resource (one suppression/blocklist entry) scoped by ID, and enumerates the fields returned (blocked domain or email, added date, list). This clearly separates it from sibling list_blocklist_entries, which returns many entries.

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 schema notes the ID comes from list_blocklist_entries, which hints at the list-then-fetch workflow, but the description never says when to use this versus list_blocklist_entries or update_blocklist_entry, nor states preconditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral value by explaining the minimumHealth semantics and the allHeldBack/message signal for a stalled campaign, which is derivable behavior an agent could not otherwise predict.

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 retrieval statement, then uses the second sentence to explain the one non-obvious return field. It is dense but every clause earns its place given there is no output schema.

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

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

With no output schema, the description carries the burden of describing returns and does so for settings, schedule, stats, counts, and the minimumHealth block. It could still be more complete about naming the sibling stats/sequence tools, but for a single-param read it is largely sufficient.

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

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

Only one parameter (id), documented at 100% coverage in the schema, including its source (from list_campaigns). The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (retrieves) and resource (campaign by ID) and enumerates what is returned: settings, schedule, stats, per-status email counts, and minimumHealth details. An agent can distinguish this from get_campaign_stats or get_campaign_sequence without opening another 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?

No when-to-use guidance and no alternatives named, even though siblings like list_campaigns, get_campaign_stats, and get_campaign_sequence overlap. The description tells the agent what comes back but not when to pick this tool over those.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes further with domain semantics that structured fields do not carry: delayDays is relative to the previous step and the first step is always 0. It omits return format details beyond the basics, but with annotations doing the safety work this is a solid addition.

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

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

Two tight sentences with zero filler. The primary return description is front-loaded and the delayDays semantics follow immediately as supporting detail.

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 carry the return contract, and it does communicate the shape (ordered emails, A/B variants included) plus the delayDays convention. It leaves gaps around empty-sequence behavior and whether variant ordering is guaranteed, but it is sufficiently complete for a simple single-parameter read.

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

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

Only one parameter and schema description coverage is 100% -- the schema already documents id as 'The numeric campaign ID (from list_campaigns)'. The description adds nothing about the id parameter, so the baseline 3 applies; the schema is fully doing the work 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+resource ('Returns the ordered emails that make up a campaign's sequence') and clarifies scope with 'including any A/B variants,' which distinguishes it from get_campaign and replace_campaign_sequence. It stops short of naming those siblings explicitly, so an agent must infer the boundary from the resource noun alone.

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

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

Usage is implied by the read-only, inspection-oriented phrasing, but there is no explicit when-to-use statement, no mention of when to prefer get_campaign over this, and no note on prerequisites. The reference to a numeric campaign ID from list_campaigns hints at the retrieval flow without spelling out the 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful non-obvious context: the response is aggregated in one call, days are UTC, and the absent opens metric is a deliberate product limitation rather than a bug. It still says nothing about result size, pagination or permission requirements.

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

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

Three sentences, each doing work: first enumerates the return payload, second gives the use case, third preempts a likely confusion about the missing opens metric. Front-loaded and free of 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?

No output schema exists, so the description carries the return-value burden and does it well by listing every section of the response. Combined with annotations covering the read-only profile, an agent has everything needed to call this correctly with a single campaign ID.

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

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

Only one parameter, and schema description coverage is 100% — the schema already says it is the numeric campaign ID from list_campaigns. The description adds no syntax, format or edge-case guidance beyond that, 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 precise verb and resource and enumerates the exact payload: totals, per-A/B-variant results, per-sequence-step results and a daily UTC time series. This is far more specific than a generic 'get stats', though it never names a sibling (e.g. get_campaign vs get_outcomes_report) to explicitly draw the boundary.

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 use context: 'Use it to judge how a campaign is doing or to compare variants.' That tells the agent the intent, but there are no exclusions or named alternatives for when a different report tool would be the better choice.

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

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

The description adds significant behavioral detail beyond the readOnlyHint annotation: a new workspace sees zeros rather than an error, and the unlimited flag changes whether credit checks or purchases are necessary. These are exactly the edge cases that a caller needs to know and that are not present in the schema or 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?

The description is front-loaded with the return concept and fields, then adds pricing, the zero-state behavior, and the unlimited caveat. Every sentence earns its place, and none of the detail is redundant with the schema or annotations.

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 full explanatory burden. It covers what is returned, the credit consumption model, the new-workspace zero behavior, and the unlimited case, making the tool safely callable and interpretable.

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 no parameters and the input schema has no properties, so the baseline is 4. The description adds useful context about what credits are used for and pricing, but there are no parameter meanings to document.

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

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

The description states a specific verb and resource: 'Returns the workspace's credit wallet' and enumerates the exact fields returned (available, reserved, lifetime granted/used, monthly grant). It is immediately distinguishable from siblings like purchase_credits and list_credit_transactions because it is framed as a balance/status read, not a purchase or transaction history.

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 clear context about when checking or buying credits matters: credits pay for prospect reveals and AI work, and if unlimited is true there is 'no need to check the balance or buy credits.' It does not explicitly name alternative tools or list exclusions, but the usage context is strong enough to guide an agent.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it aggregates the inbox placement window together with the latest health check of every connected mailbox, and returns results ordered worst first with remediation actions attached.

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

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

Three sentences, front-loaded with the core question the tool answers, then the data it combines, then the usage trigger. No filler and nothing repeated from the schema or annotations.

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

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

For a read-only aggregate with one optional param and no output schema, the description covers the sources (placement window, auth records, blacklist listings, per-mailbox placement) and the output shape at a high level (ranked issues plus fixes). Precise return fields are not enumerated, but no critical calling information 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 optional parameter with 100% schema description coverage, so the schema already explains 'days' and its default. The description refers only obliquely to 'the window' without adding format or semantics beyond what the schema provides, matching the baseline for fully documented params.

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 diagnostic verb+resource: it surfaces what is wrong with deliverability across the workspace, ranked worst first, each item paired with a fixing action. It is clearly distinguishable from siblings like get_sender_reputation or get_inbox_placement_stats_by_date, which cover only one mailbox or one metric.

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 trigger: 'The best first call when asked why are we landing in spam,' which tells the agent to prefer this over narrower siblings. It stops short of naming those alternatives or stating when-not-to-use it, so it is strong context rather than 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 declare readOnlyHint=true and openWorldHint=false, so the safety bar is covered. The description adds value beyond annotations by disclosing return content (the full status enum, cost breakdown, failure reason) and noting it is meant for repeated polling, which matters since no output schema exists.

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 first front-loads what is returned, the second gives the usage trigger. The enum listing is dense but earns its place given the absence of an output schema.

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

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

With no output schema, the description carries the return-value burden and mostly does so, describing status values, cost breakdown, and failure reason. It omits pagination/format details, but for a single-record read tool it is largely complete.

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

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

Schema description coverage is 100% and the id parameter is already documented as coming from create_dfy_order or list_dfy_orders. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns one done-for-you order') and enumerates the returned fields (status enum, cost breakdown, failure reason). The word 'one' implicitly contrasts with the sibling list_dfy_orders, letting an agent distinguish single-fetch from list 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?

'Poll it to track provisioning after create_dfy_order' gives a clear when-to-use context and ties it to the sibling that produces the ID. It lacks an explicit when-not or comparison to list_dfy_orders, but the usage trigger 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?

Beyond readOnlyHint=true, the description discloses the monthly_limit_reached error semantics, what happens to remaining addresses, and that they are not billed. This is extra behavioral detail not present in 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?

Three sentences with no filler: returns/payload, polling instruction, and a critical edge-case explanation. The most important content is front-loaded and every sentence 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?

Despite no output schema, the description covers what the response contains, how to use it (poll), and a non-obvious error case. For a one-parameter read 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 100% and jobId is already documented as 'The job ID'; the description adds no new parameter-level detail. The baseline of 3 is appropriate since the schema carries the parameter meaning.

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

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

Description begins 'Returns one verification job' with a specific verb and resource, and immediately enumerates the payload (state, per-verdict counts, billed). The singular 'one' distinguishes it from list_email_verification_jobs and from the cancel/create siblings.

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

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

The instruction 'Poll until state is done' tells the agent when to use the tool and how. It does not explicitly name alternatives such as list_email_verification_jobs, but the usage context is clear enough.

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 annotations readOnlyHint=true, the description reveals the multi-provider waterfall, the credit-counting rule (one vs two credits), and which billing fields to trust for budgeting. No contradiction with annotations; it adds substantial behavioral 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?

Three sentences, front-loaded with the core result, then usage timing, then the pricing rule. Every sentence adds necessary information; there is no filler.

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

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

Even with no output schema, the description explains the return substance (perAddressCeilingUsd vs perAddressFloorUsd) and the billing-credit model, and there are no input arguments to document. An agent has everything it needs to invoke the call and interpret the result.

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 zero parameters, so the parameter-semantics burden is minimal and the baseline is 4. The description correctly focuses on output semantics rather than input details, which are absent.

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

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

The description opens with a specific verb and object ('Returns what one email verification costs right now') and grounds it in the actual billing plan the meter charges against. It clearly distinguishes this rate-lookup tool from the create_email_verification_job sibling by positioning itself as the pre-budget call.

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 directs the agent to call this before create_email_verification_job rather than assuming a price, and gives concrete budgeting guidance (treat perAddressCeilingUsd as the common case, not perAddressFloorUsd). That is clear when-to-use context with an alternative named.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description adds real value by enumerating what the returned record contains: targeting criteria, AI/human-edited flag, primary status and audience size. That partially compensates for the absent 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?

One well-formed sentence, front-loaded with the action and the identifier. It is efficient, though the trailing enumeration of returned fields makes it slightly dense.

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-resource read with no output schema, the description supplies the key returned fields and the annotations carry the read-only safety profile. Only the routing decision against get_primary_icp/list_icps is left unaddressed.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented as 'The numeric ICP ID (from list_icps)'. The description's 'by ID' phrasing adds nothing beyond that, 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 ('Retrieves') and resource ('one Ideal Customer Profile'), and the 'by ID' scope cleanly separates it from the plural list_icps. It does not name or differentiate against get_primary_icp, which is the closest sibling and a plausible source of confusion.

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

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

There is no statement of when to use this tool versus list_icps, get_primary_icp, or get_audience_size. The only hint is the schema note that the ID comes 'from list_icps', so usage must be inferred entirely.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the description does not need to cover safety. It adds valuable domain-specific behavioral context: what 'Promotions' and 'Missing' mean, the implication of a silent block, and the spamScore unit convention. This goes beyond structured fields significantly.

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 what is returned and its components. Every sentence adds distinct value: first sentence lists report sections, subsequent sentences define key terms and units. No redundancy or filler.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so thoroughly for the main report sections. However, it could be more complete by mentioning pagination or limits, though for a single-run retrieval those are likely not applicable. The tool is complex and the description provides substantial context.

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 the single 'id' parameter fully. The description does not add parameter syntax or format details, which is acceptable given the high coverage. 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 (Returns), resource (one inbox placement run), and the full report content. Clearly distinguishes from siblings like list_inbox_placement_runs by specifying singular run retrieval, and no sibling tool retrieves a single run with this detailed report.

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?

Implies usage by mentioning 'from list_inbox_placement_runs' but doesn't explicitly state when to use this vs list_inbox_placement_run_results or list_inbox_placement_tests. The context of retrieving a single run is clear from the description, but no direct alternatives or exclusions are provided.

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 and closed-world, but the description adds a genuinely non-obvious behavioral trait: the series is sparse, and days with no runs are absent rather than zero. The explicit warning never to read a missing day as 0% placement is exactly the kind of semantics annotations cannot 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?

Three tight sentences, front-loaded with the core operation and its default, then the crucial sparse-series caveat. No filler; every sentence carries load.

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

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

With no output schema, the description carries the return-value burden and does so by describing the shape of the series and its absence behavior. An agent can both call it correctly and interpret the result without guessing.

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 both parameters (from/to) are already documented with RFC3339 format and defaults. The description restates the 30-day default and adds the UTC-day bucketing concept, but adds little else beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb (rolls up), resource (completed inbox placement runs), aggregation dimension (UTC calendar day), and purpose (trend). This cleanly separates it from the raw-run siblings like list_inbox_placement_runs and get_inbox_placement_run, which return individual runs rather than an aggregated series.

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

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

Gives clear context (use it for a trend) and states the window default of the last 30 days. It does not name an alternative tool or give explicit when-not-to-use conditions, but the trend framing makes the intended use 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful non-annotated detail that the response includes contact and company data, which matters because there is no output schema, but it says nothing about error behavior for missing IDs or permissions.

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

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

One tightly written sentence with the resource and return contents front-loaded and zero filler. It is appropriately sized for a single-parameter read, though it is arguably too terse to carry any routing information.

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

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

For a simple read-by-ID tool with complete schema coverage and readOnly annotations, the description supplies the one missing piece – what the call returns – even without an output schema. Nothing essential to invoking it correctly is absent, though sibling routing would make it airtight.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema, including the note that the ID is returned at creation. The description only echoes 'by ID' and adds no format, range, or sourcing detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Retrieves a lead by ID') and even summarizes the payload (contact details, company information), so an agent immediately knows what it fetches. It does not, however, explicitly distinguish itself from siblings like list_leads or get_lead_conversation, leaving that differentiation 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?

There is no guidance on when to use this tool versus the many sibling read tools (list_leads, get_lead_conversation, get_icp). The 'by ID' phrasing weakly implies single-record lookup, but no exclusions or alternatives are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: chronological ordering, inclusion of unsent/scheduled drafts, and the isDraft marker flagging AI drafts awaiting review, plus who can send them.

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 return contents and efficiently packs direction, status, and draft behavior into three sentences. The closing sentence about editing/sending drafts is adjacent routing information rather than core to what this tool returns, a minor bit of scope bleed.

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 return values and does so thoroughly (thread ordering, direction, status, isDraft marker). An agent has everything needed to call and interpret this read-only tool.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema as the numeric lead ID returned at creation. The description adds no syntax or format detail beyond that, 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?

The description states a specific verb and resource ('Returns a lead's full email thread') and details the exact composition of the result: outbound sent/scheduled/unsent drafts plus inbound replies with direction and status. This clearly separates it from siblings like get_lead (lead record) and list_replies (cross-lead reply list).

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

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

It gives a clear use condition ('read the back-and-forth with one lead before deciding what to do next') and routes follow-up actions to update_reply_draft and send_reply_draft. It lacks explicit when-not-to-use guidance or a direct comparison against get_lead or list_replies, so it stops short of a full 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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful context: the call is free, makes no call to the data provider, and exposes workspace-specific quotas and remaining daily allowance. This is valuable behavioral/useful context that annotations alone do not convey.

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

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

The description is dense but well organized: the filter list is parenthesized and the limits are grouped in a single clause. It is long, but every item names a distinct output category and there is no filler.

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

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

For a no-input metadata endpoint, the description covers all returned content: accepted filter values, applicable limits, and credit cost per prospect. It also states free/no-data-provider-call behavior, so an agent has what it needs to use 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?

The tool has zero parameters and an empty input schema, so the description carries no parameter-documentation burden. Baseline 4 is appropriate; no parameter semantics are needed.

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 clear verb ('Returns') and specific resource (Lead Finder filter values and workspace limits), enumerating all filter categories and limit types. It is immediately distinguishable from sibling tools like search_lead_finder and get_lead_finder_search because it targets filter metadata, not search results or searches.

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 instructs the agent to call it before search_lead_finder so filter values match exactly. It doesn't enumerate when not to use related Lead Finder getters, but the precondition is unambiguous and clearly signals the intended workflow.

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

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

Annotations only mark the tool read-only; the description adds non-obvious behavior: fields can change until finishedAt, a failed add may still have added and charged people, and endReason/lastError values are enumerated. There is no contradiction with readOnlyHint=true.

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?

Five dense sentences, front-loaded with the return contract before caveats and alternatives. The status and error enums are inline rather than padded, and the final strategic note about search_lead_finder earns its place as usage 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?

With no output schema, the description carries the burden of explaining return semantics and does so thoroughly: statuses, completion reasons, failure reasons, credits, and the polling caveat are all specified. Minor omissions like exact skipReasons values are not needed 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?

The single id parameter is fully documented in the schema ('importId from add_lead_finder_prospects or list_lead_finder_imports'), so the description does not need to repeat it. It adds no syntax or formatting details beyond the schema, so the baseline for full schema coverage applies.

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

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

The first sentence names the exact resource ('one Lead Finder add's progress') and lists the specific fields returned: status, added, skipped, skipReasons, email verification, and creditsSpent. This clearly distinguishes it from siblings like get_lead_finder_search and list_lead_finder_imports.

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 instructs the agent to poll this tool after add_lead_finder_prospects until finishedAt is set, and provides a conditional alternative: after a large add, use search_lead_finder to pick missing people. This is concrete when-to-use and when-not-to-use guidance.

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

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

Adds substantial behavior beyond the readOnlyHint annotation: the ~6-second wait, page re-read window, cache nuance, ref validity extension, failed/expired status, and the 15-minute disappearance. No annotation contradiction exists; the description enriches what the agent needs to know about side effects and lifecycle.

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 dense and front-loaded with its core action, and nearly every clause contributes needed behavioral detail. It is somewhat long and could be organized into bullets, but no sentence 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 single-parameter read tool with no output schema, the description covers the whole call-and-refresh cycle: when to retry, what windows apply, what error to expect, and what to do after expiry. Nothing required to call it correctly is missing.

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

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

The schema already documents searchId at 100% coverage, so the description only adds provenance by tying it to search_lead_finder. This is mildly useful but does not meaningfully expand parameter understanding 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: 'Reads a search started with search_lead_finder, by its searchId.' This clearly distinguishes it from the sibling search_lead_finder and other get_lead_finder_* tools, and the title reinforces the read 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?

Gives explicit lifecycle guidance: calling again while the search is still running is fine, re-reading within 10 minutes extends ref validity, and after 15 minutes the search is not found. It also points to running search_lead_finder again as the refresh path, which effectively covers both when to use this tool and how to recover after expiry.

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 readOnlyHint annotation, the description discloses non-obvious calculation behavior: spend is valued at a fixed list price, subscription fees are excluded, and campaignId narrows only the outcome side while spend remains workspace-level. This is exactly the kind of behavioral context an agent needs and could not infer from the schema 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?

Three dense sentences carry all the essential information with no filler. Metric groups, exclusions, the campaignId caveat, and the intended use case are each given their due, and the most important scoping context is front-loaded.

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 reporting tool without an output schema, this description covers the metric families, pricing basis, exclusions, and attribution semantics. It could go slightly further by stating default time-window behavior and return shape, but the provided information is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already defines all three parameters. The description adds useful context about campaignId's partial-attribution caveat, but it mostly reinforces what the schema already states about spend remaining workspace-level rather than introducing substantial new parameter meaning.

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

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

The description opens with a specific operation—mapping money spent to results for a time window—and enumerates the exact metric groups included. The closing 'Use it to answer what did we spend and what did we get' makes the tool's purpose unmistakable and clearly separates it from campaign-stat or credit-balance tools.

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

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

It provides a clear when-to-use signal and includes important exclusions: subscription fees are not included, and campaignId produces partial attribution rather than a true campaign cost. However, it does not explicitly name sibling alternatives or say when NOT to use this tool, so it stops just short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the 'at most one primary' invariant and the explicit 404 error when none is set, which is not derivable from 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 sentence, front-loaded with the return value, with the invariant and error behavior appended. 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, the description identifies the returned entity but does not describe the ICP's shape or fields. For a no-param read tool whose safety profile is already in annotations, this is nearly complete, with only minimal detail on the returned object missing.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description appropriately spends no words on parameters.

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

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

States a specific verb (Returns) and resource (the workspace's active/primary ICP), and the parenthetical clarifies the entity's semantics. It is cleanly distinguishable from siblings like get_icp and list_icps by the 'primary/active' qualifier.

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

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

It gives clear context for when the tool applies (you want the single active profile, not an arbitrary one) and states the boundary condition that at most one exists. It stops short of naming the alternatives (get_icp, list_icps, set_primary_icp) that an agent should choose between.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the healthScore range (0-100), its definition (share of warm-up emails landing in inbox over the last 7 full days), that it moves daily, and that it returns null when warm-up is off or before 20 emails are checked. It does not describe error behavior for invalid IDs, but the added semantics are 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-loads the purpose in the first clause, then spends the remainder on the one piece of non-obvious semantics (healthScore). Every sentence earns its place, though the healthScore explanation is dense and runs long for a single-parameter lookup.

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 compensates by explaining the most important returned field, healthScore, including its null conditions. Annotations cover the read-only profile and there is only one fully documented parameter. Only error handling and any other returned fields remain unaddressed.

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

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

Schema coverage is 100% and the single parameter is already documented as 'The numeric sender email ID (from list_sender_emails)' with a minimum bound. The description only restates 'by ID', adding nothing the schema doesn't already carry. Baseline 3 applies when the schema does all 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?

States a specific verb+resource with scope: 'Retrieves a connected sending email account by ID, including its health score.' The 'by ID' qualifier implicitly separates it from list_sender_emails, though it never names that sibling. An agent can identify what it does 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?

No when-to-use guidance, no exclusions, no named alternatives. The description never mentions that list_sender_emails is the bulk counterpart, nor how this differs from get_sender_email_warmup or get_sender_reputation, which are the obvious near-neighbors for sender-account data.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds meaningful behavior beyond them: live DNS lookups at request time, a few-second latency, guarantee of no stale records, the OK/WARNING/MISSING/ERROR status vocabulary, and how healthScore is computed (7-day inbox share). This is rich context an agent cannot get from structured fields.

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 what is checked before the usage hint and latency note. Dense but every clause carries information; the healthScore parenthetical is slightly long but justified since no output schema exists.

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 fully compensates by explaining the returned record statuses, human-readable issues, and warm-up fields (enrollment, ramp target, daily cap, healthScore). An agent has everything needed to call and interpret the result.

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

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

Schema description coverage is 100% and the single id parameter is documented with its source (list_sender_emails). The description adds no parameter-level detail, so baseline 3 is appropriate when the schema fully carries that burden.

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 (checks) and specific resources (SPF, DKIM, DMARC, MX records plus warm-up status) for the sender domain. It clearly distinguishes itself from siblings like get_sender_email_warmup and get_sender_reputation by enumerating exactly which signals it returns.

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 use case ('Use it to diagnose deliverability'), which orients the agent. However, it never names when NOT to use it or routes to alternatives such as get_deliverability_insights or get_sender_email_warmup, so selection among similar siblings still requires inference.

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

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

With only readOnlyHint/openWorldHint from annotations, the description carries the burden and delivers: it explains the healthScore formula and scale, the null conditions (off, or fewer than 20 checked), what currentPerDay represents, and that when configured is false the values are defaults. This is substantial disclosure well beyond 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?

Front-loaded with the verb and resource, and every clause carries real information (ramp semantics, healthScore definition, defaults). It is a dense run-on sentence but not padded; slightly heavy for a single-parameter read.

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, and the description fully compensates by describing the return shape and the meaning/edge cases of each field. An agent can interpret the response correctly without any additional context.

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 there is a single 'id' parameter already documented (from list_sender_emails). The description adds no further meaning to the parameter, 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 (Reads) and resource (a mailbox's warm-up settings) and enumerates the exact fields returned (ramp, weekly limits, timezone, currentPerDay, healthScore). It even distinguishes itself from the mutation siblings by noting warm-up volume is separate from campaign sending limits changed with update_sender_email.

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

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

Usage is implied rather than stated: the agent can infer this is the read counterpart to update_sender_email_warmup, and the note about update_sender_email clarifies a boundary. But there is no explicit when-to-use guidance versus the other get_sender_email*, get_sender_reputation, or get_deliverability_insights siblings.

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

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

Annotations already cover read-only and closed-world safety. The description goes further with two high-value semantics the agent cannot get elsewhere: blacklistsChecked vs blacklistsListed to avoid misreading counts as totals, and -1 meaning not measured rather than zero. That's genuinely useful, though it omits freshness/rate-limit details.

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

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

Front-loaded with the verb and the exact fields returned, then the two semantic caveats. Efficient, though the long field enumeration makes it a bit dense; a bulleted structure would scan better.

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

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

No output schema exists, so the description carries the return-value burden and largely does it: it enumerates the status fields and explains the two ambiguous value conventions. It could still say what a mailbox-scoped result looks like and what 'recent runs' means in terms of time window.

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?

Zero parameters, so the baseline is 4. The description correctly adds no parameter content, and instead spends its words on output semantics.

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 (returns) and resource (latest health check for every connected mailbox) with concrete scope: SPF, DKIM, DMARC, MX, blacklists, placement, health score. Distinguishable from siblings like get_sender_email_dns and get_inbox_placement_run, which cover subsets.

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?

Implied usage: it's the aggregate health-check tool, so an agent would pick it when needing a full mailbox reputation snapshot. But it never says when to prefer this over get_sender_email_dns or get_inbox_placement_run, nor whether it must be called before certain mutations. Context is implied, not 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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the concrete return shape (counts by status, members), but says nothing about auth requirements, rate limits, or whether the member list is paginated.

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 with no filler; the return contents come first and the usage hint second, which is the right front-loading for a zero-argument tool.

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

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

With no output schema, the description carries the return-value burden and does list the payload contents. It stops short of noting whether the member list can be large or how counts are grouped, which a caller might want to know.

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?

Zero parameters, so the schema provides nothing to interpret and the baseline is 4. The description correctly implies the tool is parameterless by scoping it to 'the workspace behind the API key'.

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 (returns) and resource (the workspace behind the API key), and enumerates the payload: campaign counts by status and member list. Implicitly distinguished from the sibling list_workspaces because it takes no scoping arguments and operates on the caller's own key.

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 frames the tool as 'useful as a first call to confirm which workspace a key belongs to', giving a clear use context. It does not name list_workspaces as the alternative when enumerating multiple workspaces, so the routing guidance is incomplete but substantive.

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 cover the safety profile (openWorldHint, non-idempotent, non-destructive), and the description adds materially new behavior: imported campaigns land as DRAFTS, nothing sends until manually launched, and the call is asynchronous returning a job id. It does not call out duplicate-import risk on re-invocation, which the non-idempotent hint implies.

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

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

Three sentences, front-loaded with the core action, then the safety-relevant draft behavior, then the async return. 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 import tool with no output schema, the description covers purpose, prerequisite credential, side effects (drafts only), and execution model (background job with id). Everything an agent needs to call and interpret the result 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 100% and the single parameter (instantlyApiKey) already documents where to find the key, matching the description's mention. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Imports) and resources (Instantly.ai campaigns and leads) with the destination system (Emailchaser) named. This clearly distinguishes it from read-oriented siblings like list_instantly_accounts.

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

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

Gives clear context for when to invoke it (bringing Instantly data into Emailchaser, requiring an API key) and sets expectations about the draft-review workflow. It does not name alternatives or say when not to use it, so it falls short of a 5.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds crucial context beyond them: the action is irreversible ('can NEVER be resumed') and it has a cascading side effect (launched campaigns are paused so nothing more sends), plus that the reason lands in the audit trail.

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

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

Two tight sentences, front-loaded with the irreversible halt and the campaign side effect, then the alternative. Efficient, though wording is slightly colloquial rather than purely informational.

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

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

For a two-parameter destructive tool with no output schema, the description covers irreversibility, side effects, and the routing alternative – everything an agent needs to call it safely and 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% – both 'id' and 'reason' are documented in the schema. The description repeats the audit-trail purpose of 'reason' but adds no syntax, format, or ID-sourcing detail beyond what the schema and list_autopilot_runs reference already provide.

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

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

States a specific action (killing an autopilot run) with vivid scope: 'the run halts wherever it is and can NEVER be resumed.' It is clearly distinguishable from the sibling pause/resume/start autopilot 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?

Explicitly names the alternative ('Use pause_autopilot_run instead when you might want to continue later'), giving a concrete condition that selects between the two tools. 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 declare openWorldHint=false and destructiveHint=false, so the safety profile is partially covered. The description adds meaningful behavioral context: validation occurs before launching and emails start sending per the campaign schedule. However, it does not disclose what happens on validation failure, required permissions, or side effects like sending emails to leads.

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

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

Two sentences, front-loaded with the action, no filler. Efficient and clear, though it could be tightened by combining the validation and sending behavior into fewer words.

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 tool with no output schema and basic annotations, the description covers the core action and validation behavior. It does not explain return values (none expected), but that is acceptable. Some gaps remain around failure handling and idempotency.

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

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

Schema coverage is 100%, and the description provides no parameter syntax or format beyond the schema. The description does mention the campaign configuration, but there is no additional parameter detail. Baseline 3 is appropriate when the schema already documents the single 'id' parameter.

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

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

States a specific verb and resource ('Launches a new campaign or resumes a paused one') with a clear dual behavior. It is distinguishable from pause_campaign, resume_autopilot_run, and copilot_launch, but does not explicitly name or differentiate against neighboring sibling tools like pause_campaign or copilot_launch.

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

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

The description implies when to use it (to launch or resume), but does not state preconditions or alternatives. It does not explain when to use launch_campaign vs resume behavior vs paused-campaign handling, or how it relates to pause_campaign.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds the ordering guarantee ('newest first') and the status taxonomy, which is useful behavioral context, but says nothing about pagination totals, default page size behavior, or empty-result handling.

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

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

One sentence, front-loaded with the core action, and the parenthetical status list is dense but informative. The inline enumeration of nine statuses is a little heavy but each item carries meaning for interpreting results.

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

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

With no output schema, the description carries the return-value burden and does so well, naming ordering, status field, and linked ICP/campaign IDs. It omits pagination metadata (total counts, has-more) that an agent listing paginated results would benefit from.

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?

Both parameters (page, limit) have 100% schema description coverage, including defaults and max. The description adds no parameter-level detail, which is acceptable at this coverage level but earns only the baseline score.

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 ('Lists the workspace's autopilot runs'), adds ordering ('newest first') and enumerates the returned status lifecycle and linked IDs. It is clearly the collection-level counterpart to get_autopilot_run among the listed 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 implied by the shape of the tool (browse all runs in the workspace), but there is no explicit guidance on when to prefer this over get_autopilot_run for a single run, nor on how paging interacts with filtering. No alternatives or exclusions are named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine domain context beyond that: blocked entries are never emailed by any campaign, the default spans workspace plus account-wide lists, and each entry reports its source list. It omits pagination/return-shape detail, but that is minor given 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?

Three sentences, front-loaded with the return semantics, then the default scope, then the per-entry provenance field. Every sentence earns its place with no repetition.

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

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

A read-only list tool with no output schema and fully documented parameters; the description conveys the domain meaning of the data and default scope. Minor gap: it does not hint at result ordering/paging interaction with limit/offset, though the schema covers those parameters.

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 limit, scope, offset, and search, including defaults and enum meanings. The description restates the default scope behavior but adds no syntax or format detail beyond the schema, matching the baseline of 3.

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

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

States a specific verb and resource ('returns the suppression entries... blocked domains and email addresses') plus scope and ordering ('newest first'). An agent can distinguish this list tool from the singular get_blocklist_entry sibling 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?

Usage is implied rather than stated: the description explains the default scope ('spans both lists') but never says when to call this instead of get_blocklist_entry or get_blocklist_entry's filtered variants. No explicit when-not guidance is provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by saying what comes back (status plus sent/replies/bounce stats) and that pagination/filtering are supported, 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 tight sentences, front-loaded with the primary action and followed by the payload/supporting capabilities. No filler or restated title boilerplate.

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, describing the returned fields (status, sent, replies, bounces) is exactly the missing piece, and it is provided. Minor gaps remain around default sort order and what an empty workspace returns, but the definition is broadly sufficient for a read-only list tool.

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

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

Schema description coverage is 100%, so each of the four parameters (page, limit, status, folderId) is already documented in the schema. The description only echoes the filtering and pagination capability without adding format or default details, so the baseline 3 applies.

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

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

States a specific verb and resource ('Lists cold email campaigns in the workspace') and summarizes the returned payload. It distinguishes itself implicitly from get_campaign/get_campaign_stats via the 'Lists' scope, though it never names a sibling explicitly to draw the boundary.

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?

Mentions the supported capabilities (pagination, filtering by status or folder), which implies when to use it, but gives no explicit when-to-use vs when-not, no guidance on choosing list_campaigns over get_campaign or get_campaign_stats, and no 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?

The description adds significant behavioral context beyond the readOnlyHint annotation: entries are ordered 'newest first', each entry includes the balance after it, and the semantics of the 'free' flag are explained (amount reflects hypothetical cost, no credits moved). It also notes that filters exist. This fully discloses the tool's behavior without contradicting 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?

The description is four sentences, each adding value: the core purpose, filtering capability, a specific use case, and a nuanced output detail (free flag). It is front-loaded with the primary action and avoids fluff. No wasted words.

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 list tool with six optional parameters and no output schema, the description covers purpose, ordering, filtering, and a special field semantics. It doesn't explicitly mention pagination (though page/limit are in the schema) or the return format, but these are standard for list tools. The description is comprehensive enough for an agent to invoke it correctly.

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

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

The schema provides 100% coverage for all six parameters, so the description doesn't need to explain them. It does mention filtering by 'movement kind, reason or a time window', which maps to parameters, but adds no detail beyond what the schema already provides. 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 clearly states the verb 'Lists', the resource 'credit ledger', and specifies the contents (grants, spends, reservations, refunds with balance). It also differentiates from get_credit_balance by emphasizing the ledger history. This is precise and distinguishes it from sibling tools.

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

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

The description gives explicit use cases: 'see where credits went' and 'check for a stripe_topup entry after an unconfirmed purchase_credits call'. While it doesn't explicitly name alternatives, it implies the tool is for detailed history rather than a balance snapshot, and it mentions filtering to narrow down. This provides clear context but lacks an explicit 'instead of X' comparison.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a useful data-scope guarantee ('Internal billing and provider records are never exposed'), which is real value beyond the annotations, but says nothing about pagination behavior or result volume for a paged list tool.

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

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

A single tight sentence with no waste; scope, ordering, and payload are front-loaded and the data-exclusion caveat follows naturally.

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 listing tool with no output schema and fully documented parameters, the description covers what is returned and what is deliberately withheld. Only the pagination/traversal behavior is left unaddressed, which is a minor gap given the schema documents page and limit.

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% — page and limit are both documented with defaults and bounds in the schema. The description adds no syntax, default, or constraint detail beyond it, 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 and resource ('Lists the workspace's done-for-you orders') plus ordering and returned contents (status, cost breakdown, domains, mailboxes). The plural scope implicitly separates it from get_dfy_order, but no sibling or alternative is named explicitly, so it stops short of a 5.

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

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

No when-to-use context, no prerequisites, and no routing to alternatives such as get_dfy_order for a single order or search_dfy_domains for domain lookup. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable context about what the tool returns: live counts and billing data (meterEvents and spentUsd), which goes beyond annotations. No contradictions.

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, efficient sentence that front-loads the action and resource, then provides key details. No filler words.

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 listing operation with all optional parameters documented in the schema, the description provides sufficient detail about output content (live counts, billing fields) and ordering. No missing information that an agent would need 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 the schema fully documents page, size, and search. The description adds no additional parameter context, 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?

The description clearly states the action (lists), the resource (workspace's standalone email verification jobs), and adds distinguishing details like newest-first ordering, live counts, and billing information. This differentiates it from singular get_email_verification_job and results-oriented list_email_verification_results.

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

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

The description implies usage context by noting 'standalone' jobs, but does not explicitly state when to use this over alternatives like get_email_verification_job or list_email_verification_results. No exclusions or alternative routing are provided.

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, so the description doesn't need to repeat that. It adds valuable behavioral context: explains the meaning of each verdict, notes that 'unknown' is not billed, and mentions that rows include provider statements and credit costs. This goes beyond the structured data, providing insight into the response content. No contradiction with annotations.

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

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

Two sentences with no fluff. The first sentence states the core output and defines verdicts; the second explains the filter. All information is pertinent, and the most important details are front-loaded. Efficient and structured.

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

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

For a list tool with no output schema, the description covers what the response contains (one row per address, verdict, provider statements, credit cost) and how to filter. Pagination is standard and self-explanatory via schema. It also clarifies the 'deliverable' filter's meaning, which is crucial for correct usage. No significant gaps for an agent to call it correctly.

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

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

Schema description coverage is 100%, so all parameters are documented. The description adds semantic depth for the 'result' parameter by explaining what each enum value means and defining 'deliverable' as a combination. It also hints at the output rows carrying provider details and credit costs, which indirectly informs the 'page' and 'size' usage. The added meaning elevates it above the baseline 3.

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

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

The description states a specific verb ('Returns one row per address') and clearly identifies the resource (email verification results). It enumerates the verdict values and explains the 'deliverable' filter, distinguishing it from sibling tools like list_email_verification_jobs (lists jobs) and get_email_verification_job (single job). The purpose is unambiguous and actionable.

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 use the 'result' filter, clarifying that 'deliverable' means valid plus catch-all, which is what campaigns send to. This guides the agent on when to use this filter. However, it does not explicitly state when to choose this tool over alternatives (e.g., get_email_verification_job for aggregate stats), though the sibling names imply it. Slight gap in exclusions, but the core usage is clear.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: sorting order ('newest first') and the content of returned records (targeting criteria, AI vs human-edited, audience size). It doesn't mention pagination limits, but the schema covers those.

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, well-structured sentence that front-loads the core action and efficiently lists the key returned attributes without any wasted words.

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 list tool with no output schema, the description adequately conveys what the tool returns (ICPs with targeting criteria, generation type, audience size) and implies pagination via parameters. It could mention default/max limits, but those are in the schema, so this is largely sufficient.

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

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

Schema description coverage is 100%, with both page and limit fully documented in the input schema. The description adds no parameter meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

States a specific verb (Lists) and resource (workspace's stored ICPs), and clarifies the scope and sorting ('newest first') plus the returned fields. Clearly distinguishable from siblings like get_icp, create_icp, delete_icp, and update_icp.

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

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

The description implies it's a list/read operation for multiple ICPs, but doesn't explicitly state when to use this versus get_icp (single) or get_primary_icp (default). No exclusions or alternatives named, leaving usage context partially inferred.

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