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

Annotations indicate 'destructiveHint: false', and the description adds valuable behavioral context not covered by annotations: it specifies prerequisites (sender accounts, leads, sequences, schedule) and references a verification tool. This enhances understanding of the tool's operational requirements beyond the non-destructive hint.

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 well-structured and concise, using bullet points for prerequisites and a clear follow-up sentence. Every sentence adds value without redundancy, making it easy to scan and understand quickly.

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 tool's complexity (activating a campaign with prerequisites), the description is complete: it covers purpose, usage guidelines, and behavioral context. With annotations providing safety info and an output schema existing (though not shown), no additional details are needed for effective use.

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 has 0% description coverage, but the description compensates by implicitly clarifying the 'campaign_id' parameter through context (e.g., referencing prerequisites and 'get_campaign'). It doesn't fully detail parameter semantics like format examples, but adds meaningful context beyond the bare schema.

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

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

The description clearly states the tool's purpose with the verb 'Activate' and resource 'campaign', specifying it's to 'start sending'. However, it doesn't explicitly differentiate from sibling tools like 'pause_campaign' or 'update_campaign' beyond the activation action, which keeps it from a perfect score.

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 explicit usage guidelines by listing four required prerequisites and recommending 'get_campaign' to verify them before use. This clearly indicates when to use this tool (after setup) and references an alternative tool for verification.

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 valuable behavioral context beyond the destructiveHint=false annotation. It specifies performance characteristics ('10-100x faster'), duplicate prevention logic ('skip_if_in_campaign=true'), and constraints like the 1,000 lead limit and email requirement. However, it doesn't mention rate limits, authentication needs, or error handling, which would be useful for a bulk operation 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?

The description is highly concise and well-structured: four sentences that each add critical information without waste. It front-loads the core purpose, then provides constraints, requirements, and recommendations in a logical flow. Every sentence earns its place by addressing distinct aspects of tool usage.

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 tool's complexity (bulk operation with many parameters) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, performance, key constraints, and recommendations. However, with 0% schema coverage and no annotations beyond destructiveHint, it could better explain parameter interactions or error cases for a robust bulk import 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?

With 0% schema description coverage, the description compensates well by explaining key parameter semantics: it clarifies the exclusive choice between campaign_id and list_id, notes the email requirement for leads, mentions custom variables must match campaign fields, and recommends skip_if_in_campaign. However, it doesn't cover all parameters like blocklist_id or verify_leads_on_import, leaving some 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?

The description clearly states the tool's purpose: 'Bulk add up to 1,000 leads' with the specific verb 'add' and resource 'leads', distinguishing it from sibling tools like create_lead (single lead creation) and move_leads_to_campaign_or_list (relocation rather than addition). The bulk nature and performance comparison further clarify its unique role.

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 explicit guidance on when to use this tool: '10-100x faster than create_lead' for large imports, and when not to use it: 'Provide EITHER campaign_id OR list_id (not both)'. It also distinguishes from create_lead by naming it as an alternative for bulk operations, though it doesn't explicitly mention other siblings like move_leads_to_campaign_or_list.

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

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

Annotations provide 'destructiveHint: false', indicating it's not destructive. The description adds context about required credentials and provider codes, which helps understand behavioral needs beyond annotations. However, it doesn't mention rate limits, authentication requirements beyond credentials, or what happens on success/failure, leaving some behavioral aspects unclear.

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 appropriately sized with two clear sections: purpose statement and provider codes, followed by credential requirements. It's front-loaded with the main action. Minor improvement could be integrating the credential note more seamlessly, but overall it's efficient with zero wasted 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?

Given the tool's complexity (12 parameters, creation operation) and the presence of an output schema (which handles return values), the description provides good context: purpose, provider mapping, and credential requirements. It covers key aspects needed for invocation, though additional details on error cases or side effects would enhance completeness.

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

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

Schema description coverage is 0%, so the description carries full burden. It explains provider codes (1-4 mapping to services) and emphasizes credential requirements, adding meaningful context beyond the bare parameter names in the schema. However, it doesn't detail all 12 parameters individually, leaving some semantics implicit.

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 specific action ('Create email account') and the resources involved ('with IMAP/SMTP credentials'), distinguishing it from sibling tools like 'update_account' or 'delete_account'. It precisely communicates what the tool does beyond just restating the 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?

The description implies usage context by mentioning 'Requires valid IMAP and SMTP credentials for email sending', which suggests prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'update_account' or 'manage_account_state', nor does it provide exclusion criteria or direct comparisons to sibling 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 only provide destructiveHint=false. The description adds significant behavioral context: the two-step workflow, personalization variables, API v2 structure requirements (type='email', variants array, delay in days, HTML formatting), and multi-step sequence capability. 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?

Well-structured with clear sections (two-step process, personalization, sequence usage, API structure). Slightly verbose but each sentence adds value. Could be more front-loaded by moving API v2 details later, but overall efficient.

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

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

Given the complex 18-parameter tool with 0% schema description coverage and an output schema, the description is highly complete. It covers workflow, parameter semantics, personalization, sequence usage, and API constraints, providing all necessary context for effective use.

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

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

Schema description coverage is 0%, so the description carries full burden. It explains the two-step parameter usage (name/subject/body first, email_list second), personalization variables, and API v2 structure for parameters like variants array and delay units, adding crucial meaning beyond the bare schema.

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

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

The description clearly states the tool creates an email campaign with a specific two-step process. It distinguishes from siblings like 'activate_campaign' or 'update_campaign' by focusing on initial creation with sender discovery and assignment.

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 describes when to use: two-step process (first call with name/subject/body, second with email_list). Also mentions using 'sequence_steps for multi-step follow-up sequences' and provides API v2 structure requirements, giving clear operational context.

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

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

Annotations only provide destructiveHint=false, indicating it's not destructive. The description adds valuable behavioral context: it explains the duplicate prevention mechanism ('skip_if_in_campaign=true to prevent duplicates'), provides an example of custom variables usage, and clarifies the bulk operation alternative. However, it doesn't mention authentication requirements, rate limits, or error conditions.

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 well-structured and front-loaded: the first sentence states the core purpose, followed by specific usage tips, an example, and an alternative for bulk operations. Every sentence adds value with zero wasted words, making it easy to scan and understand.

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 tool has an output schema (so return values are documented elsewhere) and annotations cover safety (destructiveHint=false), the description provides strong context for usage and parameters. It covers the main behavioral aspects (duplicate prevention, custom variables, bulk alternative) but doesn't address all potential edge cases or system constraints like rate limits.

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 description coverage is 0%, so the description carries full burden. It effectively explains key parameters: it clarifies the purpose of 'skip_if_in_campaign' (prevent duplicates), provides an example structure for 'custom_variables' with field matching requirements, and implicitly indicates 'email' is required. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the specific action ('Create a single lead') and resource ('lead with custom variables'), distinguishing it from siblings like 'add_leads_to_campaign_or_list_bulk' (for bulk operations) and 'update_lead' (for modifications). The first sentence directly answers 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?

The description provides explicit guidance on when to use this tool ('Create a single lead') versus alternatives ('For bulk imports (10+ leads), use add_leads_to_campaign_or_list_bulk instead'). It also includes a recommendation for a specific parameter ('Use skip_if_in_campaign=true to prevent duplicates (recommended)').

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 provide destructiveHint=false, indicating this is a non-destructive operation. The description adds useful context about the enrichment feature ('Set has_enrichment_task=true to enable automatic lead enrichment. Enrichment adds company info, social profiles, and other data.'), which goes beyond the annotations. However, it doesn't mention permissions, rate limits, or what happens after creation beyond enrichment.

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 appropriately concise with three sentences. The first states the purpose, the second explains the key parameter, and the third elaborates on enrichment benefits. Each sentence adds value, though the structure could be slightly improved by front-loading the enrichment explanation with the parameter mention.

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 that there's an output schema (which handles return values), annotations cover safety (destructiveHint=false), and the description explains the key enrichment feature, this is adequate for a creation tool. However, it doesn't address prerequisites, permissions, or how this tool relates to sibling operations like list_lead_lists or update_lead_list, leaving some contextual gaps.

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

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

The description provides specific guidance about the 'has_enrichment_task' parameter, explaining what it does and what enrichment includes. With 0% schema description coverage (schema has no parameter descriptions beyond the ref), this adds significant value. However, it doesn't mention the 'name' or 'owned_by' parameters, leaving those undocumented.

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

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

The description states 'Create a lead list' which clearly indicates the verb (create) and resource (lead list). However, it doesn't differentiate from sibling tools like 'create_campaign' or 'create_account' - all are creation operations for different resources. The purpose is clear but lacks sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. There are multiple creation tools (create_account, create_campaign, create_lead) and related list tools (list_lead_lists, update_lead_list, delete_lead_list), but the description offers no context about when this specific creation tool is appropriate versus other options.

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 'destructiveHint: true' annotation. It details specific consequences: 'Removes the account from all campaigns', 'Deletes all account data', and 'Cannot be reversed'. This provides concrete information about what gets destroyed and the irreversible nature, which the annotation alone doesn't specify.

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 well-structured and front-loaded with the critical warning. Each sentence adds value: the first states the action with urgency, the bullet points detail consequences, and the final sentence provides usage guidance. There's no redundant or wasted text, making it highly efficient.

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

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

Given the tool's high complexity (destructive, irreversible operation) and the presence of annotations and an output schema, the description is complete. It covers the purpose, behavioral consequences, and usage prerequisites. The output schema likely handles return values, so the description appropriately focuses on the irreversible nature and required confirmation.

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

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

With 0% schema description coverage for the single parameter, the description doesn't explicitly mention the 'email' parameter or its semantics. However, it implies the target is 'an email account', which aligns with the parameter. The description compensates by emphasizing the permanence ('PERMANENTLY delete'), but doesn't provide format or validation details for the email 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?

The description explicitly states the action ('PERMANENTLY delete') and resource ('an email account'), distinguishing it from sibling tools like 'delete_campaign' or 'delete_lead' by specifying the account type and irreversible nature. It uses strong language ('🚨', 'CANNOT UNDO!') to emphasize the specific destructive operation.

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 explicit guidance on when to use this tool: 'Confirm with user before executing!' This indicates a prerequisite user confirmation step. It also implicitly distinguishes from alternatives like 'manage_account_state' or 'update_account' by highlighting the permanent deletion aspect, though it doesn't name specific 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?

The annotations provide destructiveHint=true, but the description adds substantial behavioral context beyond this: it details what gets destroyed (campaign data, sequences, settings), clarifies what happens to leads (removed from campaign but not deleted), and emphasizes the irreversible nature. It doesn't contradict the destructiveHint annotation, but provides richer behavioral information.

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 appropriately sized and front-loaded with the most critical warning. Every sentence earns its place by providing essential warnings, behavioral details, or usage requirements. The structure moves from dire warning to specific consequences to mandatory prerequisites in a logical flow.

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

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

Given this is a highly destructive tool with only one annotation (destructiveHint), the description provides excellent completeness. It covers the irreversible nature, specific data affected, prerequisites for use, and warnings. With an output schema present, it doesn't need to explain return values, and it fully addresses the tool's critical behavioral aspects.

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

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

With 0% schema description coverage, the description compensates well by providing semantic context for the single parameter. While it doesn't explicitly name 'campaign_id', it repeatedly references verifying 'campaign_id' in the usage guidelines and mentions 'Campaign UUID' in the schema. The description adds meaning about the parameter's critical importance for this destructive operation.

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 specific action ('PERMANENTLY delete') and resource ('a campaign'), distinguishing it from sibling tools like 'delete_account', 'delete_lead', or 'delete_lead_list' which target different resources. The use of 'PERMANENTLY' and 'CANNOT UNDO!' emphasizes the irreversible nature of this deletion operation.

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 explicit guidance on when to use this tool: it lists three prerequisites that MUST be met before calling (user confirmation, campaign_id verification, warning about irreversibility). It also implicitly distinguishes from alternatives like 'pause_campaign' or 'update_campaign' by emphasizing the permanent deletion aspect.

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 'destructiveHint: true' annotation. It details specific effects: 'Removes the lead from all campaigns and lists' and 'Deletes all lead data and history,' and emphasizes 'CANNOT UNDO!' This provides actionable insights into the tool's destructive scope and permanence, enhancing the agent's understanding.

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 a clear warning ('🗑️ PERMANENTLY delete a lead. CANNOT UNDO!') followed by bullet points for key actions and a directive. Every sentence earns its place by reinforcing the tool's critical nature without redundancy, making it highly efficient and well-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?

Given the tool's high complexity (destructive, permanent) and the presence of annotations and an output schema, the description is complete. It covers purpose, guidelines, behavioral details, and warnings, addressing all necessary context for safe invocation without needing to explain return values, which the output schema handles.

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

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

With 0% schema description coverage, the description does not mention the 'lead_id' parameter explicitly. However, it implies the need for a lead identifier through context like 'delete a lead.' While it adds some meaning by clarifying the target, it doesn't detail parameter format or requirements, partially compensating for the schema gap.

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

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

The description explicitly states the action ('PERMANENTLY delete') and resource ('a lead'), distinguishing it from siblings like 'delete_campaign' or 'delete_lead_list' by specifying the target. It uses strong verbs and clear scope, 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 provides explicit guidance: 'Confirm with user before executing!' This indicates when to use (after user confirmation) and implies caution versus alternatives like 'update_lead' or 'deactivate' tools. It directly addresses the irreversible nature, guiding the agent on 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 annotations provide destructiveHint=true, which the description reinforces with 'PERMANENTLY delete' and 'CANNOT UNDO!'. It adds valuable context beyond annotations: the requirement for user confirmation, the potential for orphaned leads, and the irreversible nature. No contradiction with annotations 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?

The description is appropriately sized and front-loaded with the most critical information ('🚨 PERMANENTLY delete...'). Every sentence adds value, such as consequences and prerequisites, with no redundant or wasted text. The use of emojis and formatting enhances clarity without sacrificing efficiency.

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 tool's high complexity (destructive operation) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage guidelines, behavioral risks, and parameter importance, addressing all necessary aspects for safe and effective use.

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

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

With 0% schema description coverage (the schema only has a generic warning), the description compensates by emphasizing the criticality of the list_id parameter ('Verify the list_id is correct') and its role in identifying the lead list to delete. It adds meaningful context about parameter handling, though it doesn't detail the UUID format.

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 specific action ('PERMANENTLY delete') and resource ('a lead list'), distinguishing it from sibling tools like delete_account, delete_campaign, and delete_lead by specifying the target resource type. It uses strong, unambiguous language that leaves no doubt about the tool's function.

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 explicit guidance on when to use this tool: it mandates user confirmation, verification of the list_id, and a warning about irreversibility before execution. It implicitly distinguishes from other deletion tools by focusing on lead lists, though it doesn't name specific 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 provide readOnlyHint=true, indicating a safe read operation. The description adds valuable behavioral context beyond annotations by detailing the comprehensive information returned (e.g., connection status, warmup progress, daily limits), which helps the agent understand the tool's output scope and utility 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 front-loaded with the core purpose in the first sentence, followed by a bulleted list that efficiently details return values without redundancy. Every sentence earns its place by adding clarity, and the structure is well-organized for quick comprehension.

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 tool's complexity (single parameter, read-only operation), the description is complete: it states the purpose, details the return values (compensating for no output schema in the context signals), and aligns with annotations. The presence of an output schema (per context signals) further reduces the burden on the description, making this adequately comprehensive.

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

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

Schema description coverage is 0%, but the description compensates by specifying the parameter's purpose ('by email') and the input schema clearly defines a required 'email' parameter of type string. The description adds minimal semantics beyond the schema, but the schema itself is straightforward, making a baseline score of 3 appropriate.

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

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

The description clearly states the tool's purpose with specific verbs ('Get account details, warmup status, and campaign eligibility by email') and distinguishes it from siblings like 'list_accounts' (which likely lists multiple accounts) and 'update_account' (which modifies accounts). It specifies the resource (account) and key attributes retrieved.

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 specifying retrieval 'by email' and listing the types of information returned, which helps differentiate it from siblings like 'list_accounts' (no email parameter) or 'get_campaign' (different resource). However, it does not explicitly state when not to use it or name 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?

The annotations provide readOnlyHint=true, which the description aligns with by describing a retrieval operation ('Get campaign details'). The description adds valuable behavioral context beyond annotations by specifying what comprehensive information is returned (email sequences, schedule configuration, sender accounts, tracking settings, status/statistics), which helps the agent understand the scope and format of returned data.

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

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

The description is efficiently structured with a clear opening sentence stating the purpose, followed by a bulleted list detailing returned information. Every sentence earns its place by adding specific value about what the tool returns, with no redundant or vague phrasing.

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 tool's moderate complexity (retrieving detailed campaign data), the description provides good context about what information is returned. With annotations covering read-only safety and an output schema presumably detailing the response structure, the description focuses appropriately on clarifying the scope of returned data without needing to explain return values or safety aspects.

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

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

With 0% schema description coverage (the schema only states 'Input for getting campaign details' and 'Campaign UUID'), the description compensates well by implicitly clarifying that campaign_id is required to fetch details for a specific campaign. While it doesn't explicitly mention the parameter, the context makes its purpose clear. For a single parameter tool, this provides adequate semantic understanding.

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's purpose as retrieving campaign details with specific components listed (config, sequences, schedules, sender accounts, tracking, status). It distinguishes from siblings like list_campaigns (which lists campaigns) and update_campaign (which modifies campaigns), but doesn't explicitly contrast with get_account or get_lead which have similar 'get' patterns for different resources.

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 description's focus on retrieving comprehensive details for a specific campaign, suggesting it should be used when detailed information is needed rather than just listing campaigns. However, there's no explicit guidance on when to use this versus alternatives like search_campaigns_by_contact or what prerequisites exist (e.g., needing a valid campaign_id).

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 value beyond the 'readOnlyHint: true' annotation by detailing the comprehensive information returned (e.g., contact details, custom variables, sequence status). However, it doesn't disclose other behavioral traits like error handling, rate limits, or authentication needs, which are important for a read operation but not covered by annotations.

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

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

The description is well-structured and front-loaded: the first sentence states the core purpose, followed by a bulleted list of return details. Every sentence earns its place by adding clarity without redundancy, making it efficient and easy to parse for an AI agent.

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 tool's low complexity (1 parameter), annotations covering read-only safety, and the presence of an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It explains what the tool does and what information it returns, though it could benefit from more usage context or error details to be fully comprehensive.

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

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

With 0% schema description coverage, the schema only documents 'lead_id' as a 'Lead UUID' without further context. The description doesn't add any parameter-specific semantics, such as format examples or validation rules. Since the schema provides basic info, the baseline score of 3 is appropriate, but the description fails to compensate for the low coverage.

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

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

The description clearly states the tool's purpose: 'Get lead details by ID' specifies the verb ('Get') and resource ('lead details'), making it distinct from siblings like 'list_leads' or 'update_lead'. However, it doesn't explicitly differentiate from 'get_account' or 'get_campaign', which follow a similar pattern, leaving some ambiguity in sibling context.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a lead ID), exclusions, or comparisons to siblings like 'list_leads' for browsing or 'search_campaigns_by_contact' for finding leads. This lack of context could lead to misuse in complex scenarios.

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 the description aligns by describing a read operation ('Get'). It adds valuable context beyond annotations by specifying the return content (server version, loaded categories, configuration status) and the use case for debugging, which helps the agent understand the tool's behavior and output.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by specific return details and usage context in two additional sentences. Every sentence adds value without waste, making it efficient and well-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?

Given the tool's simplicity (0 parameters, read-only, with output schema), the description is complete. It explains what the tool does, what it returns, and when to use it, covering all necessary aspects without needing to detail parameters or output structure.

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

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

With 0 parameters and 100% schema description coverage, the baseline is high. The description does not need to explain parameters, and it appropriately focuses on the tool's purpose and output, adding no redundant information.

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 'Get' and the resource 'Instantly MCP server information', specifying it returns server version, loaded categories, and configuration status. It distinguishes from sibling tools like get_account or get_campaign by focusing on server metadata rather than domain entities.

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 explicit context for usage ('Useful for debugging and verifying server setup'), which helps the agent understand when to invoke this tool. However, it does not explicitly state when not to use it or name specific alternatives among 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?

The annotations provide readOnlyHint=true, indicating this is a safe read operation. The description adds value by detailing the return breakdown (valid, invalid, risky, unknown emails), which goes beyond the annotations. However, it doesn't disclose other behavioral traits like rate limits, authentication needs, or data freshness, leaving some gaps in transparency.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a bulleted list of return values that adds necessary detail without redundancy. It's appropriately sized, with every sentence earning its place by clarifying output semantics, making it efficient and well-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?

Given the tool's low complexity (one parameter) and the presence of an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It explains what the tool does and the breakdown of results, which complements the structured data. However, it lacks usage context and some behavioral details, slightly reducing completeness for a read operation.

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

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

The input schema has 0% description coverage, with only one parameter 'list_id' documented as 'List UUID' in the schema. The description doesn't add any parameter-specific details beyond implying it operates on a 'lead list'. Since schema coverage is low, the description compensates minimally by clarifying the tool's overall function, but doesn't explain parameter usage or constraints, meeting the baseline for moderate schema coverage.

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

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

The description clearly states the tool's purpose: 'Get email verification statistics for a lead list.' It specifies the verb ('Get'), resource ('email verification statistics'), and target ('lead list'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'get_lead' or 'list_lead_lists', which also retrieve lead-related data, so it misses full sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing lead list), exclusions, or compare it to siblings like 'get_lead' or 'list_leads', which might offer overlapping functionality. Without such context, users must infer usage from the name alone.

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

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

The annotations declare readOnlyHint=true, and the description reinforces this by describing a listing operation. It adds valuable behavioral context beyond annotations: pagination mechanics (cursor-based, 100 per page), status code meanings, provider code mappings, and return content details (warmup status, campaign eligibility). This significantly enhances the agent's understanding of how the tool behaves.

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 efficiently structured with clear sections: purpose statement, pagination instructions, status codes, provider codes, and return content. Every sentence adds value - no redundant information. It's front-loaded with the core functionality and follows with essential operational details.

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 tool's complexity (pagination, multiple parameter types, status codes), the description provides comprehensive context. With annotations covering safety (readOnlyHint=true) and an output schema existing, the description focuses on operational mechanics, code mappings, and return content - exactly what's needed for the agent to use the tool effectively.

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

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

With 0% schema description coverage, the description carries full burden for parameter understanding. It doesn't explicitly mention individual parameters like 'limit', 'starting_after', 'search', etc., but provides crucial semantic context: pagination cursor usage, status code meanings (1=Active, 2=Paused, -1/-2/-3=Errors), and provider code mappings (1=IMAP, 2=Google, 3=Microsoft, 4=AWS). This compensates well for the schema coverage gap.

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

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

The description clearly states the verb ('List') and resource ('email accounts'), specifies cursor-based pagination with page size, and distinguishes from siblings like 'get_account' (singular) and 'create_account' (write operation). It provides specific scope details that differentiate it from other list tools.

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

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

The description provides clear context about pagination mechanics and when to make subsequent calls, but doesn't explicitly state when to use this tool versus alternatives like 'get_account' for single accounts or 'search_campaigns_by_contact' for campaign-related queries. It offers good operational guidance but lacks sibling differentiation.

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 provide readOnlyHint=true, but the description adds valuable behavioral context: pagination mechanics (cursor-based, 100 per page, continuation logic), search limitations (filters by name only, not status), and return content (campaign list with status, lead counts, performance metrics). No contradictions 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?

The description is well-structured and front-loaded with key information (list campaigns, pagination details). Each sentence adds value: pagination mechanics, search constraints, alternative tool, and return data. 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?

Given the tool's complexity (pagination, filtering), annotations (readOnlyHint), and output schema (exists), the description is complete. It covers purpose, usage, behavioral traits, and parameter context adequately without needing to detail return values (handled by output schema).

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

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

Schema description coverage is 0%, but the description compensates by explaining pagination (starting_after usage), search limitations (by name only), and implies parameters like limit (100 per page) and search. It doesn't cover all parameters (e.g., tag_ids), but adds significant meaning beyond the bare schema.

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

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

The description clearly states the verb 'List' and resource 'campaigns', specifies cursor-based pagination with 100 per page, and distinguishes from siblings by noting search filters by name only (not status). It explicitly mentions an alternative tool for status filtering (get_daily_campaign_analytics).

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

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

The description provides explicit guidance on when to use this tool (for listing campaigns with pagination) versus alternatives (use get_daily_campaign_analytics to filter by status). It also details the pagination continuation logic, offering clear operational context.

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

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

Annotations declare readOnlyHint=true, which the description aligns with by describing a listing operation. The description adds valuable behavioral context beyond annotations: it explains pagination mechanics (cursor-based, 100 per page, how to continue), which is crucial for correct usage. It doesn't mention rate limits or authentication needs, but with annotations covering safety, this is sufficient.

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 well-structured and front-loaded: first sentence states core purpose, followed by dedicated PAGINATION section, then usage context. Every sentence adds value—no wasted words. It's appropriately sized for a tool with pagination complexity.

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 tool's complexity (pagination, filtering) and rich annotations (readOnlyHint), the description is complete. It explains pagination behavior, filtering use case, and resource context. With an output schema present, it doesn't need to detail return values, making this description fully adequate.

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

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

Schema description coverage is 0%, so the description carries full burden. It effectively explains key parameters: 'starting_after' (pagination cursor), 'has_enrichment_task' (filter for auto-enrichment), and implies 'limit' (100 per page). It adds meaning beyond the bare schema by clarifying how parameters interact with pagination and filtering.

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's purpose: 'List lead lists with cursor-based pagination (100 per page).' It specifies the verb ('List'), resource ('lead lists'), and scope ('with cursor-based pagination'), and distinguishes from siblings like 'get_lead_list' (singular) or 'list_leads' (different resource).

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 context for usage: 'Lead lists are containers for organizing leads outside of campaigns. Use has_enrichment_task filter to find lists with auto-enrichment enabled.' It explains when to use the filter but doesn't explicitly state when not to use this tool versus alternatives like 'list_campaigns' or 'search_campaigns_by_contact'.

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 provide readOnlyHint=true, but the description adds valuable behavioral context: pagination mechanics (cursor-based, 100 per page, continuation logic), filter value meanings, and deduplication behavior. This goes beyond what annotations alone convey about this read operation.

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

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

Well-structured with clear sections: pagination instructions, filter values, and deduplication. Every sentence adds value with zero waste. The information is front-loaded with the core purpose and pagination details.

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 tool's complexity (pagination, filtering, deduplication) and 0% schema coverage, the description provides complete guidance. With annotations covering safety and an output schema presumably handling return values, the description fills all necessary gaps about usage mechanics.

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

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

With 0% schema description coverage, the description fully compensates by explaining pagination behavior, filter value meanings (FILTER_VAL_CONTACTED, etc.), and the distinct_contacts parameter's purpose. It provides essential semantic context that the schema lacks.

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 ('List') and resource ('leads'), and specifies cursor-based pagination with 100 per page. It distinguishes from siblings like 'get_lead' (single lead) and 'search_campaigns_by_contact' (different resource/focus).

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 context for pagination and filtering usage, including how to handle multiple pages and filter values. However, it doesn't explicitly state when to use this versus alternatives like 'search_campaigns_by_contact' or 'get_lead', though the purpose distinction is implied.

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

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

Annotations provide destructiveHint=false, indicating non-destructive operations. The description adds valuable context beyond this: it explains what each action does (e.g., 'Stop all sending from this account' for pause, 'Test IMAP/SMTP connectivity' for test_vitals). This clarifies behavioral outcomes without contradicting annotations. However, it doesn't mention rate limits, authentication needs, or error conditions.

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 well-structured and front-loaded with the core purpose, followed by a bulleted list of actions and a specific usage note. Every sentence earns its place: the first sentence summarizes, the list details actions, and the last sentence provides targeted guidance. No wasted words or 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?

Given the tool's moderate complexity (state management with multiple actions), annotations cover safety (non-destructive), and an output schema exists (so return values needn't be described). The description adds good context about actions but could better address the email parameter and potential side effects. It's mostly complete but has minor gaps in parameter explanation.

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

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

Schema description coverage is 0%, so the description must compensate. It effectively explains the semantics of the action parameter by listing and describing each enum value (pause, resume, etc.). However, it doesn't clarify the email parameter's role or format. Since there's only 1 parameter (a nested object with 2 sub-parameters), the description covers the more complex part well but leaves the email parameter unexplained.

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

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

The description clearly states the tool's purpose with specific verbs (pause, resume, enable/disable warmup, test vitals) and the resource (account state). It distinguishes itself from siblings like pause_campaign (which targets campaigns) and update_account (which likely modifies settings rather than state transitions). The action list provides concrete examples of what 'manage' means.

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 context for when to use test_vitals ('to diagnose connection issues'), which helps guide selection. However, it doesn't explicitly state when to choose this tool over alternatives like update_account or pause_campaign, nor does it mention prerequisites or exclusions for other actions. The guidance is helpful but incomplete regarding sibling differentiation.

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 provide destructiveHint=false, but the description adds valuable behavioral context: it discloses that operations run as background jobs for large operations, which implies asynchronous processing and potential delays. It also clarifies the move vs. copy behavior with copy_leads. 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?

The description is front-loaded with the core purpose, followed by structured bullet-like sections for source selection, destination, and copy behavior. Every sentence adds essential information with zero waste, making it highly efficient and easy to parse.

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 tool's complexity (20+ parameters, background job behavior) and the presence of an output schema (which handles return values), the description is largely complete. It covers the main use cases and behavioral traits, though it doesn't detail all schema parameters like check_duplicates or limit, which could be helpful for advanced usage.

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

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

Schema description coverage is 0%, so the description must compensate. It effectively explains key parameters: source selection methods (ids, search, filter with campaign/list_id), destination options (to_campaign_id, to_list_id), and copy_leads. However, it doesn't cover all 20+ parameters in the schema, leaving some undocumented.

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

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

The description clearly states the specific action ('move or copy leads between campaigns/lists'), identifies the resource ('leads'), and distinguishes from siblings like 'add_leads_to_campaign_or_list_bulk' by emphasizing movement/copying between existing campaigns/lists rather than bulk addition.

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 explicit usage rules: it specifies source selection options (ids, search+campaign/list_id, filter+campaign/list_id), destination options (to_campaign_id OR to_list_id), and when to use copy_leads=true. It also mentions it 'runs as background job for large operations,' indicating appropriate context.

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

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

The description adds valuable behavioral context beyond the annotations. While annotations only indicate destructiveHint=false, the description details specific effects: 'Immediately stops all email sending', 'Leads remain in the campaign', and 'In-progress sequences are paused'. This provides crucial operational information not captured 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?

The description is perfectly structured and concise. It starts with the core purpose, lists specific effects in bullet points for clarity, and ends with usage guidance. Every sentence earns its place with zero 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?

Given the tool's moderate complexity, the presence of annotations, and an output schema, the description is complete. It covers purpose, effects, and usage guidance. The output schema existence means the description doesn't need to explain return values, making this description fully adequate.

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

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

With 0% schema description coverage, the description doesn't provide any parameter information beyond what's implied by the tool name. The schema already documents the single 'campaign_id' parameter with its description, so the description adds no additional parameter semantics. This meets the baseline for high schema coverage situations.

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 specific action ('Pause campaign to stop sending') and distinguishes it from siblings by mentioning 'activate_campaign to resume sending'. It specifies the exact effect on email sending, which differentiates it from deletion or other campaign management 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 explicitly states when to use this tool ('Pause campaign to stop sending') and when to use an alternative ('Use activate_campaign to resume sending'). It provides clear context about the tool's purpose versus its sibling activate_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 declare readOnlyHint=true, and the description aligns by describing a search/retrieval operation ('Find', 'Returns list'). It adds valuable behavioral context beyond annotations by specifying the return format ('list of campaigns the contact email is enrolled in') and clarifying the search scope (enrolled campaigns only). 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?

The description is well-structured and front-loaded with the core purpose, followed by a bulleted list of use cases and a clear statement about return values. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 tool's low complexity (1 parameter), rich annotations (readOnlyHint), and existence of an output schema, the description is complete. It covers purpose, usage scenarios, and return behavior, leaving no significant gaps for agent understanding.

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

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

Schema description coverage is 0%, but the input schema's $defs includes a detailed description that explains the parameter's purpose ('Finds all campaigns a specific lead/contact is enrolled in') and format ('Email address'). The tool description does not add further parameter details, so it meets the baseline for adequate coverage without enhancing 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?

The description clearly states the tool's purpose with specific verb ('Find') and resource ('campaigns'), and distinguishes it from siblings by focusing on contact-based search rather than general listing or management. It explicitly identifies the target (campaigns a specific contact is part of), making the scope 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 provides clear usage context through a 'Useful for' section with three specific scenarios (checking existing campaigns, finding duplicates, auditing membership). However, it does not explicitly state when NOT to use this tool or name alternative tools (like list_campaigns for broader searches), which prevents a perfect score.

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

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

The annotations provide 'destructiveHint: false,' indicating non-destructive behavior, which the description doesn't contradict. The description adds useful context about partial updates and common use cases, but doesn't disclose other behavioral traits like authentication needs, rate limits, or what happens to unspecified fields. With annotations covering the safety profile, this is adequate but not rich in additional behavioral details.

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

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

The description is well-structured and appropriately sized, with a clear purpose statement followed by a bulleted list of common updates and a closing instruction. Every sentence adds value, and it's front-loaded with the core functionality. It could be slightly more concise by integrating the instruction into the opening sentence.

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

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

Given the complexity (multiple parameters, nested objects) and the presence of an output schema (which reduces the need to explain return values), the description is reasonably complete. It covers key parameters and the partial update nature, but doesn't address all schema parameters or potential side effects. With annotations providing destructiveHint and an output schema existing, it's sufficient but not exhaustive.

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 description coverage is 0%, so the description carries the full burden. It adds significant value by explaining the semantics of common parameters (e.g., 'first_name, last_name: Display name,' 'daily_limit: Max emails per day (1-100)'), which clarifies their purpose beyond the schema's basic types. However, it doesn't cover all parameters listed in the schema, such as 'enable_slow_ramp' or 'remove_tracking_domain.'

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's purpose: 'Update account settings (partial update).' It specifies the verb ('update'), resource ('account settings'), and scope ('partial update'), which distinguishes it from other update operations. However, it doesn't explicitly differentiate from sibling tools like 'manage_account_state' or 'create_account'.

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 implied usage guidance through the 'Common updates' list and the instruction 'Only include fields you want to update,' which suggests this is for partial updates. However, it doesn't explicitly state when to use this tool versus alternatives like 'manage_account_state' or 'create_account,' nor does it mention prerequisites or 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 provide 'destructiveHint: false,' indicating it's not destructive, but the description adds useful context: it clarifies this is a 'partial update' and lists common fields that can be updated. However, it doesn't disclose other behavioral traits like authentication needs, rate limits, or what happens if invalid fields are provided. No contradiction with annotations 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?

The description is appropriately sized and front-loaded: it starts with the core purpose, then lists common updates in a bulleted format, and ends with a key instruction. Each sentence earns its place, but the bulleted list could be slightly more structured for clarity.

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

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

Given the tool's complexity (many parameters) and the presence of an output schema (which handles return values), the description is fairly complete. It covers the purpose, partial update nature, and common parameters, though it could benefit from more behavioral context or error handling info. The annotations provide basic safety, but more details would enhance completeness.

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 description coverage is 0%, so the description carries the full burden. It adds significant value by listing common parameters (e.g., name, sequences, email_list) with brief explanations, such as 'Campaign display name' for 'name' and 'Sender account assignments' for 'email_list.' This compensates well for the lack of schema descriptions, though it doesn't cover all parameters.

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

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

The description clearly states the tool's purpose: 'Update campaign settings (partial update).' It specifies the verb ('update'), resource ('campaign settings'), and scope ('partial update'), which is more specific than just the tool name. However, it doesn't explicitly differentiate from sibling tools like 'update_account' or 'update_lead', though the resource specificity helps.

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 implied usage guidance: it mentions 'partial update' and 'Only include fields you want to update,' suggesting this is for modifying specific settings rather than full replacements. However, it doesn't explicitly state when to use this tool versus alternatives like 'create_campaign' or 'delete_campaign,' nor does it mention prerequisites or 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?

The description adds valuable behavioral context beyond the annotations. While annotations only indicate destructiveHint=false (non-destructive), the description reveals the critical nuance that custom_variables 'REPLACES the entire object!' This is a crucial behavioral trait that isn't captured in annotations. It also provides a step-by-step workflow for safe usage. No contradiction with annotations 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?

The description is efficiently structured with zero wasted text. It starts with the core purpose, immediately highlights the most important warning with an emoji, provides clear numbered steps for correct usage, and concludes with a concrete example. Every sentence serves a distinct purpose and contributes to understanding.

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 this is a mutation tool with 0% schema description coverage but with an output schema present, the description provides excellent contextual completeness. It covers the critical behavioral nuance (custom_variables replacement behavior), provides usage workflow, and includes examples. The presence of an output schema means the description doesn't need to explain return values, allowing it to focus on the most important usage considerations.

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

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

The description provides essential parameter semantics that compensate for the 0% schema description coverage. It explains the critical behavior of the custom_variables parameter ('REPLACES the entire object!') and provides a concrete example showing how to properly handle parameter values. This adds significant meaning beyond what the bare schema provides, especially given the low schema coverage.

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

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

The description clearly states the tool's purpose: 'Update lead (partial update).' It specifies the verb ('update'), resource ('lead'), and scope ('partial update'), distinguishing it from create_lead and delete_lead. However, it doesn't explicitly differentiate from update_account or update_campaign, which are similar mutation operations on different resources.

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 explicit guidance on when and how to use this tool: 'To preserve existing custom variables: 1. First call get_lead to retrieve current values 2. Merge your changes with existing values 3. Pass the complete merged object.' It names a specific alternative (get_lead) for prerequisite data retrieval and gives a concrete example of correct usage versus incorrect usage.

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

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

The annotations provide 'destructiveHint: false', indicating this is a non-destructive operation. The description adds value by specifying updatable fields (name, enrichment settings, owner), which clarifies the scope of changes. However, it lacks behavioral details like permission requirements, whether updates are partial or overwrite all fields, or rate limits. No contradiction with annotations 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?

The description is a single, efficient sentence with zero waste. It front-loads the core action ('Update lead list') and specifies key updatable aspects. Every word adds value, making it easy for an agent to parse quickly.

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 tool has annotations (destructiveHint) and an output schema (implied by context signals), the description doesn't need to cover safety or return values. However, as a mutation tool with 0% schema coverage and no usage guidelines, it leaves gaps in parameter understanding and context. It's minimally adequate but lacks depth for effective agent use.

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

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

Schema description coverage is 0%, so the schema provides no parameter descriptions. The description compensates by listing updatable fields (name, enrichment settings, owner), which map to parameters in the schema. However, it doesn't explain 'list_id' (the required parameter) or provide details on format, constraints, or default behaviors for nullable fields. Baseline is 3 due to partial compensation.

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 ('Update') and target resource ('lead list'), and specifies what can be updated ('name, enrichment settings, or owner'). It distinguishes from siblings like 'create_lead_list' and 'delete_lead_list' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from other update tools like 'update_account' or 'update_campaign' beyond the resource 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing list), exclusions (e.g., what cannot be updated), or comparisons to siblings like 'create_lead_list' for new lists or 'get_lead' for read-only access. The agent must infer usage from the tool name alone.

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