Mailcannon

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and fields, but does not explain whether the step is appended, what validation occurs, authentication requirements, or what the response looks like. For a mutating tool this is a significant gap.

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

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

The description is a single concise sentence that is easy to parse and front-loads the core action. However, it is slightly under-specified and could have used a few more words to clarify the campaign relationship without losing efficiency.

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

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

Given there are no annotations and no output schema, the description should explain more about the operation's context, prerequisites, and effects. It omits critical information such as needing an existing campaign, step ordering, and return values, making it incomplete for reliable tool invocation.

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

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

Schema description coverage is only 25%, and the description adds minimal clarification beyond the schema (e.g., 'delay in hours' restates the schema's day description). The campaignId parameter is completely unexplained, and subject/body formats are not elaborated. The description does not compensate for the schema's sparse parameter documentation.

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 ('Add') and identifies the resource ('a sequence step'), with a parenthetical listing the key fields (delay in hours, subject, body). This distinguishes it from update/delete siblings, though it does not explicitly mention the campaign context or how it differs from other add 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?

No guidance is provided on when to use this tool versus alternatives like update_campaign_step or delete_campaign_step. The only implicit signal is the verb 'Add,' which is not sufficient for an agent to choose this tool confidently.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It merely says 'add', providing no information about side effects, idempotency, duplicate handling, permissions, or response format. The description adds almost nothing beyond the tool name.

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

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

The description is a single short phrase, but it is under-specified rather than effectively concise. It fails to include essential context, making the brevity a deficiency rather than a strength.

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

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

Given the tool has six parameters, two required, no annotations, no output schema, and no parameter descriptions, a one-sentence description is grossly inadequate. It does not explain what a 'contact' entails, how tags are used, or what the response will be, making it impossible for an agent to invoke correctly with confidence.

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

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

Schema description coverage is 0%, and the description does not mention any of the six parameters. It does not even clarify that email and firstName are required or explain the purpose of tags, company, title, or lastName, leaving the agent with no compensatory semantics.

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

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

The description clearly states the action with a specific verb ('Add') and object ('a single contact'), distinguishing it from the sibling tool 'add_contacts' by emphasizing 'single'. This makes the purpose unambiguous and differentiates from other add 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?

No guidance is provided on when to use this tool versus 'add_contacts' or other add tools. There is no mention of prerequisites, limitations, or preferred use cases, leaving the agent without contextual decision support.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions the bulk nature and 100-item limit, but omits critical information such as authentication requirements, idempotency, duplicate handling, or failure behavior. For a write operation, this is insufficient.

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

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

The description is a single, front-loaded sentence 'Bulk add contacts (max 100)' with no wasted words. It delivers the essential scope and limit efficiently.

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

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

For a bulk operation with nested object fields, no output schema, and no annotations, the description is too sparse. It does not explain how to format contacts, what happens if the limit is exceeded, or what the response contains. This leaves critical gaps for an agent attempting to invoke the tool correctly.

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

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

Schema description coverage is 0%, and the description adds no explanation of the 'contacts' parameter structure or field meanings beyond what the schema property names already show. The description fails to compensate for the lack of schema descriptions, leaving the agent to infer semantics from names like 'title' and 'company'.

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 'Bulk add contacts (max 100)' clearly specifies the action (add) and resource (contacts). It distinguishes itself from the sibling 'add_contact' by explicitly indicating a bulk operation, making the purpose unambiguous.

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

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

The description implies usage for adding multiple contacts with a maximum batch size of 100. However, it does not explicitly state when to prefer this tool over 'add_contact' or mention any exclusions or alternative tools. Still, the bulk context provides clear usage direction.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It only states the basic add action and gives no information about side effects, permissions, idempotency, or potential overwriting of existing providers.

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

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

The description is a single sentence with no fluff, but it is under-specified for a tool with 7 parameters. This is more under-specification than appropriate conciseness, as no detail is provided to support invocation.

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 absence of annotations, output schema, and any schema descriptions, the one-sentence description is completely inadequate. It does not explain parameters, return values, or behavioral context, leaving a 7-parameter tool nearly unusable.

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

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

Schema description coverage is 0%, and the description adds no meaning for any of the 7 parameters. The enums for 'kind' and 'transport' are not explained, and the roles of 'name', 'url', 'command', 'args', and 'env' are entirely opaque.

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') and the resource ('email provider'), which distinguishes it from sibling tools like remove_provider and list_providers. It is specific about the tool's core function, though it does not elaborate on scope.

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

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Usage is only implied by the tool name and sibling context, which is insufficient.

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It identifies the specific records checked but does not disclose whether the tool performs a live DNS lookup, returns a simple pass/fail, or provides detailed output. It does not explicitly state read-only behavior, though it is implied by 'check'.

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

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

A single, concise sentence that communicates the core function without redundant words or filler. It is well-front-loaded and easy to parse.

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

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

For a simple one-parameter tool, the description is adequate but leaves gaps: no mention of output format (e.g., boolean vs. detailed report), no context on when to choose this over get_deliverability, and no note on potential failure modes. Lacking an output schema, some of this information would be helpful.

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 the domain parameter with an example (100% coverage), so the baseline is 3. The description adds value by specifying exactly which DNS records (SPF, DKIM, DMARC) are evaluated, giving the domain parameter more operational meaning.

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

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

The description clearly states the tool checks SPF, DKIM, and DMARC records for a domain, using a specific verb and resource. It does not explicitly differentiate from sibling tools like get_deliverability or check_email_spam_score, but the specific mention of the three record types gives enough 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?

Usage is implied: this tool is for verifying email authentication records for a domain. However, there is no explicit when-to-use vs. alternatives guidance, particularly compared to get_deliverability, which might be a similar or higher-level tool.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. 'Analyze' implies a read-only operation, but it does not disclose return format, side effects, permissions, or whether data is sent externally. This is a minimal disclosure similar to the update_drive example.

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

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

The description is a single, front-loaded sentence with no redundant words. Every word contributes to the purpose, making it appropriately 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 tool with two string parameters and no output schema, the description states the core function but omits return value expectations and any prerequisites. It is adequate as a minimal viable description, but the missing output information leaves a clear gap given the absence of an output schema.

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

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

Schema description coverage is 0%, and the description only repeats the parameter names ('subject/body') without adding details about formats, constraints, or how each parameter is used. It adds some value by indicating both are analyzed together, but it fails to compensate for the missing schema 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 uses a specific verb ('Analyze') and clearly identifies the resource ('email subject/body') and purpose ('spam trigger words'). It distinguishes from sibling tools like 'check_domain_deliverability' (domain-focused) and 'check_step_spam_score' (likely step-based), 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 clearly implies usage: when you have raw email subject and body and want to check for spam triggers. However, it does not explicitly name alternatives or state when not to use this tool versus 'check_step_spam_score'. This is clear context without exclusions, so a score of 4 fits.

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

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

With no annotations, the description must disclose behavioral traits itself. It only says 'check', which implies read-only but doesn't confirm it, nor does it describe the output format, possible side effects, or any limitations. Minimal behavioral context is provided.

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

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

The description is a single sentence with no redundant information. It is front-loaded with the action verb 'Check' and clearly states the subject. Perfectly concise.

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 one parameter, no annotations, and no output schema, the description is too sparse. It fails to describe what the result looks like (e.g., a spam score, a list of triggers), what the agent should do with the output, or any prerequisites. This incompleteness could hinder correct tool usage.

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

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

The schema has only 'stepId' with no description (0% coverage), so the description must add meaning. It clarifies that 'stepId' refers to a campaign step and that the check covers subject/body, providing some context. However, it doesn't explicitly state that the stepId is the identifier to be used for the check, leaving a small inference gap.

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

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

The description clearly states the tool's function: 'Check a campaign step's subject and body for spam triggers.' It specifies the exact resource (campaign step) and the specific aspects to be checked (subject and body), distinguishing it from siblings like check_email_spam_score and check_domain_deliverability.

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 campaign steps, but it does not explicitly mention alternatives or when to prefer this tool over check_email_spam_score or check_domain_deliverability. No direct 'use this instead of X' guidance is provided.

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

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

No annotations are provided, so the description must disclose side effects or return behavior. It only repeats the tool's function; doesn't state whether the campaign is created as draft, requires subsequent steps, or what is returned.

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

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

A single, concise sentence with no redundancy. It is front-loaded and contains no extraneous detail.

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

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

For a create tool with minimal parameters, the description conveys the basic action but lacks context about post-creation steps, return values, or initial state. Sibling tools suggest a workflow that is not referenced, leaving the agent without guidance on what happens after creation.

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

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

The only parameter 'name' is not described in the schema, and the description doesn't explicitly mention it. With 0% schema description coverage, the description fails to compensate, leaving the agent to infer the parameter's meaning from its name alone.

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 'Create a new email campaign' uses a specific verb ('create') and resource ('email campaign'), clearly distinguishing it from sibling tools like update_campaign or delete_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?

No guidance on when to use vs alternatives; no mention of campaign lifecycle, prerequisites, or exclusions. The intended use is merely implied by the name and provides no context for choosing between this and related 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?

With no annotations, the description carries full responsibility for behavioral disclosure. 'Create a new task' only restates the action; it does not mention side effects, authentication needs, response format, or potential risks, which is a significant gap for a mutation tool.

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

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

The description is a single, direct sentence with no wasted words. It is perfectly concise and front-loaded, though it sacrifices completeness for brevity.

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 four parameters, no output schema, no annotations, and a rich set of sibling tools, the description is far from complete. It omits return value information, any usage context, and parameter semantics, making it inadequate for confident tool invocation.

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

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

Schema description coverage is only 25%, and the tool description provides no parameter information at all. It fails to compensate for the low schema coverage, leaving title, priority, and description parameters entirely unexplained beyond basic types and enum values.

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

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

The description 'Create a new task' states a clear verb and resource, unambiguously indicating the tool's function. It does not explicitly distinguish from sibling tools like update_task or delete_task, but the resource and action are distinct enough for basic selection.

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

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

No guidance is provided on when to use this tool versus alternatives such as update_task or list_tasks. The description lacks context about prerequisites, typical scenarios, or exclusions, leaving the agent without decision support.

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

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

With no annotations, the description carries the burden of disclosing behavioral traits. It clearly states that deletion cascades to all steps, which is important. However, it does not mention irreversibility, potential side effects beyond steps, or any permission requirements.

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

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

The description is a single concise sentence that conveys the core purpose without any unnecessary words or repetition. It earns its place with high information density.

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 simplicity of the tool (one parameter, no output schema, no nested objects), the description is largely complete. It captures the essence of the operation and its most important consequence (deleting steps). It could be slightly more complete by mentioning other potential effects, but overall it suffices.

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 no description for the 'id' parameter (0% coverage). The tool name and description make it clear that 'id' refers to the campaign ID, but the description does not explicitly state this or provide any additional formatting/type details beyond the schema's string type.

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 ('Delete') and the resource ('a campaign'), adding the specific scope 'and all its steps', which distinguishes it from delete_campaign_step. This makes the purpose unambiguous.

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

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

The description implies when to use this tool: when you want to delete an entire campaign and its steps, rather than just a single step (which would use delete_campaign_step). However, it does not explicitly state when not to use it or name 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?

With no annotations, the description carries full burden, but it only states 'Delete', a generic destructive verb. It does not disclose permanence, side effects on campaign flow, or error conditions.

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

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

A single, front-loaded sentence conveys the complete action with no redundant words. This is appropriately concise for a simple deletion tool.

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

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

The tool is simple, but with no annotations and no output schema, the description leaves out important context such as whether deletion is permanent, any prerequisites, and parameter details, making it only partially complete.

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

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

There is one required 'id' parameter with 0% schema coverage. The description implies that id identifies the campaign step to delete, adding some meaning beyond the bare schema, but does not specify the id format or scope.

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 the specific verb 'Delete' and identifies the resource 'a step from a campaign', clearly distinguishing it from sibling tools like delete_campaign or update_campaign_step.

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 intended use is implied by the verb and resource—use when removing a step from a campaign—but no explicit alternatives or exclusion criteria 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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the delete action with no mention of irreversibility, cascading effects, permissions, or return behavior. This leaves significant behavioral traits undisclosed for a mutation tool.

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

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

The description is a single, front-loaded sentence with zero filler. Every word 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 tool is simple (1 param, no output schema), but the description does not mention what happens after deletion (e.g., success/failure response, errors, cascades). Given no annotations, the description is minimally viable but leaves clear gaps for a mutation tool.

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

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

The schema has one required string parameter 'id' with no description, and schema description coverage is 0%. The tool description adds minimal context by clarifying the ID is a task ID, but it does not explain format, source, or constraints. The parameter name is self-explanatory, but the description does not compensate beyond that.

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 'Delete a task by ID' uses a specific verb ('Delete') and resource ('task'), and clarifies the mechanism (by ID). It distinguishes itself from siblings like delete_campaign and delete_campaign_step by targeting tasks specifically.

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

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

No explicit guidance is given on when to use this tool versus alternatives. The task-specific wording implies it is for deleting tasks, but there is no mention of when to use delete_campaign or delete_campaign_step, nor any prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden, but it only names the metrics and doesn't disclose behavioral traits like read-only semantics, data scope, time range, or return format. The word 'get' implies a read operation, but the description adds no substantive behavior beyond the tool's name.

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

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

The description is a single sentence with no filler, front-loading the verb and resource, then specifying the key metrics. It is concise and easy to parse, earning a high score for structure.

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

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

Despite its simplicity, the description is under-specified for a tool with no output schema or annotations. It doesn't clarify the scope of the stats (per-campaign, global, date range), the format of the returned data, or how it relates to similar tools like check_domain_deliverability. This leaves significant gaps for an agent trying to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description adds marginal value by listing the metric fields (sent, opens, bounces, replies), which hints at the output structure, but since there are no parameters to explain, it doesn't need to compensate for missing schema details.

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 ('Get') and the resource ('deliverability stats'), with a parenthetical listing the specific metrics (sent, opens, bounces, replies). This makes the tool's function clear and loosely distinguishes it from siblings like check_domain_deliverability, though it doesn't explicitly name alternatives.

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

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

The description provides no guidance on when to use this tool versus sibling tools such as check_domain_deliverability or check_step_spam_score. It lacks any context about typical use cases, prerequisites, or exclusions, leaving the agent to infer when this is the appropriate choice.

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

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

The description conveys that this is a read-only operation ('Get'), which is useful, but it does not disclose behavior for missing keys, default values, response format, or error handling. Without annotations, more detail would be valuable.

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

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

The description is a single, focused sentence with no filler or redundancy. It is front-loaded with the verb and resource, making it easy to grasp quickly.

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

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

For a simple getter with one parameter, the description plus schema is mostly sufficient. It identifies the resource and gives an example, though it omits output format and edge-case behavior, which would improve completeness.

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

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

The schema has one required 'key' parameter with no description, but the example 'timezone' gives meaningful context about what values the key accepts. This compensates for the 0% 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 uses a specific verb ('Get') and resource ('user setting') with a clarifying example ('timezone'). It clearly indicates a single-setting retrieval, though it does not explicitly differentiate from the sibling tool 'list_settings'.

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

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

No guidance is provided for when to use this tool versus alternatives like 'list_settings' or 'set_setting'. The example hints at retrieving a specific setting by key, but there is no explicit context or exclusion criteria.

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

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

With no annotations, the description carries the burden of disclosure. It states the operation lists all campaigns and includes their steps, indicating read-only behavior and output scope, which is adequate for a simple list tool. It does not mention edge cases or failure modes, but none are expected for this straightforward read.

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

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

Single sentence, six words, front-loaded verb and object; every word 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?

Given the tool's simplicity (no params, no output schema), the description is complete: it tells what is returned (campaigns with their steps) and the scope (all). The absence of a return schema is mitigated by the explicit mention of steps.

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 accepts zero parameters, and schema description coverage is 100%, so the baseline is 4. The description correctly adds no param details because none exist.

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 the specific verb 'List' with the resource 'campaigns' and clarifies scope with 'all' and content 'with their steps.' It distinguishes from sibling tools like list_contacts or list_tasks by naming the exact resource and included steps.

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

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

No explicit when-to-use or alternative guidance is provided; the description implies usage simply by naming the list operation. There are no exclusions or comparisons to sibling list tools, so the agent must infer from 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'list all contacts' without mentioning whether the operation is read-only, whether results are paginated, or any potential side effects. A simple list operation would benefit from at least an explicit note that it does not modify data.

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

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

The description is a single, front-loaded sentence with no filler. It is appropriately sized for a zero-parameter tool and every word 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 zero-parameter list tool, the description is nearly complete, but it does not describe the return format or any pagination behavior, and there is no output schema to fill that gap. This is a minor but notable omission for a tool that an agent will use to retrieve data.

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

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

The tool has zero parameters and schema coverage is vacuously 100%, so the baseline is 4. The description's phrase 'all contacts' reinforces the lack of filtering parameters, aligning with the empty schema without needing further 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 'List all contacts' uses a specific verb ('list') and resource ('contacts'), clearly distinguishing it from sibling tools like add_contact, remove_contact, and list_tags. It unambiguously states the action and scope.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation via the verb 'list' but does not explicitly state that it is safe or non-destructive, nor does it mention any authentication or return format. For such a simple operation, the transparency is adequate but minimal.

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 words long, with no fluff or redundancy. Every word is necessary and contributes to the meaning, making it extremely concise and easy to parse.

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

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

Given the tool's simplicity—no parameters, no output schema, and no annotations—the description is sufficiently complete to convey its purpose. It does not include details like return format or authentication, but these are unlikely to be essential for a basic 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 has zero parameters, giving a baseline of 4. The description adds that the tool lists 'all' email providers, which clarifies the scope of the operation and aligns with the empty schema, providing all necessary context.

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 'List all email providers' clearly states the action (list) and the resource (email providers). It distinguishes from sibling tools like add_provider and remove_provider by using the verb 'list', making the intended use unambiguous.

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

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

The description provides no guidance on when to use this tool compared to alternatives. It simply states the action without mentioning exclusions, prerequisites, or alternative tools, offering no contextual usage hints.

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

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

No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states 'List all' without detailing return format, pagination, sorting, or whether the operation is read-only. The read-only nature is implied by 'List' but not explicitly confirmed, and there is no mention of auth requirements or 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 a single five-word sentence: 'List all scheduled campaign runs'. Every word adds meaning, with no filler or redundancy. It is front-loaded and highly 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 tool with no parameters and no output schema, the description is minimally adequate: it states the basic action and scope. However, it lacks important context such as the return value structure, whether historical runs are included, and any usage context relative to siblings. The completeness is sufficient for a trivial list tool but leaves gaps that could confuse an agent.

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 zero properties, so there are no parameters to describe. The description incurs no burden to explain parameter semantics, and the baseline for 0 params is 4. The 'all' suggests no filtering, which aligns with the absence of 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 'List all scheduled campaign runs' clearly states the action (List) and resource (scheduled campaign runs). It distinguishes itself from sibling tools like list_campaigns, which likely lists campaigns rather than scheduled runs. However, the term 'scheduled campaign runs' could be more explicit about what constitutes a 'run'.

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

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

No usage guidance is provided. The description does not indicate when to use this tool over alternatives like list_campaigns or list_tasks, nor does it mention exclusions or prerequisites. The 'all' implies a broad scope, but no explicit when-to-use or when-not-to-use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool lists settings, without mentioning the return format, whether it is read-only, authentication requirements, or potential pagination/limitations.

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

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

The description is extremely concise at three words, with no wasted or redundant language. It is front-loaded and immediately clear.

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 with no parameters and no output schema, so the description is minimally sufficient. However, it does not explicitly describe the shape of the response or any edge cases, leaving some ambiguity about what 'settings' entails.

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

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

The tool has zero parameters and the schema is fully covered (100%). The description does not need to explain parameters, and none are misleading or undocumented.

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

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

The description clearly states the verb and resource: 'List all user settings.' This distinguishes it from sibling tools like get_setting (which retrieves a single setting) by explicitly saying 'all.'

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

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

No guidance is provided about when to use this tool versus alternatives. It does not mention that get_setting should be used for retrieving a single setting, nor does it describe any exclusions or prerequisites.

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

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

The description indicates a read-only operation with 'List', which safely implies no mutation occurs. However, it does not add details about response format, ordering, or any edge cases (e.g., contacts without tags), and there are no annotations to supplement this.

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

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

The description is a single sentence with no unnecessary words, front-loading the action and scope effectively. It is highly 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 parameterless, output-schema-less tool, the description fully specifies the purpose and output ('all unique tags across your contacts'). It is sufficiently complete for an agent to 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?

The tool has zero parameters, and the schema is trivially covered at 100%. The description correctly implies no inputs are needed, and with 0 parameters the baseline score of 4 applies.

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

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

The description uses a specific verb ('list') and resource ('unique tags across your contacts'), clearly distinguishing it from sibling list_* tools that target other entities. It conveys exactly what the tool returns without ambiguity.

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

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

The description implies the tool is for retrieving all contact tags, but it does not explicitly state when to prefer this over alternatives like list_contacts or update_contact_tags. No usage constraints or prerequisites are given, resulting in only implied 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?

With no annotations, the description carries the burden of behavioral disclosure. It indicates a read-only list operation, but does not mention output format, pagination, ordering, or whether deleted tasks are included. No contradiction with annotations exists.

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

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

The description is two words and completely free of filler. It is front-loaded and every word adds meaning, making it appropriate for such a simple tool.

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

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

Given the low complexity (no parameters, no output schema), the description is minimally adequate. However, it does not disclose return value structure or any edge-case behavior, which would be helpful for a complete 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 input schema has zero parameters and full schema coverage, so the description does not need to explain parameters. The baseline for 0-parameter tools is 4, and the description does not detract from this.

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 'List all tasks' clearly states the action (list) and resource (tasks), with 'all' specifying scope. It distinguishes itself from task-related sibling tools like create_task, update_task, and delete_task.

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

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

Usage is implied by the tool name and sibling context: it is for retrieving tasks. However, the description offers no explicit 'when to use' or 'alternatives' guidance, leaving the agent to infer from the name alone.

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

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

No annotations are provided, so the description must carry the burden. It states the primary effect: 'stops processing all active schedules'. However, it omits additional behavioral details such as reversibility, idempotency, side effects on already-scheduled items, or whether permissions are required. The description is adequate but not rich.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently conveys the action and its scope, earning a high score for conciseness and structure.

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

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

For a simple one-parameter pause operation, the description covers the essential behavior. No output schema exists, and the description does not mention return values or error conditions, but given the low complexity and the clear core behavior, it is reasonably complete. A 5 would require more context about reversibility or next steps.

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

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

Schema description coverage is 0%, but there is only one parameter 'id' (string), which is clearly the campaign identifier from the tool name and description ('this campaign'). The description does not explicitly document the parameter, but the single self-explanatory parameter makes it minimally sufficient. It adds little 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 uses a strong verb ('Pause') with a specific resource ('a campaign') and clearly defines the scope: 'stops processing all active schedules for this campaign'. This distinguishes it from siblings like resume_campaign and delete_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 the context: use when you need to temporarily halt schedule processing without deleting the campaign. However, it does not explicitly mention alternatives or exclusions (e.g., 'use resume_campaign to restart', 'use delete_campaign to delete entirely'), 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that includeFailed retries failed schedules, but it doesn't explain what 'process' actually does (e.g., send emails, update statuses), whether the operation is synchronous, or what side effects it has. This is a significant gap for a batch 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 a single sentence with a parenthetical, front-loaded with the verb and object. It's concise and contains no fluff, achieving efficient communication.

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 (one optional parameter, no output schema), and the description covers the core action and the includeFailed option. However, it doesn't describe what happens after processing, such as the return value or status updates, and assumes the meaning of 'process' is obvious. This leaves some ambiguity for a batch operation tool.

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

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

The schema already describes includeFailed as 'Also retry failed schedules', and the description repeats this with 'includeFailed: true to retry failed ones'. Since schema coverage is 100%, the baseline is 3, and the description adds no new meaning beyond what's already structured.

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 ('Process') and resource ('all due campaign schedules'), clearly indicating the tool's scope. However, it doesn't explicitly distinguish itself from the sibling tool 'retry_failed', especially since the includeFailed option overlaps with that tool's purpose.

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

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

The description implies when to use the tool (when you want to process all due campaign schedules), but it doesn't provide exclusions or mention alternatives like 'retry_failed' for retrying only failed schedules. There's no guidance on when not to use this tool or how it compares to similar siblings.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remove' signals destructive intent, but the description does not explain whether deletion is permanent, if it cascades to related data, or if special permissions are needed. This is a significant gap for a destructive tool.

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

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

The description is a single, short, front-loaded sentence with no wasted words. Every word contributes to the core 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?

For a simple one-parameter tool, the description gives enough to select and invoke the tool correctly (pass the contact's ID). However, without annotations or mention of side effects and permanence, an agent cannot fully assess the impact of the destructive operation, leaving completeness at a moderate level.

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

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

With only one parameter and 0% schema description coverage, the description's 'by ID' clarifies that the 'id' parameter identifies the contact to remove. However, it adds minimal detail beyond the schema, such as the format or source of the ID, making this adequate but not rich.

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 'Remove' with a clear resource 'contact' and qualifier 'by ID', making the tool's purpose immediately obvious. It also distinguishes well from sibling tools like add_contact, list_contacts, and update_contact_tags.

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

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

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or conditions. It does not state when not to use it or whether removal is permanent, so the agent gets no decision-support beyond the basic action.

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

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

With no annotations, the description must disclose behavioral traits. 'Remove' implies a destructive operation, but the description does not state whether removal is permanent, whether it cascades to related data, or if there are any side effects. This is a significant gap for a mutation tool.

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

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

The description is a single, front-loaded sentence with no wasted words. It conveys the core action and target in minimal space.

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

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

For a simple one-parameter delete tool, the description is nearly complete: it states what it does and how it identifies the target. It lacks mention of return values or error behavior, but given the low complexity, the description is adequate.

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

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

The single parameter `id` is referenced in the description as 'by ID', which clarifies its role. However, schema coverage is 0%, and the description does not add details like the ID format or source (e.g., from list_providers), so it only slightly compensates.

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 ('Remove'), names the resource ('provider'), and specifies the method ('by ID'). This clearly distinguishes it from siblings like add_provider and list_providers.

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

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

Usage is implied: you use this tool to remove an existing provider. However, there is no explicit guidance on when to choose it over alternatives or any prerequisites or exclusions, so it remains at the baseline.

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

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

No annotations are provided, so the description carries the burden. It discloses that all paused schedules are reactivated, which is a key behavioral trait. However, it does not mention error handling for non-paused campaigns, idempotency, or side effects beyond reactivation.

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

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

The description is extremely concise: two short clauses that convey the core action and scope. Every word earns its place with no filler.

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

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

For a simple one-parameter tool with no output schema, the description provides the essential purpose and a key behavioral detail. However, it omits expected outcomes, error conditions, or preconditions beyond 'paused', leaving some ambiguity for an agent.

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 one required string parameter 'id' with no description, and schema coverage is 0%. The description does not directly explain what 'id' refers to, though the tool name and description imply it is the campaign identifier. This inference is weak for an agent.

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 'Resume' with the resource 'paused campaign' and clarifies scope with 'reactivates all paused schedules'. This clearly distinguishes it from pause_campaign and schedule_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 implies usage for paused campaigns but does not explicitly state when to use it over alternatives or provide exclusions. The sibling context suggests it is the inverse of pause_campaign, but this is not stated.

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

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

No annotations are provided, so the description carries the full burden. It discloses the scope ('all failed schedules') and the state change ('reset to active'), but does not mention potential side effects, reversibility, or whether it only affects schedules in a 'failed' state. With no annotations, more detail about the bulk nature and implications would be warranted for full transparency.

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

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

The description is a single, concise sentence that directly states the verb, resource, and purpose. There is no redundant language or filler, making it easy to parse and act upon.

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 tool with no parameters and no output schema, the description is nearly complete. It clearly defines the action and target. However, it could add a note about what happens to the schedule's retry count or error history, which would make it slightly more robust. The low complexity keeps it from needing much more.

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

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

There are no parameters in the schema, so the baseline is 4. The description effectively communicates that the operation acts on all failed schedules, providing semantic context that the empty schema lacks. No parameter details are needed.

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

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

The description uses the specific verb 'Reset' with a clear resource ('failed schedules') and outcome ('to active for retry'). It precisely distinguishes this from sibling tools like 'resume_campaign' or 'process_campaigns' by focusing on failed schedules specifically.

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: retrying failed schedules. It does not explicitly mention alternatives or when-not to use, but the context is clear enough for an agent to know it applies to failed schedules that need reactivation. Sibling tools like 'resume_campaign' exist, but the description's specificity provides sufficient usage 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states the high-level action without explaining side effects, such as whether scheduling occurs immediately, whether contact assignment overrides existing campaign members, or what happens if startAt is omitted. This is a significant gap for a tool with scheduling semantics.

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

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

The description is a single, straightforward sentence that is easy to parse and front-loaded with the primary verb. It is concise but lacks necessary detail, making it somewhat under-specified rather than efficiently complete.

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 5 parameters, no output schema, and no annotations, the description is too thin. It fails to explain the scheduling workflow, return values, or how the tool integrates with related campaign lifecycle tools (e.g., pause_campaign, process_campaigns), leaving significant contextual gaps.

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

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

Schema description coverage is high (80%), with details for tags, startAt, contactIds, and providerId already provided in the input schema. The description adds minimal semantic value beyond the schema, essentially restating the core action without clarifying parameter interactions or scheduling behavior.

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 main action: assign contacts to a campaign and schedule it. It distinguishes itself from sibling tools like create_campaign, add_contacts, and list_schedules by combining assignment and scheduling, though it could be more specific about what 'schedule it' means (e.g., schedule sending).

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

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

No guidance is provided on when to use this tool versus alternatives. There are no conditions, prerequisites, or exclusions mentioned, leaving the agent to infer optimal usage from the description alone.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the high-level action and does not reveal side effects (e.g., actual email delivery), authentication needs, or whether the email is queued or sent immediately. This leaves the agent unaware of potential consequences.

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

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

The description is a single, concise sentence with no redundancy. It is front-loaded with the verb and efficiently conveys the tool's 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?

For a side-effectful tool that sends an email, the description is under-specified. It does not mention return values, success/failure handling, or configuration needs like an active provider. With no output schema and no annotations, more context is necessary for an agent to use it safely.

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

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

Schema description coverage is only 33% (only providerId has a description). The tool description does not add meaning for the required subject and body parameters, and the optional providerId is explained only in the schema. The description adds minimal value 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 action ('Send'), the target ('a test email to yourself'), and the purpose ('preview formatting'). This distinguishes it from sibling tools like check_email_spam_score or add_provider, which have different objectives.

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 'to preview formatting' implies the tool is for reviewing email appearance, but it does not explicitly say when to use this tool versus alternatives or mention any prerequisites like a configured provider. No exclusions or alternative tool 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?

No annotations are provided, so the description carries the full burden. It only states the basic action 'Set a user setting' without disclosing side effects, persistence, validation, error handling, or return behavior. For a mutation tool, this lacks transparency.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the essential purpose and a concrete example.

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 with only two string parameters and no output schema. However, the lack of annotations and absence of return-value/error information leaves gaps. It is minimally viable but not fully complete for an agent needing to know validation or success/failure behavior.

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

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

The schema has zero descriptions for 'key' and 'value'. The description adds one example (timezone to 'America/New_York'), which gives partial semantics but does not enumerate valid keys or value constraints, leaving the agent to guess about other possible settings.

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 'Set' with a clear resource 'user setting' and provides a concrete example (timezone to 'America/New_York'). This distinguishes it from sibling tools like get_setting and list_settings, which have different actions.

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

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

There is no guidance on when to use this tool versus alternatives. The example implies a use case (setting timezone), but there is no explicit statement about when not to use it or when to prefer get_setting/list_settings instead.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without addressing side effects, permissions, reversibility, or return values. The mutation is implicit but not elaborated.

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

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

The description is a single concise sentence, front-loaded with the action. It is efficient and appropriate for the tool's simplicity, though it omits some contextual details.

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

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

The tool has no annotations, no output schema, and the description only states the basic action. It lacks information about response behavior, side effects, or usage context, making it incomplete for a mutation tool.

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

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

The description adds meaning to the 'name' parameter by indicating it is the field to update, but it does not explicitly describe the 'id' parameter. Given 0% schema coverage, this partial compensation is moderate.

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 updates a campaign's name, with a specific verb and resource. It distinguishes itself from sibling tools like update_campaign_step or delete_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 provides no guidance on when to use this tool versus alternatives such as schedule_campaign or pause_campaign. No exclusions, prerequisites, or alternative recommendations are mentioned.

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

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

With no annotations, the description must disclose behavioral aspects. It only states 'update' implying mutation but provides no detail on update semantics (e.g., partial vs. full replacement), required permissions, idempotency, or response 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?

Single sentence is concise and front-loaded with verb and object. However, it omits key behavioral and parameter details, making it slightly under-specified.

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 4 params and no annotations/output schema, the description provides minimal context. It lacks usage context, update semantics, and parameter details needed for reliable invocation.

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

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

Schema description coverage is only 25% (day has 'Delay in hours'). Description lists subject/body but adds no further meaning. It doesn't clarify formats, required id, or how parameters interact.

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 uses specific verb 'Update' and resource 'campaign step' with explicit fields (day, subject, or body), clearly distinguishing it from siblings like add_campaign_step or delete_campaign_step.

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

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

No guidance on when to use this tool versus alternatives. It doesn't mention whether it's for modifying an existing step or partial/full updates, nor does it state exclusions.

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

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

With no annotations, the description carries the burden, and it explicitly discloses the key behavioral trait: overwriting all existing tags. This goes beyond the tool name and schema, though it omits details like error handling or what happens with an empty array.

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

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

The description is a single, concise sentence front-loaded with the action verb. It contains no redundant words and earns its place by adding the crucial 'replaces all tags' clarification.

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 2-parameter mutation tool, the description covers the core purpose and main side effect. However, it lacks context about prerequisites (e.g., contact must exist), behavior on failure, and does not mention any response format, which are relevant for an agent.

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

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

Schema coverage is 0%, and the description does not directly explain the parameters. The parenthetical clarifies that 'tags' represents the full replacement set, but it does not explain the 'id' parameter or any constraints, leaving the agent to infer from property names.

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 ('Set tags on a contact') and specifies that it replaces all existing tags, which distinguishes it from list_tags and any potential incremental tag tools. The verb-resource pair is specific 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?

No guidance is given on when to use this tool versus alternatives. The 'replaces all tags' note implies it is for full replacement, but there is no explicit mention of scenarios where this is preferred or any exclusions.

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

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

No annotations are provided, so the description must disclose behavior, but it only says 'update.' It does not mention partial-update semantics, whether non-specified fields are preserved, error behavior for invalid ids, or permission requirements.

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

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

The description is very concise with no wasted words, but it is under-specified for a 6-parameter tool. Being short is positive, but it sacrifices necessary detail.

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

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

With no output schema, no annotations, and sparse description, the tool is not fully contextualized. It lacks information about response format, validation rules, and how it interacts with other task-related tools.

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

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

Schema description coverage is 0%, and the description only mentions status and priority, ignoring title, dueDate, and description. It adds little beyond the schema's enums and does not clarify the required id parameter or value formats.

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 identifies the action ('update') and resource ('task'), and lists representative fields (status, priority). It is distinguishable from siblings like create_task and delete_task, though the phrase 'or fields' is somewhat vague.

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

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

It is implied that this tool is for modifying an existing task, as opposed to create_task or delete_task. However, there is no explicit guidance about when to use it over alternatives, prerequisites, or any exclusions.

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