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

The description goes well beyond the annotations by disclosing that it 'creates remote state', is 'blocked in readonly mode', and 'does not send email'. It also states it is non-destructive. These facts align with annotations and add valuable operational context.

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

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

The description is front-loaded with the purpose and uses small, readable sections. However, there is redundancy: the 'Safety —' line duplicates the later statements 'Creates remote state' and 'Does not send email'. This prevents a higher score.

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?

Together with the rich input schema and output schema, the description covers purpose, safety profile, endpoint, and suppression semantics. It is sufficient for correct invocation, though it could optionally mention auth or 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 already provides 100% coverage of parameters, so the baseline is 3. The description adds meaningful context by emphasizing 'global block list' and 'no campaign emails them', clarifying that the domain_block_list parameter applies across all campaigns, not just a single campaign.

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: 'Add domains or email addresses to the global block list so no campaign emails them.' It specifies the verb, resource, and effect, and clearly distinguishes the tool from its siblings like get_domain_block_list and remove_domain_from_block_list.

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

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

The description makes the use case clear: use it to suppress outbound emails to certain domains/addresses. It also frames it as a 'suppression action' and contrasts with the read-only get/remove siblings. However, it does not explicitly state when not to use it or mention alternative 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?

Despite annotations already indicating readOnlyHint=false and destructiveHint=true, the description adds rich context: endpoint, creates/modifies remote state, blocked in readonly mode, duplicate email handling (case-insensitive, trimmed), no auto-retry to avoid double imports, and detailed destructive bypass conditions. This goes far beyond annotations and fully discloses behavior.

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

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

The description is appropriately sized for a complex tool, with useful front-loading of the core purpose and safety summary. It covers many behavioral aspects without being overly verbose, though the 'Safety' bullet list and the later 'Creates remote state' line are somewhat redundant.

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

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

Given the tool's complexity (nested objects, 5 params, write operation, destructive potential), the description is exceptionally complete. It covers key gotchas: no auto-retry (idempotency), dedupe behavior, activation separation, destructive confirmation requirements, and readonly blocking. An output schema exists, so not explaining return values is acceptable.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats some parameter constraints (confirm_import must be true, max 400, duplicate removal) that are already in the schema. It adds minor context around the meaning of confirm_destructive and the local deduplication behavior, but does not substantially enhance understanding beyond the schema's own parameter descriptions.

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

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

The description opens with 'Import leads into an explicitly named campaign,' which is a specific verb+resource statement that clearly distinguishes it from sibling tools like smartlead_get_campaign_leads (retrieves) and smartlead_update_campaign_status (changes status). It also explicitly disambiguates by stating 'Never activates the campaign — use smartlead_update_campaign_status separately.'

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 operational constraints: requires explicit campaign_id and confirm_import: true, max 400 leads, and blocks in readonly mode. It also points to the alternative tool for activation. However, it does not explicitly state when to prefer this tool over other lead-importing methods or list all sibling 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 description reveals important behaviors beyond annotations: DRAFTED status, inability to send email until explicitly started, remote state creation, readonly-mode blocking, and non-idempotency with duplicate-campaign risk. 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 and includes structured safety info. However, it repeats 'Creates remote state' and the draft status, making it slightly redundant. Overall, each section still earns its place.

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

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

For a relatively simple create operation with a complete schema and output schema, the description adequately covers behavior, safety, and endpoint. It does not mention authentication or rate limits, but those are not essential for invocation.

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

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

The input schema already provides 100% description coverage for both parameters (name and client_id). The tool description adds no additional parameter-level detail, so the baseline score of 3 applies.

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

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

The description states 'Create a new Smartlead campaign' — a specific verb and resource. It also notes the DRAFTED status, which distinguishes it from other campaign-related tools like status updates or listing.

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 usage context is clear: this is the tool to create a campaign. It provides operational constraints such as 'Blocked in readonly mode' and 'Never auto-retried', but does not explicitly name alternative tools or when not to use this one.

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 provides extensive safety detail: 'read-only: yes; ... creates or modifies remote state: no; ... destructive: no.' However, the annotation idempotentHint=false directly contradicts the description's claim of no state modification, which implies idempotency. This is an annotation contradiction, so the behavioral transparency score is 1.

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

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

The description is concise and front-loaded with the purpose. The safety list is clear but redundant at the end ('Free and read-only' repeats earlier statements). Overall, it is efficient and does not waste words, though it could be slightly tighter.

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 low complexity (2 parameters, no nested objects) and the presence of an output schema, the description is complete: it states the purpose, provides the endpoint, and explicitly discloses all relevant safety traits. The idempotency contradiction does not affect the completeness of usage instructions for this simple read-only GET.

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 covers both parameters with descriptions (campaign_id and include_tags) at 100% coverage. The description adds only the endpoint template (e.g., {campaign_id}) but no additional semantic detail beyond what the schema already provides. Baseline 3 for full 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: 'Retrieve full configuration for one campaign by ID.' It specifies the action (retrieve), the resource (full configuration for one campaign), and the selection criterion (by ID). This distinguishes it from siblings like smartlead_list_campaigns (which lists campaigns) and smartlead_get_campaign_analytics (which retrieves 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 gives clear context: use when you need the full configuration of a specific campaign by ID. However, it does not explicitly name alternatives or state when not to use this tool. It implies the usage but lacks an explicit comparison 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 already provide readOnlyHint=true and destructiveHint=false. The description goes beyond this by explicitly stating 'may consume SmartProspect credits: no' and 'can send email: no', adding useful side-effect context. The endpoint is also disclosed, which helps understanding the remote 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?

The description is compact, starting with a clear purpose sentence, followed by a structured safety summary and endpoint. Every sentence earns its place; no fluff or repetition.

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

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

Given the tool's simple parameter set (one required integer) and the presence of an output schema (so return values need no explanation), the description is fully sufficient. It covers purpose, safety, and endpoint without requiring further clarification.

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 fully documents campaign_id with type integer and description 'Campaign ID' (100% coverage). The description mentions 'one campaign' but does not add extra detail about how to obtain or format the ID, so it provides minimal incremental meaning beyond the schema.

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

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

The description states a specific verb ('Retrieve') and resource ('performance analytics for one campaign') along with the included metrics (sent, opened, replied, bounced). This clearly distinguishes it from siblings like smartlead_get_campaign, which likely fetches campaign details rather than 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 clearly implies when to use this tool: when needing analytics for a specific campaign. The read-only safety guarantees also make it a safe choice for read operations. However, it does not explicitly name alternatives or exclusions, but the single-purpose phrasing provides sufficient 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?

Beyond the annotations' readOnlyHint and destructiveHint, the description explicitly enumerates safety properties: 'may consume SmartProspect credits: no; creates or modifies remote state: no; can send email: no; destructive: no.' It also adds a privacy note about returning personal data (emails and names), which is valuable context not present in annotations.

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

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

The description is remarkably concise, with a single-sentence purpose followed by a compact safety/endpoint block. Every sentence carries meaningful information; there is no redundancy or filler.

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

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

With an output schema present (per context signals) and full parameter documentation in the input schema, the description only needs to convey safety and data sensitivity, which it does. It also specifies the REST endpoint, providing a complete operational picture.

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

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

Schema coverage is 100% with detailed descriptions for each parameter. The description's mention of 'pagination and status/engagement filters' adds no new meaning beyond the schema, so it earns the baseline score for a well-documented 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 states 'List leads in a campaign with pagination and status/engagement filters,' which is a specific verb+resource combination that clearly distinguishes this tool from siblings like smartlead_get_campaign (which retrieves campaign details) and smartlead_get_campaign_analytics (which returns analytics). The scope is unambiguous.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisite conditions. It simply describes the function without situating it among the many 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 already provide readOnlyHint and destructiveHint, but the description adds concrete safety specifics: 'read-only: yes', 'may consume SmartProspect credits: no', 'creates or modifies remote state: no', 'can send email: no', and 'destructive: no'. It also states the endpoint, providing useful context beyond the annotations.

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

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

The description is front-loaded with the purpose and then provides a structured safety block. The final 'Free and read-only' is slightly redundant with the safety line, but the overall length is acceptable and every other sentence adds value.

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

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

For a simple list operation, this description is complete: it states the purpose, safety profile, endpoint, and is backed by a full input schema and output schema. The agent has all necessary context to invoke the tool safely and correctly.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The description's mention of 'source and client association' hints at filter_client_id but does not add parameter-level meaning beyond what the schema provides.

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

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

The description opens with 'List blocked domains and email addresses' which uses a specific verb and resource, and adds 'with their source and client association' to clarify the returned data. It clearly distinguishes this get/list tool from sibling add/remove block-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 implies this is the read-only viewing tool for the domain block list, especially given sibling tools 'smartlead_add_domain_to_block_list' and 'smartlead_remove_domain_from_block_list'. However, it lacks explicit when-to-use or exclusionary language, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description goes beyond this by explicitly stating no SmartProspect credit consumption, no email sending, no remote state modification, and that it returns personal data. It also provides the endpoint. This adds significant behavioral context beyond the structured 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 concise and well-structured: a single-purpose statement, followed by neatly labeled safety details, and a final note about personal data. Every sentence adds value, and no unnecessary words are used.

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 simple nature of the tool, the presence of an output schema, and the annotations, the description fully covers purpose, safety, endpoint, and a privacy consideration. It is complete for an agent to select and invoke the tool confidently.

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

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

The schema has 100% coverage over the sole 'email' parameter, with its own description 'Email address to look up.' The tool description only reiterates the email-based lookup without adding format, examples, or constraints. Baseline of 3 is correct since the schema does the heavy lifting.

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

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

The description opens with a clear, specific verb+resource: "Look up a single lead by email address and return its associated campaign data." This immediately distinguishes it from sibling tools like smartlead_list_campaigns or smartprospect_get_contacts. The scope is precise and 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 clearly implies the use case: looking up a lead by email. It provides context but does not explicitly mention alternatives or when not to use this tool. Since the tool is simple and the context is clear, it does not need exclusions, but naming an alternative would have pushed it to a 5.

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

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

Beyond annotations (readOnlyHint, destructiveHint), the description explicitly states 'may consume SmartProspect credits: no; creates or modifies remote state: no; can send email: no; destructive: no' and 'Free and read-only'. This adds detailed safety context, and there is 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 concise and well-structured: one sentence for purpose, one for safety, one for endpoint, and a short concluding phrase. Every sentence adds distinct value with no redundancy except minor repetition of 'read-only'.

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 an output schema exists, return values are covered. The description plus annotations and schema fully cover the behavior of this simple list tool: what it does, safety profile, endpoint, and parameter details. No critical gaps remain.

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

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

Schema description coverage is 100%, with both parameters (client_id, include_tags) already described in the input schema. The tool description does not add additional parameter semantics, so the baseline of 3 applies.

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

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

The description opens with 'List all Smartlead campaigns with status, schedule and sending configuration', which is a specific verb ('List'), resource ('Smartlead campaigns'), and scope ('all'). This clearly distinguishes it from sibling tools like smartlead_get_campaign which fetches a single campaign.

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

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

The description clearly implies usage for listing all campaigns, but it does not explicitly mention alternatives or when-not-to-use. The 'List all' phrasing provides clear context and filters, though no exclusions or alternatives are stated.

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

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

Beyond the annotations, the description explicitly discloses read-only behavior, no credit consumption, no state modification, no email sending, and no destructive actions. It also notes that mailbox addresses are personal data, adding a privacy consideration not present in the structured metadata.

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 and all information is concise. There is slight redundancy with 'Free and read-only' repeating part of the safety block, but overall each sentence provides unique value.

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

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

The description covers the endpoint, safety profile, and a privacy note. It does not explain return values or pagination, but the presence of an output schema and the schema's limit/offset parameters makes this unnecessary for a read-only list operation. The description is sufficiently complete for its complexity.

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

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

The input schema has 100% parameter coverage, so the schema already documents each parameter. The description adds only a high-level mention of warmup, SMTP, and provider filters without adding per-parameter syntax or details. The baseline of 3 is appropriate.

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

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

The description clearly states 'List connected sending accounts with warmup, SMTP and provider filters', using a specific verb and resource. It is easily distinguishable from sibling tools like smartlead_list_campaigns, which focus on campaigns rather than email accounts.

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

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

The description implies usage context by mentioning the resource type and filters, but it does not explicitly state when to use this tool versus alternatives, nor does it name other tools for related tasks. It provides no exclusions or explicit when-not-to-use guidance.

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

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

The description goes beyond the annotations by explicitly stating that it consumes no SmartProspect credits, does not create or modify remote state, cannot send email, and is not destructive. This directly addresses safety and side-effect concerns, adding significant value over the readOnlyHint and destructiveHint 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 two concise sentences. The first sentence states the core functionality, and the second summarizes safety and endpoint details. No unnecessary words or repetition. Information is front-loaded.

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

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

For a simple, read-only list operation with four optional parameters and an output schema, the description is complete. It states the endpoint, confirms read-only behavior, and the output schema covers return values. No critical information is missing.

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

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

The input schema provides 100% coverage with detailed descriptions for all four parameters. The description mentions 'name and tag filtering' which maps to listName and tagIds, but adds no new semantic information beyond summarizing what the schema already states. This meets the baseline for full 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 action ('List') and resource ('saved lead lists'), and mentions the optional filtering capabilities ('name and tag filtering'). This unambiguously distinguishes it from sibling tools like smartlead_list_campaigns or smartlead_list_email_accounts.

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

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

The description provides clear context: this is for listing lead lists, with optional filters. While it does not explicitly name alternatives or exclusion criteria, the purpose is self-evident and aligns with the tool's name. The 'Free and read-only' note adds practical guidance.

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

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

The description goes well beyond the annotations by detailing the runtime effects: it deletes a suppression record, re-enables sending to a previously blocked recipient, and classifies itself as DESTRUCTIVE. It also includes an endpoint URL and a safety summary. This exceeds what the annotations alone provide, offering clear expectations about the tool's side effects and prerequisites.

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 structured in short lines, each delivering a distinct piece of information (action, safety, endpoint, guardrails, prerequisite). It is longer than necessary but remains focused and easy to scan. The front-loaded sentence states the core purpose and consequence clearly.

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

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

With an output schema present, the description does not need to explain return values. It covers the purpose, prerequisites, safety classification, and related sibling tool for verification. The combination of schema, annotations, and context signals is comprehensive enough for an AI agent to use this tool correctly and safely.

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

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

The schema already covers both parameters with descriptions, and the description reinforces the semantics by stating that the id comes from smartlead_get_domain_block_list and that confirm_destructive must be true. This adds useful context beyond the schema, though it does not introduce new parameters or change the baseline 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 uses a specific verb ('Delete') and clearly identifies the resource ('one entry from the global block list') and its consequence ('re-enabling outreach to that domain or address'). It also distinguishes itself from sibling tools like smartlead_get_domain_block_list and smartlead_add_domain_to_block_list by specifying the exact destructive action.

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

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

The description explicitly states a prerequisite action ('Call smartlead_get_domain_block_list first to confirm which entry the ID refers to') and required configuration (unrestricted mode, SMARTLEAD_MCP_ALLOW_DESTRUCTIVE=true, confirm_destructive: true). It leaves no ambiguity about when and how to invoke this tool, including the need for explicit confirmation.

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 goes well beyond the annotations by specifying exact safety traits: no read-only, may consume credits, modifies remote state, can send email, destructive. It also discloses the endpoint, mentions the permanent nature of STOPPED, and clarifies the 'START' vs 'ACTIVE' naming. This provides deeper behavioral context than the annotations alone.

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

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

The description is dense but well-structured, with each line serving a distinct purpose: action summary, safety flags, endpoint, per-status behavior, and naming clarification. For a tool with destructive and email-sending implications, the length is justified and every sentence earns its place.

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

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

The description covers the essential operational context: endpoint, safety profile, per-status requirements, and the non-standard 'START' value. Since an output schema exists, return value details are not needed. This is complete for a complex, mutating tool.

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

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

Schema coverage is 100%, so all four parameters (status, campaign_id, confirm_send, confirm_destructive) are already fully described in the schema. The description adds minimal additional parameter semantics beyond repeating the enum values and confirm requirements, which are already documented in the schema's property descriptions.

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

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

The description opens with a specific verb phrase 'Start, pause or stop a campaign', clearly identifying the action (update status) and resource (campaign). It distinguishes itself from sibling tools like smartlead_list_campaigns or smartlead_get_campaign by focusing on status changes, not retrieval or creation.

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 on when each status is appropriate: PAUSED is an ordinary mutation, START requires unrestricted mode and confirm_send, STOPPED is permanent and requires confirm_destructive. It effectively explains prerequisites and exclusions, though it does not explicitly name alternative tools or state 'use this when...'.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical non-obvious behaviors: credit consumption, remote state modification, email sending capability (no), credit preflight check with rejection (never silent reduction), and no automatic retries. The safety breakdown explicitly echoes and expands on the annotations without contradiction.

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

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

The description is structured into clear sections: purpose, credit warning, safety breakdown, endpoint, parameter constraints, and behavioral guarantees. Each sentence adds meaningful information, though the safety breakdown somewhat restates what the annotations and title already convey. Still, it remains focused and front-loaded.

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

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

For a credit-consuming mutation tool with 7 parameters and an output schema, the description is exceptionally complete. It covers the endpoint, authentication requirement, prerequisites, parameter relationships, credit preflight behavior, and error handling (rejects rather than reduces). The presence of an output schema means return value details are not required, and the description fills all other gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by emphasizing the mutual exclusivity of 'id' and 'limit' (also in schema) and by clarifying the documented limit range (1-10000, up to 30000 on some accounts), which goes beyond the schema's simple min/max. It also highlights the need for confirm_credit_spend=true, reinforcing the schema's description.

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

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

The description states a specific action ('Reveal contact email addresses') on a specific resource ('a saved filter'), with two distinct modes ('explicit adapt IDs' or 'bounded limit'). This clearly distinguishes it from sibling tools like smartprospect_search_contacts (search) and smartprospect_get_contacts (likely retrieving already fetched contacts).

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 for a saved filter and provides clear prerequisites (SMARTLEAD_MCP_ALLOW_CREDIT_SPEND=true, confirm_credit_spend=true) and a mutual exclusion rule (id vs limit). However, it does not explicitly state when to prefer this tool over related tools like smartprospect_get_contacts or smartprospect_find_emails, nor does it provide 'when not to use' guidance.

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

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

Annotations indicate non-read-only and non-destructive, but the description adds critical context: consumes credits, creates/modifies remote state, maximum 10 contacts, never retried automatically to avoid double charging, and the endpoint. This goes well beyond the structured 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?

Every sentence serves a purpose: purpose, safety, endpoint, limits, prerequisites, retry policy, and credit-check reminder. The structure front-loads the core function and uses a compact safety summary line, making it efficient and easy to scan.

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

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

Although an output schema exists, this tool has unusual complexity (credit spending, env var requirement, non-read-only behavior). The description covers usage limits, prerequisites, safety, retry policy, and points to a sibling tool for credit balance, leaving no critical gaps for agent invocation.

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

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

Schema covers all three parameters at 100% coverage, but the description adds operational semantics: the 10-contact limit, the mandatory firstName/lastName/companyDomain trio, and the environment variable gate for confirm_credit_spend. It reinforces the critical flag without duplicating schema text.

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

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

The description clearly states the tool's purpose: 'Look up email addresses for up to 10 named contacts at their company domains.' This is a specific verb+resource+scope that differentiates it from sibling tools focused on broader searches or 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 preconditions: requires SMARTLEAD_MCP_ALLOW_CREDIT_SPEND=true and confirm_credit_spend: true, and advises checking smartprospect_get_search_analytics first for credit balance. It doesn't contrast with search_contacts alternatives, but clearly states when the call will be refused locally.

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

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

Adds substantial behavioral context beyond annotations: explicitly states it does not consume SmartProspect credits, creates or modifies no remote state, cannot send email, and is destructive: no. This goes beyond readOnlyHint and gives concrete operational 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 compact and well-structured, front-loading the core purpose in the first sentence and then providing safety and usage constraints. Each sentence adds unique information, with only minor redundancy around read-only status.

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 8 parameters, full schema descriptions, and an output schema, the description covers all essential aspects: purpose, safety profile, endpoint, parameter selection rules, and scoping of filters. No critical gaps remain 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 coverage is 100% with descriptions, so baseline is 3. The description adds extra value by centralizing the mutual exclusivity rule and specifying that limit, offset, search, verification_status, and catch_all_status apply only when using filter_id, which is not fully apparent from individual parameter descriptions.

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 retrieves already-saved or fetched contacts, using a specific verb ('Retrieve') and resource ('contacts'). It distinguishes from siblings like smartprospect_fetch_contacts by explicitly noting these are already paid for and no credits are spent.

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

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

Provides clear context: use this for already-fetched contacts without spending credits and states the constraint to provide exactly one of id or filter_id. It does not explicitly name alternative tools for when-not-to-use, but the 'already fetched' phrasing and credit-saving implication serve as implicit guidance.

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

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

Adds explicit safety details (credits, remote state, email, destructive) and endpoint beyond the readOnlyHint annotation.

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

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

Three concise sentences front-loaded with purpose, followed by essential safety and endpoint info.

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?

Fully sufficient: purpose, safety, endpoint, and output schema covers return values.

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?

No parameters to document; baseline 4 for zero-param tool.

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

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

States it returns reply counts for current and previous month with trend, using specific verb 'Return' and resource 'reply counts', distinguishing from sibling analytics 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?

Clear purpose implies when to use, but does not explicitly contrast with alternatives like smartprospect_get_search_analytics.

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

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

The description adds safety declarations beyond annotations, notably 'may consume SmartProspect credits: no' and 'free and read-only,' which are not in the annotations. It also discloses the endpoint. No contradictions with the readOnlyHint and destructiveHint 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 main purpose and organized logically. The safety line is somewhat redundant with annotations but adds credit-consumption context; otherwise, each sentence serves a purpose.

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

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

Given the simple one-parameter tool with output schema and rich annotations, the description covers purpose, usage timing, safety, and the optional parameter effectively. The 'before any credit-consuming call' guidance completes the contextual picture.

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

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

The schema already describes filter_id, but the description adds that passing it yields per-filter metrics in addition to aggregate figures, clarifying the default behavior. This subtle enrichment goes beyond the schema's basic description.

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

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

The description clearly states the tool returns SmartProspect credit balance, limits, and leads found/emails fetched metrics. It uses a specific verb ('Return') and names the resource and scope, distinguishing it from sibling tools like get_reply_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 explicitly advises reading this tool before any credit-consuming call, establishing a clear use case. It does not explicitly list alternatives or when-not-to-use, but the context of a free, read-only pre-flight check is evident.

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 goes well beyond the annotations by explicitly enumerating safety properties: read-only, no credit consumption, no remote state changes, no email, not destructive. It also discloses that it does not reveal contacts and includes a specific behavioral note about the country/state filter requirement. This is excellent context beyond the structured 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 reasonably concise and front-loaded with the core purpose. Every sentence adds value (purpose, safety, endpoint, reference data, dependency note), though the safety line and reference data sentence slightly overlap on the 'no credits' point, making it a touch redundant.

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

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

Given the tool is a simple reference-data listing with an output schema available, the description provides all needed context: purpose, endpoint, safety profile, and a known filter constraint. The output schema covers return values, so the absence of further return details is not a gap.

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

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

Schema description coverage is 100%, so the baseline is 3; each parameter already has a clear description. The description adds no new parameter details, only repeating the country requires state note already present in the schema. This does not elevate above baseline.

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 exactly what the tool does: 'List city values available as SmartProspect search filters.' This is a specific verb + resource, and the 'cities' focus clearly distinguishes it from sibling list tools (states, countries, departments, etc.). The endpoint is also provided for additional clarity.

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 context by noting this is 'Reference data only' and 'Does not reveal contacts and does not consume credits,' implying it should be used for filter dropdowns rather than contact discovery. It also mentions the country/state dependency. However, it doesn't explicitly contrast with sibling alternatives (e.g., 'use list_states for states') or state when not to use it.

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?

An enumeration of safety properties is provided: read-only, no credit consumption, no state modification, no email sending, no destructive behavior. It also adds the exact endpoint and clarifies that it does not reveal contacts, going well beyond the annotation hints and giving the agent confidence in side-effect-free use.

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

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

The description is compact and front-loaded with the purpose. Every line adds value: purpose, safety details, endpoint, and reference-data clarification. 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?

This is a low-complexity list operation with a high-quality schema, an output schema present, and clear safety/endpoint disclosure. The description sufficiently covers what the tool does, its constraints, and its non-contacting scope, making it complete for agent decision-making.

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

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

The input schema already documents all three parameters with complete descriptions (100% coverage). The tool description adds no extra information about limit, offset, or search semantics, so it earns the baseline score for schema-covered 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 opens with a clear verb+resource statement: 'List company names available as SmartProspect search filters.' It also distinguishes from sibling contact-search tools by noting 'Does not reveal contacts,' making its 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 implies the use case (retrieving reference data for filter options) and explicitly states 'Reference data only,' which excludes contact discovery. However, it does not name specific alternative tools or when-not-to-use conditions, so it stops short of full explicit guidance.

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

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

Beyond the annotations (readOnlyHint, destructiveHint, openWorldHint), the description explicitly enumerates safety properties: no credit consumption, no remote state changes, no email, no destructive actions. It also provides the exact endpoint and clarifies that the tool returns reference data only, which exceeds annotation coverage.

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

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

The description is three sentences: the first clearly states the purpose, the second provides a structured safety summary, and the third reinforces the reference-only nature. Every sentence adds distinct value without repetition or fluff.

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

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

For a simple reference-data listing tool with an output schema present, the description covers purpose, safety, endpoint, and usage context. It fully addresses the tool's function and constraints, making it complete for an AI agent to decide when and how to invoke it.

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

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

Schema coverage is 100% with detailed descriptions for limit, offset, and search. The description adds no additional parameter-specific meaning; it only frames them as search filters. Baseline 3 is appropriate since the schema carries the explanatory burden.

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

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

The description starts with 'List country values available as SmartProspect search filters,' which is a specific verb+resource statement. It clearly identifies the tool as a reference data listing for countries and distinguishes it from sibling list tools (states, cities, industries, etc.).

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

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

The description states the tool lists country values for use as search filters, implying when to use it. It adds 'Reference data only' and 'Does not reveal contacts,' which clarifies it is not for lead retrieval. However, it does not explicitly name alternative tools or state when not to use it, so it misses the top 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?

Beyond the annotations (readOnlyHint, destructiveHint), the description explicitly discloses that it consumes no SmartProspect credits, sends no email, creates/modifies no remote state, and does not reveal contacts. This provides concrete safety and side-effect context that annotations alone don't cover, with no contradictions.

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

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

The description is compact and front-loaded, leading with the core purpose, followed by safety assertions, endpoint, and a concise note about reference data. Every sentence adds useful information with no redundancy.

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

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

Given the low complexity of a reference-data list tool, the description fully covers what an agent needs: purpose, safety profile, endpoint, and the fact that it neither reveals contacts nor consumes credits. The output schema is present, so return-value details are handled externally.

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 covers all three parameters (limit, offset, search) with detailed descriptions, so schema coverage is 100%. The description adds no additional parameter-specific semantics, so baseline 3 is appropriate per the rubric.

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

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

The description states a specific action and resource: 'List department values available as SmartProspect search filters.' This clearly distinguishes it from sibling reference-data tools like list_countries or list_industries. The endpoint is also provided for additional clarity.

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 stating these are 'search filters' and 'Reference data only,' making it clear this is for retrieving filter options. However, it doesn't explicitly mention when to prefer this tool over other list_* tools or search_contacts, though the name and purpose make this fairly evident.

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

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

Beyond annotations, the description details specific safety traits: 'read-only: yes; may consume SmartProspect credits: no; creates or modifies remote state: no; can send email: no; destructive: no.' It also states 'Does not reveal contacts' and includes the endpoint, adding valuable behavioral context. 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 concise and front-loaded with the primary purpose. The safety and endpoint details are provided in compact, structured lines. The slight repetition of 'does not consume credits' is minor and does not detract from overall 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?

The tool is simple, has an output schema, and the description covers purpose, safety, endpoint, and reference-data nature. It does not need to explain return values given the output schema. The description is sufficiently complete for an AI agent to select and invoke this tool correctly.

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

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

The input schema has 100% description coverage, so all three parameters (limit, offset, search) are already documented with defaults and ranges. The tool description adds no additional parameter semantics beyond what the schema provides, aligning with the baseline of 3.

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

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

The description opens with 'List company domains available as SmartProspect search filters,' which is a specific verb+resource statement. It clearly distinguishes from sibling list tools by targeting company domains, not countries, states, or other filter types. The title reinforces this.

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 statement 'available as SmartProspect search filters' provides clear context for when to use the tool: to obtain domain options for building search filters. 'Reference data only' adds context that this is not for contact retrieval. However, it does not explicitly name alternatives or state when not to use it, stopping short of a 5.

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

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

Beyond annotations (readOnlyHint, destructiveHint), the description adds critical safety context: no SmartProspect credit consumption, no remote state modification, no email sending, and the fact that contacts were already paid for. This provides a complete safety profile without requiring the agent to infer from annotations alone.

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

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

The description is somewhat verbose with repetitive safety statements, but each sentence adds unique value (purpose, safety, endpoint, alternative). It is well-structured and easy to scan, though it could be tightened without losing meaning.

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

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

The tool is fully contextualized: purpose, safety, endpoint, relation to paid contacts, and the recommended companion tool for retrieval. An output schema exists, so return-value details are not needed in the description.

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

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

Schema coverage is 100% with clear descriptions for both limit and offset. The description does not add parameter-specific semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description specifies the exact resource ('searches whose contacts have already been fetched') and includes per-filter fetch metrics, clearly distinguishing it from sibling tools like list_saved_searches and list_recent_searches. The verb 'List' is concrete and actionable.

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

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

Explicit guidance is given: 'Contacts listed here were already paid for; retrieve them with smartprospect_get_contacts rather than fetching again.' This tells the agent when to use this tool versus alternatives, and also states the tool is free and read-only.

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

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

Annotations already declare readOnlyHint and destructiveHint, but the description adds valuable behavioral context: 'may consume SmartProspect credits: no', 'creates or modifies remote state: no', 'can send email: no', and 'Does not reveal contacts.' This goes beyond the binary hints and clarifies cost and data exposure.

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

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

The description is compact (about 80 words) and front-loaded with purpose, followed by a structured safety summary and endpoint. Every sentence adds information; the safety bullet duplicates some annotation hints but includes credit and contact exposure details not present in annotations, making it justified.

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

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

For a simple reference-data listing tool with a full output schema and 100% parameter coverage, the description provides all necessary context: what it lists, that it's read-only and free, that it does not reveal contacts, and the exact endpoint. No critical gaps.

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

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

Schema coverage is 100% with clear descriptions for limit, offset, and search. The description does not add further parameter semantics, so the baseline of 3 applies. It correctly implies these are list-pagination/filter parameters but without additional detail.

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

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

The description opens with a specific verb and resource: 'List company head count (size) ranges available as SmartProspect search filters.' This clearly distinguishes it from sibling list tools (countries, industries, etc.) by naming the exact resource (head count ranges) and its role as search filter values.

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

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

The phrase 'available as SmartProspect search filters' provides clear context for when this tool is useful (populating filter options). It does not explicitly exclude alternatives or state when not to use it, but the purpose is self-evident and the description adds 'Reference data only' to set expectations.

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

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

Annotations already declare read-only and non-destructive, but the description adds critical context: no credit consumption, no contact exposure, and the exact endpoint. These are meaningful beyond the structured fields, fully disclosing side effects.

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

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

The description is three compact sentences, each carrying substantive value: purpose, safety profile, and reference-only nature. No fluff or redundant 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?

With an output schema present, the tool's return value is fully documented. The description covers purpose, safety, endpoint, and usage context, making it complete for this simple read-only list 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 provides 100% parameter descriptions, so the description does not need to compensate. The baseline of 3 applies as the description adds no additional parameter-level meaning beyond the schema.

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

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

The description clearly states the tool's function: to list industry values used as SmartProspect search filters. It is specific and distinguishes this tool from sibling list tools (e.g., countries, states, sub-industries).

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 indicates the tool's role as a reference for search filters and explicitly states it does not reveal contacts or consume credits, which helps set context. However, it does not explicitly mention when to prefer this over alternatives such as list_sub_industries.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes further by stating 'may consume SmartProspect credits: no', 'creates or modifies remote state: no', 'can send email: no', and 'does not reveal contacts'. This adds valuable context beyond annotations and includes the endpoint for clarity.

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

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

The description is compact: a one-sentence purpose, a structured safety block, and an endpoint. Every sentence provides useful information without redundancy.

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

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

For a simple reference-data list tool with an output schema, the description covers purpose, safety, endpoint, and explicitly clarifies that it does not expose contacts or consume credits. This is complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the schema fully documents limit, offset, and search. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description starts with 'List job title values available as SmartProspect search filters' – a specific verb and resource that clearly distinguishes this from sibling list_* tools (countries, states, cities, etc.). It also notes 'Reference data only. Does not reveal contacts', differentiating it from contact-related 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: this returns reference data for SmartProspect search filters and explicitly states it does not reveal contacts or consume credits. This implies when to use it (needing filter values) and when not (needing contacts), though it doesn't name alternative tools explicitly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds concrete safety details: no SmartProspect credit consumption, no remote state modification, no email, and no contact revelation. It also provides the exact endpoint, offering transparency beyond the structured annotations.

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

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

Three concise, front-loaded sentences: purpose, safety, and endpoint/note. Every sentence contributes value with no redundancy or fluff.

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

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

For a simple read-only reference tool with an output schema and fully described parameters, the description covers purpose, safety, endpoint, credit implications, and contact privacy. Nothing relevant is missing.

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

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

Input schema has 100% description coverage for all three parameters (limit, offset, search), including constraints and defaults. The description adds no additional parameter-level semantics, so the baseline of 3 applies — the schema carries the parameter 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 tool lists 'company keyword values available as SmartProspect search filters' — a specific verb and resource. It explicitly notes it is reference data and does not reveal contacts, distinguishing it from sibling contact-search 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 implies usage: retrieving filter options for SmartProspect searches. It clarifies it is reference-only and does not reveal contacts, which helps the agent avoid using it for contact discovery. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds safety clarifications beyond annotations: 'may consume SmartProspect credits: no; creates or modifies remote state: no; can send email: no; destructive: no,' plus the endpoint. 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 three sentences, front-loaded with the purpose. The safety block and endpoint are useful, but 'read-only' appears twice ('read-only: yes' and 'Free and read-only'), creating slight redundancy. Overall, it is concise 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?

For a simple read-only list tool with an output schema present and annotations covering safety, the description is complete. It correctly does not need to explain return values or pagination in detail, as the schema already documents limit and offset.

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 covers 100% of parameters (limit and offset) with detailed descriptions including defaults and bounds. The description adds no parameter-specific meaning, but the schema fully documents the parameters, so baseline 3 applies.

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

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

The description opens with 'List recently executed SmartProspect searches with their filter details,' which clearly identifies the action and scope. It differentiates from sibling list tools like list_saved_searches and list_fetched_searches by focusing on 'recently executed' searches.

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

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

The description does not explicitly specify when to use this tool versus alternatives such as list_saved_searches or list_fetched_searches. The use case of browsing recent search history is implied by 'recently executed,' but no explicit guidance, exclusions, or alternative mentions are provided.

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

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

Beyond the annotations, the description reveals that the tool does not reveal contacts, does not consume SmartProspect credits, and takes no pagination parameters (meaning returns all data at once). It also provides the endpoint URL, adding useful behavioral context.

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

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

The description is concise and front-loaded: the first sentence states the purpose, followed by safety, endpoint, reference nature, and pagination. Each sentence earns its place with no redundant information.

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

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

For a simple zero-parameter reference-data list tool, the description covers purpose, safety, credit consumption, contact privacy, and pagination. An output schema exists, so detailed return format is not needed in the description.

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

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

The tool takes zero parameters, and the input schema confirms this. The description adds that the endpoint takes no pagination parameters, which aligns with the schema. Per baseline for 0 params, a score of 4 is appropriate.

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

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

The description clearly states 'List company revenue range values available as SmartProspect search filters' with a specific verb and resource. It distinguishes from sibling list tools by specifying the exact data type (revenue ranges) and their role as search filters.

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

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

The phrase 'available as SmartProspect search filters' provides clear context for when to use this tool (when needing reference values for filters). However, it does not explicitly name alternatives or mention when not to use it, so it stops short of a 5.

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

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

The description goes beyond the annotations by explicitly enumerating safety properties: 'read-only: yes; may consume SmartProspect credits: no; creates or modifies remote state: no; can send email: no; destructive: no.' This provides detailed behavioral transparency, including credit consumption and email capabilities, which annotations alone do not convey.

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

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

The description is efficiently structured: a clear opening sentence, a compact safety block, the endpoint, and a practical usage tip. Every sentence adds value, and the main purpose is front-loaded, making it easy for the agent to quickly grasp the tool's function.

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 low complexity (two optional parameters), presence of an output schema, and annotations covering safety, the description is complete. It adds the endpoint URL and the crucial cross-tool hint about using the returned `id` as a `filter_id`, covering all necessary operational context.

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

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

The input schema covers 100% of parameters with descriptions for both limit and offset, including bounds and client-side guard rationale. The description does not add extra parameter-level detail, but it doesn't need to because the schema already provides sufficient semantics. The baseline of 3 applies.

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

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

The description clearly states the verb 'list', the resource 'saved searches', and adds 'with their stored filter details' to specify the returned information. This distinguishes it from sibling tools like list_recent_searches and list_fetched_searches, which focus on different types of searches.

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

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

The description provides clear usage context by stating 'Use the returned `id` as a `filter_id` elsewhere', which tells the agent how to leverage the output. It also notes 'Free and read-only', implying safe to call, but does not explicitly name alternatives or exclusions relative to sibling list tools.

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

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

Annotations already declare readOnlyHint and destructiveHint, and the description adds concrete details: 'does not consume credits,' 'creates or modifies remote state: no,' 'can send email: no,' and the endpoint URL. This goes beyond annotation basics, clarifying credit usage and remote effects.

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

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

The description is compact, with the main purpose in the first sentence, followed by a structured safety summary and endpoint. Every sentence provides distinct value, and the formatting is clean and scannable.

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

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

For a simple reference-list tool with an output schema, the description covers purpose, safety profile, endpoint, and credit consumption. It does not need to explain return values because the output schema exists, and the low complexity means no missing behavioral constraints.

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

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

Schema description coverage is 100%, so the parameters (limit, offset, search) are fully documented in the schema. The description adds no further semantic detail about how these parameters affect the list, so the baseline score of 3 is appropriate.

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

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

The description states 'List seniority level values available as SmartProspect search filters,' which clearly identifies the verb (list), resource (seniority levels), and scope (search filters). This distinguishes it from sibling list tools like list_countries or list_departments.

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: 'Reference data only. Does not reveal contacts and does not consume credits.' This implies it is for retrieving filter values, not contact data. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide when to use it.

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 goes beyond annotations by explicitly stating no credits are consumed, no remote state is modified, no email is sent, and no contacts are revealed. It also provides the exact endpoint. These details enrich the annotation-provided readOnlyHint=true and destructiveHint=false without contradiction.

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

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

The description is well-organized: one-sentence purpose, a structured safety profile, endpoint, and a reference-data caveat. Each sentence earns its place, though the safety list is somewhat redundant with annotations, keeping it from a perfect 5.

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

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

This is a simple read-only list tool. The description covers purpose, safety, endpoint, and the nature of the data, while the input schema fully documents parameters and an output schema exists. No significant gaps remain for an agent using it.

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

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

Input schema has 100% parameter description coverage, so the baseline is 3. The description does not add additional parameter-specific semantics beyond noting the tool provides filter values; it neither clarifies formats nor adds usage constraints beyond what the schema already documents.

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 'List state/region values available as SmartProspect search filters,' specifying a specific verb and resource. This distinguishes it from sibling list tools like list_countries or list_cities by naming the exact type of value (state/region) and its purpose (search filters).

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

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

The description implies the tool is for retrieving reference data to use in SmartProspect search filters and explicitly notes it does not reveal contacts. It provides clear context, but does not explicitly name alternative tools or state when not to use it, so it falls short of a perfect 5.

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

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

The description provides substantial behavioral context beyond the annotations: it includes an explicit safety block (read-only, no credit consumption, no state changes, no email), the REST endpoint, and states it 'Does not reveal contacts and does not consume credits.' This goes well beyond the basic readOnlyHint and destructiveHint annotations.

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

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

The description is four concise sentences that front-load the core purpose, then efficiently covers safety, endpoint, and key behavioral notes. Every sentence serves a clear function with no redundant or filler content.

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, the presence of an output schema, and complete parameter documentation, the description is fully adequate. It covers purpose, safety, endpoint, and important limitations (reference data only, no credits), leaving no significant gaps for an agent to invoke it correctly.

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

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

With 100% schema description coverage, every parameter already has detailed descriptions. The tool description doesn't add parameter-specific meaning but provides overall context about the data being listable. This meets the baseline of 3 for high 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?

Description clearly states the tool 'List[s] sub-industry values available as SmartProspect search filters' using a specific verb and resource. This distinguishes it from sibling list tools like list_industries and list_countries by focusing on sub-industries as reference data.

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 stating these are 'available as SmartProspect search filters' and 'Reference data only,' which communicates that the tool is for retrieving filter options. It doesn't explicitly name alternatives or exclusions, but the purpose is clear enough within the sibling group.

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 explicitly discloses that this modifies remote state (matching readOnlyHint=false), does not consume credits, and is blocked in readonly mode—valuable context beyond the annotations. It also clarifies it is not destructive, consistent with destructiveHint=false.

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?

All sentences carry useful information: purpose, safety profile, endpoint, and readonly restriction. No fluff 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?

The description gives purpose, safety, endpoint, and a hint of return values while an output schema exists. It provides enough context for an agent to select and invoke correctly.

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

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

Schema coverage is 100% and the filter_id parameter is already clearly described in the schema. The tool description mentions the filter context but adds no extra parameter meaning, so the baseline 3 applies.

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

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

The description states a specific action ('Re-sync contact metrics and statuses') on a specific resource ('contacts for a SmartProspect filter') and notes the returned counts. This clearly distinguishes it from sibling tools that search, fetch, or list contacts.

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 this is for re-syncing a filter's contacts but does not explicitly state when to prefer it over alternatives like search_contacts or fetch_contacts, nor does it describe exclusions beyond being blocked in readonly mode.

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 explicitly discloses safety-relevant behaviors beyond the annotations: it creates remote state, does not consume SmartProspect credits, cannot send email, is not destructive, and is blocked in readonly mode. It also provides the exact endpoint. This is highly transparent and goes well beyond the readOnlyHint/destructiveHint flags.

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

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

The description is compact and well-structured, but there is some redundancy: the safety line states 'creates or modifies remote state: yes' and 'may consume SmartProspect credits: no,' and the next sentence repeats 'Creates remote state' and 'does not consume credits.' This duplication prevents a perfect conciseness score.

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

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

For a tool with 28 parameters, the schema fully documents the parameters and the output schema exists. The description covers the key operational context: side effects, credit consumption, readonly behavior, and the endpoint. It does not explain the relationship to list/update saved searches, but this is not essential for invocation and sibling tool names provide that context.

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

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

The input schema has 100% description coverage for all 28 parameters, including clear descriptions of each filter field and the required search_string. The description adds little beyond the word 'named,' so the schema carries the parameter semantics. The baseline of 3 applies because no compensation is needed.

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

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

The description starts with a clear action: 'Save a named SmartProspect search filter for later reuse.' This uses a specific verb and resource, and it distinguishes the tool from sibling tools like smartprospect_search_contacts (which runs a search) and smartprospect_update_saved_search (which modifies an existing filter).

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 practical usage context: it states the tool only saves the filter, 'Does not run the search and does not consume credits,' and is 'Blocked in readonly mode.' This helps an agent choose when to use it, though it does not explicitly name alternatives or exclusions relative to sibling tools.

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