Mailercloud

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known without the description. The description adds the non-obvious fact that it returns a letter grade and actionable recommendations, but it does not disclose any additional behavioral traits (e.g., required auth, rate limits, or latency). It adds some context but stays within the annotation coverage.

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

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

The description is a single, front-loaded sentence that states the purpose first and then enumerates outputs. It contains no redundant phrases or obviously wasted terms. Every clause contributes to the agent's understanding of what the tool does and what it delivers.

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?

Without an output schema, the description appropriately explains the return content (grade, scores, deliverability, insights, recommendations). It does not mention error conditions, pagination, or the reliance on api_key, but the api_key is present in the schema and the operation is a safe read, so a competent agent can infer authentication needs. This is slightly incomplete but sufficient for a single-campaign analysis tool.

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

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

Schema covers 100% of parameters with descriptions, so it already documents api_key, campaign_id, and cost_per_email. The description does not add any parameter-specific meaning beyond the schema, and the mention of 'cost per email in dollars' is already present in the schema. No extra semantic depth is provided, so a baseline 3 is appropriate.

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

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

The description clearly states the verb ('Deep-dive analysis') and the resource ('a single campaign'), and enumerates a specific list of outputs (letter grade, performance scores, deliverability health, insights, recommendations). It explicitly scopes to 'single campaign', which distinguishes it from sibling tools like analyze_latest_campaigns (plural) and audit_campaign_draft.

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 analyzing one campaign's performance but does not explicitly say when not to use it or mention any alternative tools. While 'single campaign' sets a clear context, it lacks an explicit routing statement such as '0use this instead of analyze_latest_campaigns' or 'when you have a specific campaign, not a list'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds details about outputs (grades, benchmarks, trends, action plan) but does not disclose any additional behavioral traits beyond what annotations provide. No contradiction.

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

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

A single dense sentence packs in scope, defaults, limits, and the full list of outputs with zero wasted words. The most important discriminating detail ('batch') is front-loaded.

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

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

Given the tool's moderate complexity and no output schema, the description covers the essential inputs (count, optional cost) and enumerates the analysis outputs comprehensively. Minor gaps such as the meaning of 'industry benchmarks' or how the api_key is used are already covered by the schema parameters.

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

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description restates the count default and range and notes cost_per_email is optional, but adds no new semantic meaning beyond the schema. Baseline 3 applies.

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

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

The description clearly states a specific verb ('Analyze'), a resource ('recent completed campaigns'), and a defining scope ('as a batch'), which distinguishes it from siblings like analyze_campaign that operate on a single campaign. The default and maximum count add precision.

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

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

The description implies the use case (batch analysis of recent completed campaigns) and specifies the count range, but it does not explicitly mention when to use this tool versus alternatives like analyze_campaign or compare_campaigns. There is no exclusion or alternative routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context (pre-send audit, fix-it recommendations) beyond annotations, but it doesn't disclose details like whether it sends any data externally or if there are rate limits. Acceptable 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, comprehensive sentence front-loaded with the core purpose, followed by specific checks and outcome. Every clause earns its place; no filler or repetition.

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

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

For a read-only audit tool with a single required parameter and no output schema, the description adequately covers what it checks and what it returns (checklist with recommendations). It could mention whether it returns results synchronously or any limitations, but nothing critical is missing given the annotations cover non-destructiveness.

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

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

Schema description coverage is 100% for both parameters (api_key and campaign_id), so schema already documents them. The description does not add additional meaning beyond what's in the schema; it merely implies campaign_id is needed. Baseline 3 is appropriate.

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

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

Description clearly states a specific verb ('audit') and resource ('campaign draft'), enumerates the exact checks performed (subject line, spam triggers, sender config, list selection, content, preheader) and outputs a pass/fail checklist with recommendations. It is distinct from sibling tools like analyze_campaign since it is explicitly pre-send and quality-focused.

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 says to use it 'before scheduling any campaign,' which gives a clear temporal trigger. It does not explicitly name alternatives or when not to use it, but the pre-send context is strong enough to separate it from analysis or scheduling tools.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description is not responsible for establishing that mutation occurs. However, the description adds no behavioral context beyond the bare claim of creating contacts: it does not disclose failure handling, whether partial batches roll back, outcome for duplicate emails within a batch, required authentication beyond the api_key parameter, or limits on array size — all significant for a bulk write 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?

A single front-loaded sentence with no filler and a clear verb-resource-scope structure. It earns its place, though it borders on under-specification rather than being economically 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?

This is a batch write over a rich nested contacts array (with per-contact overrides of list_id and id) yet the description says only 'create multiple contacts.' It omits batch success/failure semantics, interaction between top-level list_id and per-contact list_id overrides, idempotence implications (annotations state idempotentHint=false, but behavior on rerun is unexplained), and any response format — all material for a non-trivial bulk tool.

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

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

Schema description coverage is 100%, so the schema already documents api_key, list_id, and contacts. With full coverage, the baseline is 3. The description adds no parameter semantics at all, but given the schema covers the load, the tool does not need to compensate for gaps.

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

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

The description states a specific verb ('Create'), resource ('contacts'), and scope ('multiple... in bulk'). This distinguishes it from the sibling create_contact without naming it directly, since the batch scope is self-evident. Loses a point for not explicitly naming the sibling it is not.

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 the single-contact create_contact, nor on when not to use it. It also omits practical selection context such as batch size limits, deduplication behavior, or whether upsert/update semantics apply instead. The agent must 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is covered. The description adds that it returns a dashboard with specific elements but doesn't disclose details like which benchmarks or how results are computed. Given the annotations, a score of 3 is appropriate because the description adds some behavioral context but not exhaustive.

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

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

Two concise sentences: the first front-loads the purpose and expected output, the second gives a clear usage directive with an alternative. No wasted words, and the structure is optimal.

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

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

This is a read-only dashboard tool with zero required parameters, full schema coverage, and rich annotations. The description sufficiently covers what the tool does and how it fits, and nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, with both parameters (api_key and cost_per_email) described in the schema. The description mentions 'cost per email' as part of the investment summary, linking it to the optional parameter, but doesn't add syntax or format details beyond what the schema already provides. Baseline 3 is correct.

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 states a clear verb ('Returns an at-a-glance dashboard') and resource ('portfolio-level health check across recent campaigns'), with specific components (overall grade, metric status, trends, priority action). It also distinguishes itself from analyze_latest_campaigns, making its 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?

Explicitly says 'Use this for a fast 10-second overview; use analyze_latest_campaigns for deep analysis.' This clearly indicates when to use this tool and names the alternative for deeper work, fulfilling the when/when-not criterion.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful context by enumerating the kinds of results returned, which matters because there is no output schema. It does not describe any side effects, but none are expected given the annotations.

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

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

The description is a single, information-dense sentence that front-loads the core purpose and then enumerates the key outputs. There is no filler or redundant restatement of the tool name.

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

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

For a comparison tool with safety annotations and schema-documented parameters, this description is largely complete. It explains the output composition, which is valuable since there is no output schema. Adding explicit guidance about when to prefer this over analyze_campaign or analyze_latest_campaigns would make it fully 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?

The input schema already documents campaign_ids and cost_per_email with 100% coverage, so the baseline of 3 applies. The description adds no parameter-specific meaning beyond what the schema provides.

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

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

The description clearly states the tool does side-by-side comparison of two or more campaigns and specifies what it produces: performance metrics, scores, grades, per-metric winners, and recommendations. This distinctively separates it from sibling tools like analyze_campaign or get_campaign.

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

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

The intended use case is clear: comparing multiple campaigns and identifying which performed best per metric. However, it does not explicitly mention when not to use it or name alternative tools, such as analyze_campaign for a single-campaign deep dive.

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

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

Annotations indicate readOnlyHint=false, so this is known to be a write operation. The description adds valuable behavioral context beyond annotations: sender auto-resolution logic, the prompt-to-choose fallback, and the reply-to default behavior. It does not disclose all post-creation behaviors (e.g., whether a draft is created without is_publish), but the critical decisions are surfaced.

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

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

The description is three concise sentences. The first states the purpose, the second states required fields, and the third explains important default behaviors. No filler words; every sentence earns its place. Structure is logically ordered from general to specific.

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 20 parameters and no output schema, the description covers the most critical creation logic (required fields, sender resolution, reply-to default). It does not mention response format or error handling, but the schema covers all parameter meanings and annotations cover safety. The description is complete enough for correct invocation in most scenarios.

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

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

Schema coverage is 100%, so every parameter already has a description. However, the description significantly enhances understanding of key parameters (sender_name, sender_email, sender_id, reply_email, reply_id) by explaining fallback and default semantics. This is exactly the kind of added meaning that helps an agent choose and fill parameters correctly.

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

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

The description clearly states the specific action 'Create a new email campaign in MailerCloud'. It names the resource (email campaign) and the required inputs, distinguishing it from sibling tools like update_campaign or list_campaigns. The verb 'create' is unambiguous and the context is explicit.

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

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

The description gives explicit prerequisites (name, subject, list ID) and explains default behaviors for sender resolution and reply-to configuration. It does not explicitly compare against alternatives like schedule_campaign or send_transactional_email, but it provides enough context for an agent to know when to invoke this tool for creating a new campaign.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds no extra behavioral context: it does not explain duplicate handling, error behavior, whether an API key is required despite appearing in the schema, or what happens if the list_id is invalid.

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 short and front-loaded with a clear purpose. The second sentence about required fields is redundant with the schema, so not every sentence earns its place, but the overall structure is efficient and free of unnecessary 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?

This tool has 14 parameters, nested objects, and no output schema, yet the description only states the basic operation. Missing context includes return value, duplicate/error handling, how API key authentication works, and the relationship to sibling batch/upsert tools, making the description inadequate for correct invocation in many scenarios.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats that email and list_id are required, which the schema already conveys, and does not add any additional meaning about parameter formats, constraints, or relationships.

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 'create' and the resource 'a contact in a MailerCloud list', immediately conveying the core function. It does not explicitly differentiate from sibling tools like batch_create_contacts or upsert_contact, but the basic purpose is unambiguous.

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

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

No guidance is given on when to use create_contact over batch_create_contacts, upsert_contact, or update_contact. It also omits prerequisites such as list existence or authentication requirements, leaving the agent to infer usage solely from the tool name.

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

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

Annotations provide readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which establish this is a non-idempotent write operation. The description adds no behavioral context beyond what annotations already convey — it doesn't clarify API key requirements, what happens on duplicate names, or how list_type affects behavior.

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

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

The description is a single efficient sentence with no wasted words, which earns some credit. However, it is under-specified for a tool that creates a resource — it lacks any qualifiers about list_type values or usage context, making it brief rather than genuinely informative.

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 3 parameters (2 required), no output schema, and a description that merely states the action. With no output schema, the agent gets no information about what a successful response looks like. list_type is an integer with no enumerated values or explanation of valid options, which is a meaningful gap for correct usage.

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

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

Schema description coverage is 100%, with name and list_type documented as required parameters. The description adds no extra meaning beyond the schema; however, the schema already documents parameter presence and types, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Create') with a clear resource ('new contact list') and platform scope ('in MailerCloud'). It clearly distinguishes from sibling tools like delete_list and update_list, though it doesn't explicitly differentiate from other create_* siblings like create_contact or create_tag.

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 alternative create tools or when existing lists should be updated instead. There are no exclusions, prerequisites, or context that would help an agent decide between create_list and update_list or list_contact_lists.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the mutation and non-idempotent nature. The description adds no further behavioral details such as permissions, side effects, or error scenarios. It is consistent with annotations but does not go beyond them.

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

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

A single, purpose-built sentence with no filler. It conveys the essential information efficiently and is front-loaded with the action and object. There is no unnecessary 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?

The tool is simple, but the description omits return values and potential failure modes. Since no output schema is provided, the agent is left without knowledge of what the response looks like. For a straightforward creation operation, this is a minor but notable gap.

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

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

Schema description coverage is 100%, so both parameters (name and api_key) are fully documented in the schema. The description provides no additional parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the action ('Create') and the resource ('a new tag') plus its purpose ('organizing contacts'). It is distinct from sibling tools like list_tags (listing tags) and create_contact (creating contacts), leaving no ambiguity about what the tool does.

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

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

No guidance is given about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or conditions that would route an agent away from other tag-related tools. The description only states the action without 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-read, potentially non-idempotent write. The description adds no extra behavioral context (e.g., whether creation overwrites, requires authentication, or has API limits), but annotations cover the basic safety profile, so a 3 is appropriate.

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

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

A single, compact sentence that directly states the tool's action. No filler or redundant information.

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

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

The description is minimal but combined with full schema coverage and annotations, an agent can understand the basic call requirements. However, there is no output schema or notes on return values, potential side effects beyond the hints, or which optional parameters (e.g., plain_text, category_id) matter in common workflows, leaving some context 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 100%, and each parameter has a description in the schema. The tool description adds no extra meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb ('Create') and resource ('HTML email template'), making the primary purpose clear. It doesn't explicitly contrast with sibling tools like update_template or get_template, but the verb alone differentiates the core action.

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

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

No guidance is provided on when to use this tool versus alternatives such as update_template or batch_create_contacts. The description gives no context for when creation is appropriate, nor 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?

Annotations already indicate this is a write operation that is not idempotent and not destructive. The description adds a minimum of context by saying the webhook will 'receive event notifications', which discloses its ongoing side effect. However, it does not mention authentication requirements or possible duplicate-creation behavior in more detail, despite those being relevant to a create call.

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

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

The description is a single, front-loaded sentence that states the core action and its purpose with no redundant or irrelevant content. Every word adds meaning.

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

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

The description is inadequate for a mutate tool without an output schema. It does not specify what the tool returns (e.g., the webhook object or an ID), nor does it explain the allowed values for 'events' or when the optional 'api_key' is required. An agent cannot fully anticipate the result or constraints of calling create_webhook from this description alone.

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

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

The input schema has 100% parameter description coverage; each parameter (url, name, events, api_key) already has a description. The tool description itself adds no parameter-level meaning, so it remains at the baseline score of 3.

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

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

The description clearly identifies the verb 'Create' and the resource 'new webhook', and explains its purpose: 'to receive event notifications'. This distinguishes it from sibling webhook tools such as update_webhook, delete_webhook, or toggle_webhook, as it is the only one explicitly creating a new webhook.

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

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

The description gives no guidance on when to select this tool over alternatives. There is no mention of prerequisites, exclusions, or distinction from update_webhook/list_webhooks. The phrase 'to receive event notifications' is a statement of purpose, not a usage rule.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description doesn't need to repeat that. The description adds the core behavioral fact that deletion is by ID. However, it doesn't disclose side effects like whether associated data is removed or whether the deletion is permanent. With annotations covering the safety profile, this 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?

Single sentence, no filler, front-loaded verb. Perfectly concise and 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?

For a simple deletion tool with annotations (destructiveHint=true, idempotentHint=true) and a fully documented schema, the description is nearly complete. It lacks explicit note on irreversibility or cascading effects, but given the tool's simplicity and annotation coverage, this is a minor gap.

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

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

Schema description coverage is 100% (both api_key and contact_id are described). The description adds a bit by specifying that the contact is deleted by ID, which matches the contact_id parameter. Since the schema fully documents parameters, the description's contribution is minimal but not incomplete. Baseline 3 for full coverage, +1 for reinforcing the required parameter's role.

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 states a clear verb ('Delete') and resource ('a contact'), and identifies the required identifier ('by ID'). It is distinguishable from sibling tools like get_contact and update_contact, though it doesn't explicitly name an alternative, so it misses the strongest differentiation.

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

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

The description implies usage: you need a contact_id to delete a contact. It doesn't provide explicit when-to-use guidance or mention alternatives (e.g., delete_list, batch operations). The context is straightforward enough that an agent can infer intent, but there is no explicit routing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safe/mutating profile is known. The description adds no extra behavioral context such as irreversibility, permission requirements, or cascading effects. It merely repeats the delete action without going beyond the annotations.

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

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

The description is a single, concise sentence that delivers the core purpose without any filler. It is appropriately sized for 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?

For a simple deletion tool with annotations covering destructiveness and idempotency, the description is mostly sufficient. However, it does not mention potential side effects, what happens if the list does not exist, or the response format, leaving some uncertainty 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?

Input schema provides descriptions for both parameters (api_key and list_id), covering 100% of the schema. The description does not add any additional meaning beyond what the schema already states, so the baseline of 3 applies.

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

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

The description 'Delete a contact list by ID' states a clear verb and resource, distinguishing it from sibling tools like delete_contact and delete_webhook. It is specific and immediately understandable.

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_list or list_contact_lists. The description simply states the action without context or exclusions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description does not need to repeat these. However, it adds no behavioral context beyond the basic action, such as irreversibility, permissions, or side effects. The description is consistent with annotations, so no contradiction.

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

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

The description is extremely short but appropriate for a simple delete operation. It front-loads the core action without any filler. Slightly more detail could be expected, but it earns its place.

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

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

For a simple delete tool with two parameters and comprehensive annotations, the description is minimally sufficient. However, it lacks any note about the api_key's necessity or the permanent nature of the deletion, which would help the agent fully understand the context before invoking.

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

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

Input schema covers both parameters (api_key and webhook_id) with descriptions, achieving 100% coverage. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Delete') and resource ('webhook'), clearly distinguishing it from sibling tools like create_webhook, get_webhook, and update_webhook. No ambiguity about the operation.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or conditions. It simply states the action, leaving the agent to infer context from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds value by explaining the analytical behavior (showing conversion rates, identifying the largest drop-off, providing recommendations) without contradicting annotations. It does not disclose any side effects beyond the safe read-only nature, but adds functional context for the agent.

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 definition is two sentences with no redundant fluff. It front-loads the core action (Visualize), then specifies the resource (engagement funnel for a sent campaign), and clarifies the analytical output. Every clause contributes to understanding the tool's function without unnecessary 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?

At low complexity (2 parameters, 1 required, schema covers all), and with full annotations covering safety, the description adequately covers what the tool does with outputs like conversion rates and recommendations. However, there is no output schema, and the description does not explicitly state the return format or how the recommendations will be presented, leaving minor ambiguity about the exact shape of the answer.

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

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

The schema provides descriptions for both parameters (api_key and campaign_id) with 100% coverage, so the description adds little beyond the schema. The description does imply the campaign_id is the central target of analysis ('for a sent campaign') which slightly enhances context, but no additional semantic details beyond schema are provided, keeping the score at the baseline for full schema coverage.

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

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

The description clearly states the tool's purpose, with a specific verb ('Visualize'), resource ('engagement funnel for a sent campaign'), and enumerates the funnel stages (total sent → delivered → opened → clicked). It also mentions specific analytical outputs (conversion rates, biggest drop-off point, recommendations), which distinguishes it from more general analysis tools like analyze_campaign or compare_campaigns by implying a funnel-specific focus.

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

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

The description specifies a concrete use case ('for a sent campaign') and implies usage when you need funnel analysis. However, it does not explicitly contrast this tool with alternatives (e.g., when to use analyze_campaign instead), nor does it mention exclusion scenarios, but the context is clear enough that an agent can infer appropriate usage.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is safe and deterministic. The description adds context about the return content (limits, usage, subscription), but does not describe exact return format or any potential caveats such as rate limits. Given the annotations carry the safety profile, a 3 is acceptable.

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 of 12 words with no redundancy, directly stating the resource and its contents. It is efficient and front-loaded with the core action. Every word earns its place, making it 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?

Given the tool's simplicity (one parameter, no output schema) and the annotations providing safety cues, the description is reasonably complete. It does not detail the exact return structure, but as an account overview, its scope likely matches the described contents. The lack of an output schema gives room for more detail, but the description covers the essential context for an agent to know when to call it.

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

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

There is only one parameter, api_key, and it is fully described in the schema at 100% coverage. The description adds no additional meaning to the parameter beyond what the schema already provides. Since the schema covers the parameter entirely, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Get account plan details'. It specifies that it includes limits, usage, and subscription information. This distinguishes it from other get tools in the sibling list, which are all about campaigns, contacts, templates, etc. Its scope is unique and unambiguous.

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

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

The description implies usage when account subscription or usage information is needed, but does not provide explicit guidance on when to use this tool versus alternatives or mention any exclusions. Given the subject matter, it's likely the only tool for account overview, but the description does not explicitly state this. A modest score is appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is established. The description adds the node_type filter behavior, which slightly goes beyond the annotations, but it doesn't explain what 'details' includes or any authentication requirements. It aligns with annotations and adds modest value.

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

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

The description is a single, tightly worded sentence with no filler. It front-loads the core action ('Get details of a specific automation workflow') before the optional qualifier ('optionally filtered by node type'). Every word contributes to understanding.

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

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

For a simple read-only get tool with all parameters documented in the schema and a full annotation set, the description is sufficient for correct invocation. The only missing piece is a description of the return payload format, but since no output schema exists and the tool is a straightforward get operation, this is not critical.

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

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

Schema description coverage is 100%, with each parameter already documented in the input schema (automation_id is required, api_key is the MailerCloud key, node_type filters by node type). The description's mention of 'node type' simply echoes the schema, so it adds no meaningful new 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 states a specific verb and resource: 'Get details of a specific automation workflow'. It clearly distinguishes this from sibling tools like get_campaign, get_contact, and get_template, since none of the siblings target automations. The optional node_type filter further clarifies the tool's focused 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 phrase 'a specific automation workflow' provides clear context that this tool is for retrieving a single automation by ID, not for listing or broad queries. It does not explicitly name alternatives or exclusions, but the resource 'automation workflow' is unique among siblings, making the intended use clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing a clear safety profile. The description adds detail about the report contents but does not disclose any additional behavioral traits such as data access requirements or output formatting. It does not contradict annotations, so a 3 is appropriate.

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

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

The description is a single, tightly packed sentence that front-loads the core purpose and then concisely enumerates the report's components. Every phrase adds meaningful information and there is no filler or redundancy.

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

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

Given the single parameter, full schema coverage, and no output schema, the description successfully conveys what the report covers and how it is derived. It lacks an explicit statement about the return data format, but the detailed content list largely compensates, making it nearly complete for invocation purposes.

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

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

The input schema fully documents the single parameter (api_key) with 100% coverage, so the description does not need to repeat it. The description provides no additional parameter-level insight beyond what the schema already states, matching the baseline for complete 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 ('Generate') and names a concrete resource ('email marketing best practices report'), clearly distinguishing it from sibling analysis tools like analyze_campaign or compare_campaigns. It enumerates what the report contains, leaving no ambiguity about the tool's function.

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

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

The description implies the tool should be used when a user wants best-practice recommendations based on campaign data, but it does not explicitly contrast with sibling tools or state when not to use it. Usage context is implicit rather than explicit, earning a mid-level score.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context that the response contains full details including performance metrics, which is valuable since no output schema exists. It does not describe error handling, but the annotations lower the burden.

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 one concise sentence with no filler. The primary verb, resource, and qualifiers are front-loaded, making it easy to parse quickly.

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

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

For a straightforward single-campaign retrieval with one required parameter and read-only annotations, this description provides adequate context for correct invocation. The mention of full details and performance metrics gives a sense of the output even without an output schema; listing specific fields might improve it, but it is not essential.

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

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

Schema description coverage is 100%, as both api_key and campaign_id have explicit descriptions. The description only reinforces that campaign_id identifies the campaign by ID and adds no new parameter-level detail beyond what the schema already provides.

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

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

The description clearly identifies the operation ('Get'), the resource ('a specific MailerCloud campaign'), the access pattern ('by ID'), and the key content ('including performance metrics'), which differentiates it from list_campaigns and analysis-oriented siblings like analyze_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 when to use the tool (when a campaign ID is known and full details are needed) but does not explicitly state alternatives or exclusions. No guidance such as 'for listing campaigns use list_campaigns' or 'for performance analysis use analyze_campaign.'

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

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

Annotations already declare readOnly and idempotent hints, so the description only needs to add behavior context. It adds the constraint 'for a sent campaign', which is useful for ensure the agent checks the campaign status. Minor gaps exist, such as mention of pagination behavior, but the description contributes beyond the annotations.

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

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

The description is a single, focused sentence with no wasted words. It front-loads the key verb and resource. Although it is minimal, it is suitably concise; a slightly longer description with pagination hints would add value, but the current structure is effective.

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

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

Given the tool's moderate complexity (4 params, no output schema, no nested objects), the description is adequately complete. All parameters are documented in the schema and the main behavioral constraint (association with a sent campaign) is explicitly stated. However, lack of detail on the return format or pagination leaves some ambiguity for the 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 covers all 4 parameters with descriptions (100% coverage). The description does not add additional semantics beyond schema, so the baseline of 3 is appropriate. The optional 'page' and 'limit' are described in schema, and the description does not need to elaborate.

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

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

The description clearly states the verb 'Get' and the specific resource: 'domain-level performance statistics for a sent campaign'. This precisely conveys the tool's purpose and distinguishes it from other campaign-related tools like get_campaign or analyze_campaign_health.

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 sent campaigns (a usage condition), but does not explicitly state when not to use it or mention alternative tools. The context that it focuses on domain-level stats is clear through the name and description, but no explicit exclusion or comparison is provided.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'detailed information' and 'specific contact' but does not describe return format, error cases, or pagination. With annotations covering safety, this 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?

A single efficient sentence. The key qualifiers 'detailed information', 'specific contact', and 'by ID' are front-loaded with no waste.

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?

Adequate for a simple read-only lookup where annotations and full schema coverage carry the burden. It lacks any mention of output structure or error behavior, but for a 2-param read tool this is acceptable.

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

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

Schema coverage is 100%, so both api_key and contact_id are already documented in the schema. The description maps the tool-level purpose to contact_id but adds no new detail beyond the schema.

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

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

States a specific verb and resource: get detailed information about a specific contact by ID. It is clearly differentiated from list_contacts and create_contact, though it doesn't explicitly name a sibling alternative.

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

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

No guidance on when to use this tool vs alternatives such as list_contacts or get_list_details. The description implies it is for single-contact lookups by ID, but provides no exclusions or context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about date range filtering and monitoring purpose, but does not disclose return format or pagination behavior. Since annotations carry the behavioral burden, a score of 3 is appropriate.

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

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

Two sentences convey the core action, scoping, and purpose with no redundant words. The key filtering constraints are front-loaded, making it easy to scan 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 read-only, non-destructive list-type tool with fully documented parameters and safe annotations, the description is mostly sufficient. It lacks details on what specific tracking metrics are returned, but the absence of an output schema and the simple nature of the tool keep this from being a major gap.

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

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

Schema description coverage is 100% and each parameter has a clear description. The tool description mentions date range and optional filters, which aligns with the parameters, but does not add meaning beyond the schema itself. Baseline 3 is appropriate.

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

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

The description clearly identifies a specific verb ('Get') and resource ('inbox placement tracking data'), and specifies the scope ('for a date range, optionally filtered by campaign or domain'). This distinguishes the tool from sibling tools like get_campaign_domain_report which targets a different data focus.

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

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

The description implies the tool is for monitoring deliverability across email providers, which gives a clear use case. However, it does not explicitly state when to prefer this over sibling tools or mention exclusions, though the purpose is sufficiently distinct.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that subscriber counts are included in the details, which is useful context. However, it does not disclose other potential behaviors such as error handling or response structure beyond this single detail.

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 front-loads the primary purpose and includes the key detail (subscriber counts). No wasted words or redundancy.

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

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

For a simple read-only retrieval tool with complete parameter schemas and rich annotations, the description is mostly sufficient. It mentions subscriber counts but leaves other possible return fields unstated. Given the tool's simplicity and no output schema, a 4 is reasonable—slightly above the minimum viable.

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

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

Schema description coverage is 100%, with both api_key and list_id thoroughly described. The description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: getting details of a specific contact list, including subscriber counts. It distinguishes itself from sibling tools like list_contact_lists (which lists all lists) by emphasizing 'specific' and the detail content.

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 when needing details of a single list, but it does not explicitly mention when to use it over alternatives like list_contact_lists or update_list. Context signals and sibling names provide hints, but the description itself lacks explicit guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully cover the safety profile. The description adds no additional behavioral context beyond what the annotations provide, which is acceptable but does not elevate the score above the baseline.

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 front-loads the key action and resource. It contains no waste and is immediately parseable by an agent.

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

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

For a simple read operation with full annotation coverage and zero required ambiguity, the description sufficiently conveys what the tool returns (details and HTML content). No output schema exists, but the description names the expected output, making it complete for invocation.

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

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

Schema description coverage is 100%, with both api_key and template_id having explicit descriptions. The description itself adds no extra semantic detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool gets a template's details and HTML content by ID, using a specific verb ('Get') and resource ('template'). It is easily distinguished from siblings like create_template or update_template, and the phrase 'by ID' clarifies the lookup method.

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 used when you need a template's details or HTML content given a template ID. While it doesn't explicitly mention alternatives or when not to use it, the context is clear enough given the sibling tool names and the read-oriented nature of the operation.

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

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

注解已经声明readOnlyHint=true、idempotentHint=true和destructiveHint=false,表明这是一个安全的读操作。描述'Get details'没有添加超出注解的行为上下文,如认证要求、错误条件或返回格式。因此没有为agent提供超越已有结构的额外行为信息。

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?

描述是一个简洁的单句'Get details of a specific webhook.',每个词都有作用,没有冗余。对于这样一个简单的读操作,这个长度是合适的,且关键信息'get'和'specific'放在前面,结构清晰。

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?

工具简单,有2个参数,注解涵盖了安全特性。但描述没有说明返回值的内容,且没有输出schema来补偿。对于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对两个参数(api_key和webhook_id)都有描述,覆盖率100%。描述本身没有添加任何参数语义,没有解释ID格式或API密钥的传递方式。根据覆盖率高的基线,评分为3。

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

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

描述使用明确的动词'Get'和资源'details of a specific webhook',清楚表明这是获取单个webhook详细信息的操作。'specific'一词将其与兄弟工具list_webhooks区分开来,后者用于列出所有webhook。标题'Get Webhook Details'也与此一致,无歧义。

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

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

描述没有明确说明何时使用此工具或何时使用替代方案。'specific webhook'隐含了需要webhook_id的使用场景,但没有提供与list_webhooks或update_webhook等兄弟工具的选择指导。没有排除条件或替代方案提示,因此用法只能推断。

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds details about the returned data fields, which is useful, but does not disclose pagination behavior such as default page size or how the response is structured. With strong annotation coverage, a score of 3 is appropriate.

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

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

The description is a single, efficient sentence that front-loads the core action and resource, then lists the key return fields. Every word earns its place with no redundancy or filler.

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

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

For a simple list operation with annotations covering safety and a fully documented schema, the description is nearly complete. It does not explain pagination defaults or output format, but no output schema exists and the core purpose and return fields are stated. Slightly more detail on pagination would make it fully complete.

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

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

Schema description coverage is 100%, so all three parameters (page, limit, api_key) are already documented in the input schema. The description mentions pagination but does not add parameter-specific meaning beyond what the schema provides. Baseline 3 is correct since the schema does the heavy lifting.

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

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

The description uses a specific verb ('List') with a clear resource ('MailerCloud campaigns') and adds pagination context. It also lists the returned fields (names, IDs, subjects, statuses, performance metrics), which distinguishes it from other campaign-related tools like analyze_campaign or get_campaign.

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

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

No guidance is given on when to use this tool versus alternatives. The description states only what the tool does, not when to choose it over siblings such as get_campaign or analyze_campaign. For a list operation, the intended use is somewhat implied, but explicit context or exclusions are missing.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is established. The description adds behavior beyond the schema by indicating that the result spans all lists and is paginated, which an agent needs when collecting the full set. No contradiction with annotations.

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

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

One efficient sentence that puts the action and resource up front and appends the pagination qualifier. No wasted words or repetition of annotations.

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

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

For a straightforward read-only list tool, the description plus fully documented parameters and safety annotations cover most of what an agent needs. It lacks explicit response-shape details or default pagination behavior, but these are not critical given the simplicity and 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 100%: page, limit, and api_key each have meaningful descriptions. The description adds little beyond reinforcing pagination, so a baseline score of 3 is appropriate because the schema does the heavy lifting.

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

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

The description uses a specific verb ('List') and resource ('MailerCloud contact lists') and states the scope ('all') plus pagination. This clearly differentiates it from siblings like get_list_details, create_list, and list_contacts.

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

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

The description implies use when the agent needs to enumerate contact lists rather than inspect a single list, create, update, or delete one. It does not explicitly state when not to use it or name alternative tools, so guidance is only implied, not explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the pagination behavior, which is a small extra context. It does not disclose details like ordering, default page/limit values, or error behavior, but given the annotations this is adequate.

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

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

One sentence with no wasted words, front-loading the core purpose and adding a key behavior. It is appropriately concise and readable.

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

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

For a simple list operation with strong annotations and a complete parameter schema, the description is mostly sufficient. It lacks explicit mention of return format or use context, but these are not critical given the simple nature and lack of 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?

The input schema covers all parameters with descriptions (100% coverage). The tool description mentions 'specific list' and 'pagination', which maps to list_id and page/limit, but does not add meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'List', the resource 'contacts', and the scope 'in a specific MailerCloud contact list', with pagination as an additional behavior. It distinguishes itself from sibling tools like list_contact_lists (which lists lists) and get_contact (single contact).

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 vs alternatives such as get_contact or list_contact_lists. The description implies you need a list_id but does not state prerequisites, context, or exclusions.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive, so the description need not restate that. It adds modest context by specifying 'in your account', clarifying the scope, but it doesn't describe return shape, pagination behavior, or any other operational nuance beyond what the schema already implies.

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

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

A single, clear sentence with no filler. The key action and object are front-loaded, making it immediately scannable and unambiguous.

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

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

For a simple read-only listing operation with optional pagination and auth parameters, this description is nearly sufficient. It lacks an explicit note about paginated return values or the output shape, and there is no output schema to fill that gap, but the core purpose and scope are clearly conveyed.

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 gives descriptions for all three parameters (page, limit, api_key), so schema description coverage is 100%. The tool description adds no parameter-level meaning, leaving a baseline of 3 per the calibration rule.

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

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

States the specific verb 'list', the resource 'custom contact properties/fields', and the scope 'defined in your account'. It clearly distinguishes itself from sibling list tools, none of which reference custom fields.

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

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

Provides no guidance on when to use this tool vs alternatives, no explicit exclusions, and no mention of conditions that would favor another tool. The only hint comes indirectly from the sibling tool names, not from the description itself.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safeness is disclosed. The description adds the context that it returns IDs usable in campaigns, and that it lists 'all' reply emails, which is a small behavioral note. No additional risks or hidden side effects are described, but the annotations carry most of the burden.

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

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

Two short sentences with no redundant phrasing. The core purpose is stated first, then the actionable usage tip. Every word contributes to clarity, and it is front-loaded with the main action.

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

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

The description is complete enough for a simple list/read operation, thanks to annotations covering the safety profile and the schema covering all parameters. The main minor gap is that it does not mention pagination behavior or the exact shape of the response (though no output schema exists), but it does explicitly flag the use of IDs, which is the key return info. For a tool of this complexity, it is mostly 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?

The schema covers all three parameters (page, limit, api_key) with a 100% description coverage. The tool description adds no further semantics beyond what the schema provides, but it does not retreads the schema either. Per the baseline, a 3 is warranted because the schema does the heavy lifting and the description does not contradict it.

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

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

The description names a specific verb (Listing) and resource (reply-to email addresses), and immediately ties them to a concrete downstream use (campaign creation with reply_id). This clearly distinguishes it from sibling tools like list_senders or list_webhooks, which target different resources.

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

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

It implies the main use case ('Use the returned IDs when creating campaigns'), which gives context but does not explicitly say when not to use it or name alternatives. Sibling tools like list_senders exist but are never mentioned, so the guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond 'List all' and the optional search/sorting, but does not disclose pagination behavior, default limits, or response structure. No contradictions with annotations.

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

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

A single, concise sentence with every word meaningful. The core action and optional capabilities are front-loaded 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?

Given the tool is a simple read-only list operation with full parameter documentation and safety annotations, the description covers the essentials. However, there is no output schema and the description does not hint at return format, pagination defaults, or sorting semantics, which an agent might need to correctly interpret results.

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

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

Schema description coverage is 100%, so all six parameters are already documented. The description's mention of search and sorting maps to existing parameter descriptions but does not add new meaning. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('List all audience segments') and clearly distinguishes this tool from siblings like list_contact_lists or list_contacts. The optional search and sorting mention adds functional scope 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?

There is no guidance on when to use this tool vs alternatives. No mention of when not to use it, no exclusions, and no reference to sibling tools. The context implies listing audience segments, but the description does not help an agent decide between this and other list-type tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect expectations. The description adds context that the senders are verified and scoped to the account, and that the response includes sender IDs, but it does not disclose additional behavior such as response shape, pagination semantics, or error handling. This is comparable to the calibration example where annotations lowered the bar and a 3 was appropriate.

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

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

The description is two sentences with no fluff. The first sentence immediately conveys the core purpose, and the second adds actionable guidance on how to use the result. Every word earns its place, making it highly concise and front-loaded.

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

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

With no output schema, the description partially covers return value semantics by stating that sender IDs are returned. Inputs are fully documented in the schema, annotations cover safety, and the description provides a use case. It lacks explicit mention of the response format, but for a simple listing tool this is not a significant gap, so it is nearly 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?

The input schema covers all three parameters (page, limit, api_key) with descriptions, and schema description coverage is 100%, so the description carries no extra burden. The description's mention of sender_id is not about this tool's parameters but about a downstream consumer, so it does not enhance parameter understanding. Baseline 3 applies.

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

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

The description specifically states the tool 'List all verified senders in your MailerCloud account', which clearly conveys both the action (listing) and the resource (verified senders). It also explains the practical purpose of the returned sender IDs, making the tool's role unambiguous even among many siblings.

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

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

The description gives clear context: use this tool when you need sender IDs for creating campaigns, as it says 'Use the returned sender IDs when creating campaigns with the sender_id parameter.' It does not explicitly compare to alternatives, but there is no competing sibling tool for sending senders, so this context is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description carries no additional behavioral disclosure. It doesn't mention pagination behavior or return format. Since annotations cover the safety profile, the description adds minimal behavioral context but doesn't contradict the annotations.

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

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

The description is a single, clear, front-loaded sentence with no unnecessary words. It conveys the essential purpose without any 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 list operation with zero required parameters and full schema coverage, the description plus annotations are adequate. It doesn't explain pagination explicitly, but the schema covers page and limit parameters. The presence of no output schema is mitigated by the simplicity of the operation.

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

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

Schema coverage is 100%, with each parameter described in the schema. The description does not add any extra meaning about the parameters beyond their names and types. The pagination parameters (page and limit) are documented in the schema, so a baseline of 3 is appropriate given the full schema coverage.

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

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

Description clearly states the action (list), resource (tags), and scope (account). It is distinguishable from sibling tools like create_tag and list_custom_fields by naming 'tags' explicitly. However, it doesn't explicitly differentiate the pagination or scope from other list tools, which prevents a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention filtering, pagination scenarios, or situations where another listing tool (e.g., list_segments, list_custom_fields) would be more appropriate. The agent is left to infer usage.

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

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

The annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the 'all' scope and MailerCloud context but does not disclose pagination, ordering, or response details. It does not contradict the annotations.

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

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

The description is a single sentence with no filler, front-loading the verb and resource. Every word contributes to 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 simple, read-only list operation with zero required parameters and safety annotations, the description is complete enough. An agent can correctly invoke it without needing further behavioral context.

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

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

Schema description coverage is 100%: the only parameter, api_key, is already described in the schema. The description adds no additional parameter-level meaning, so the schema carries the semantic burden.

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

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

The description uses a specific verb ('List') and a clear resource ('email template categories'), and adds scope ('all in MailerCloud'). This distinguishes it from sibling list_* tools targeting other resource types.

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: whenever an agent needs all email template categories. However, it does not explicitly state alternatives or when not to use it, even though many sibling listing tools exist.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. However, the description adds no behavioral details about pagination, return structure, or how the api_key parameter is used, leaving potential execution behavior under-specified.

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, complete sentence with no wasted words. It is front-loaded with the action and resource, and includes the account scope inline. 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?

Given the tool's simplicity, the description is minimally viable, but it lacks any mention of return format, pagination behavior, or authentication handling. With no output schema, these details are left entirely to the agent's assumptions, so some important context is missing.

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

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

Schema descriptions already cover all three parameters (page, limit, api_key) at 100% coverage. The description adds no extra semantic meaning beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states the verb ('List') and the resource ('all webforms in your MailerCloud account'), which is specific and distinguishes it from sibling tools like list_webhooks or get_webhook. The scope is explicit and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where pagination is needed, nor does it contrast with related list/get tools. Usage context is entirely implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond listing, such as pagination behavior or authorization requirements. It neither contradicts nor enriches the annotations.

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

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

The description is a single clear sentence with no filler or redundancy. It is front-loaded with the action and resource, making it easy for an agent to parse quickly.

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

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

The tool is a simple list operation with well-documented parameters and comprehensive annotations. The only minor gap is the lack of explicit mention of pagination or return format, but these are implied by the parameters and not critical for correct invocation.

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

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

Schema description coverage is 100%, so all three parameters (page, limit, api_key) are documented in the schema. The description provides no additional meaning beyond what the schema already states, which matches the baseline for high 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 states a clear verb ('List'), a specific resource ('webhooks'), and scope ('all webhooks configured in MailerCloud'), which distinguishes it from sibling tools like get_webhook (single webhook) and create_webhook (creation). No ambiguity remains about what the tool does.

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

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

No guidance is provided on when to use this tool versus alternatives. Though siblings like get_webhook exist, the description does not mention them or any exclusion criteria. The context is implied by the tool name but not explicitly stated.

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

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

Annotations indicate this is a mutating action (readOnlyHint=false) but provide no other behavioral hints. The description doesn't disclose side effects such as whether scheduling is irreversible, whether it conflicts with existing schedules, or whether it requires prior validation. It adds little beyond the annotations, but the 'send immediately' hint is useful. Since annotations are minimal, description carries most burden, and it's only marginally better than nothing.

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

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

Two sentences, both essential. The action is stated upfront, and the key parameter instruction (omit scheduled_at) is front-loaded. There's zero fluff.

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

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

Given the simplicity of the tool (3 parameters, no output schema), the description covers the main usage intent. It doesn't mention errors, validation, or behavior when a campaign already exists or is currently unscheduled. However, with 100% schema coverage and a superficial task, it's adequate but could clarify whether scheduling overwrites previous schedule.

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

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

Schema description coverage is 100% with clear descriptions for all three parameters (api_key, campaign_id, scheduled_at). The description reinforces the meaning of scheduled_at ('omit for immediate send') but doesn't add any new field semantics beyond the schema. Baseline 3 is appropriate since the schema explains each parameter adequately.

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 states a clear verb-resource pair ('Schedule a campaign for sending') and distinguishes immediate vs. scheduled send. It's unambiguous, though it doesn't explicitly contrast with sibling tools like update_campaign (which could also modify send time), so it lacks explicit sibling differentiation.

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

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

The description implies when to use this tool: when you want to schedule or immediately send a campaign. It gives a clear usage rule for the optional parameter (omit scheduled_at for immediate send). However, it doesn't explicitly advise against using it in other cases (e.g., if campaign is already sent) or suggest alternatives like update_campaign for modifying campaign properties.

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

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

Annotations already indicate the operation is not read-only and not idempotent, and the description matches that by stating an email will be sent. It adds the useful context that this is a test delivery before the real send, but does not elaborate on side effects such as whether recipients receive actual email, rate limits, or if any state is changed beyond the annotation booleans.

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, well-constructed sentence that states the action, target, and timing with zero wasted words. It is front-loaded with the verb and object, making it easy for an agent to scan 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 straightforward tool with two required parameters, no output schema, and no nested objects, the description covers the core action well. However, it omits any note about return value or failure behavior, and there is no mention of prerequisites (e.g., campaign existing) or whether the test send affects campaign metrics, so the context is adequate but not fully 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?

The input schema has 100% description coverage for all three parameters, including required fields and the 'recipients' array. The description adds no additional parameter-level meaning, so a baseline score of 3 is appropriate given the schema already documents the parameters thoroughly.

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 ('Send'), a clear resource ('a test email for a campaign'), and states the purpose ('before the actual send'). It leaves no ambiguity about what the tool does and distinguishes it naturally from sending the real campaign email.

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

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

The phrase 'before the actual send' implies the tool should be used as a pre-flight check, giving some usage context. However, it does not explicitly state when not to use it or contrast it with alternatives like 'send_transactional_email' or 'schedule_campaign', so guidance is implied rather than explicit.

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

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

The description adds behavioral details about supported features and version differences beyond the annotations, which are minimal (all false hints). However, it does not disclose side effects, authentication requirements, or error behavior, so it partially carries the transparency burden but leaves gaps.

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

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

Three brief sentences with no filler. Each sentence provides essential information: core function, supported features, and version usage. Information is front-loaded and efficiently 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?

The description covers core functionality and version selection, but does not mention authentication, response format, or error handling. With 13 parameters and no output schema, more context could be expected, though the schema covers parameter details.

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

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

Schema description coverage is 100%, so all parameters are already documented. The description reinforces the connection between version and content types but adds little beyond what the schema states. Baseline 3 is appropriate.

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

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

The description clearly states the tool sends a transactional email via a specific API, distinguishing it from sibling tools like send_test_email or create_campaign. It also specifies supported content types and versions, making the purpose unmistakable.

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

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

It provides clear guidance on when to use API version 1.0 vs 2.0 based on content type, but does not explicitly state when to choose this tool over alternatives or exclude other tools. The context is clear but lacks explicit when-not guidance.

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

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

Annotations already indicate idempotentHint=true and readOnlyHint=false, so the safety profile is covered externally. However, the description adds no extra behavioral context, such as whether changes take effect immediately, whether repeated toggling has side effects, or any permissions required. It simply restates the operation without enriching beyond structured 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 concise sentence with no wasted words. It is front-loaded with the action and resource. However, it is perhaps too terse to satisfy deeper informational needs, but as a minimal purpose statement it is efficient.

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

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

For a simple toggle operation with fully documented parameters, the description is sufficient to understand the basic action. Yet it lacks any mention of operation effects, such as whether enabling/disabling impacts delivery or requires webhook revalidation. Given the simplicity, a modest score reflects minor gaps.

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

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

The input schema provides 100% coverage of parameters, including descriptions for 'active' and 'webhook_id'. The description adds no additional semantic detail beyond what the schema already states. Baseline of 3 is appropriate because the schema does the heavy lifting.

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

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

The description 'Enable or disable a webhook' uses a clear action verb and specifies the resource being acted on. It distinguishes itself from sibling tools like update_webhook by focusing specifically on toggling activation state, making the core 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention relationships to update_webhook, which might also handle status changes, or when to prefer this over create/delete webhooks. Usage context is entirely absent.

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

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

Annotations already provide the key behavioral signals: readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds the draft-only constraint, which is useful, but does not elaborate on side effects, permissions, or error conditions. Given the annotations cover safety, a score of 3 is appropriate.

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

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

The description is two short sentences with zero fluff. The essential constraint (draft-only) is front-loaded and the entire description is easily parsed by an agent. 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 simple update operation with comprehensive schema coverage and useful annotations, the description conveys the key business rule. It does not explain return values or required permissions, but given no output schema and the annotations covering safety, it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, so all three parameters (campaign_id, fields, api_key) are already documented in the schema. The description does not add extra meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states a specific verb 'Update' and resource 'campaign', and adds a critical scope restriction 'draft campaign'. This distinguishes it from sibling tools like create_campaign or schedule_campaign, making the tool's 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 explicitly states when the tool can be used ('Only draft campaigns can be updated'), which serves as a clear precondition. However, it does not mention alternatives or when not to use it beyond the draft restriction, so it stops short of full guidance.

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

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

The annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description states 'update' which aligns with these annotations, but it does not add context such as whether updates are reversible, what happens if fields do not exist, or any side effects beyond the operation itself.

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 filler. It is efficient and front-loads the essential purpose without unnecessary 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 relatively simple tool with full schema coverage and informative annotations, the description is sufficient for an agent to invoke the call correctly. It might benefit from a note on partial field updates or error behavior, but the current form is mostly complete.

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

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

Schema description coverage is 100%, with each parameter (fields, api_key, contact_id) already documented in the input schema. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description is clear: 'Update fields on an existing contact' uses a specific verb, resource, and scope. It distinguishes this tool from siblings like create_contact and delete_contact by explicitly stating 'update' and 'existing', though it does not elaborate on what specific fields can be updated.

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_contact or create_contact. There is no mention of prerequisites, edge cases, or situations where a different tool would be more appropriate. The intent is largely left to inference from the tool name.

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

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

Annotations already indicate non-read-only, idempotent, and non-destructive behavior. The description adds no additional behavioral context beyond the word 'Update', which aligns with the annotations. There is no contradiction, but also no extra value such as permission 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, tight sentence that gets straight to the point. Every word is meaningful, and there is no redundant information or filler. It is appropriately sized for the tool's simplicity.

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 update operation with comprehensive schema and annotations, the description provides sufficient context. The lack of an output schema is not an issue here. However, it does not mention any side effects or edge cases, which would make it fully 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?

The input schema fully describes all three parameters with clear descriptions (name, api_key, list_id). The description does not add any parameter-specific meaning, but schema coverage is 100%, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Update' and the resource 'name of an existing contact list', distinguishing it from create/delete/list operations. It is concise and unambiguous, though it does not explicitly mention that only the name is updatable, which is slightly implicit.

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 such as update_contact or create_list. No context, prerequisites, or exclusion criteria are provided; the description merely states the action without any situational 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?

Annotations already indicate readOnlyHint=false, idlepotentHint=true, and destructiveHint=false, so the mutation profile is covered structurally. The description adds a small scoping constraint with 'existing', but it does not explain update semantics such as partial versus full replacement, authentication 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 front-loaded sentence with no filler. Every word contributes to the core purpose, making it maximally concise without losing clarity.

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

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

The description is too sparse for a 5-parameter mutation tool with no output schema. It does not clarify whether updating is a partial field update or a full replacement, how the api_key parameter factors in, or what the response will contain. An agent is left to infer important call semantics from the schema alone.

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

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

All 5 parameters already have meaningful descriptions in the input schema, and schema description coverage is 100%. The tool description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description uses the specific verb 'Update' with the concrete resource 'existing email template', making the operation clear. The word 'existing' explicitly distinguishes it from creating a template via create_template, which is present in the sibling list.

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

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

There is no guidance on when to use this tool versus alternatives such as create_template or get_template. The description does not mention any exclusions, prerequisites, or conditions that would help an agent decide between this and related template tools.

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

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, so the description is not burdened with that. But the description adds no additional behavior: it doesn't say whether the update replaces the whole configuration or merges only provided fields, nor does it mention authentication requirements or side effects. It merely restates the 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, front-loaded sentence without filler. It loses some value from being overly terse, but as a concise statement it is acceptable.

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

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

For a tool that accepts a free-form 'fields' object and returns no documented output, the description is incomplete. An agent is not told what webhook settings can be updated, whether the operation is a PATCH-like partial update, or what the result will look like. The sibling operations and annotations don't fill these gaps.

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

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

The input schema describes all three parameters (webhook_id, fields, api_key) with brief descriptions, and schema coverage is 100%. The tool description itself says nothing about parameters, so it doesn't add meaning beyond the schema. The nested 'fields' object remains unconstrained, but the description offers no hints about valid keys.

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

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

The description states a specific verb ('Update') and resource ('existing webhook's configuration'), which distinguishes it from create, delete, toggle, and get webhook siblings. However, it does not articulate exactly what aspects of configuration can be changed, leaving some ambiguity relative to toggle_webhook which might also change configuration (e.g., enabling).

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 update_webhook versus create_webhook, toggle_webhook, or delete_webhook. The description neither states prerequisites nor defines scenarios, so an agent must infer the tool's role purely from its name.

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

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

Annotations already establish the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds a genuinely useful trait — the conditional create/update logic — which explains and is consistent with idempotentHint=true. However, it does not disclose a material behavioral detail: whether an update is partial (only provided fields change) or a full replacement (omitted fields like first_name/last_name are cleared). No contradiction with annotations.

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

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

A single sentence of about twelve words with zero filler. The core conditional behavior is stated immediately and completely, and every word earns its place. This is appropriate conciseness, not under-specification.

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 moderately simple tool (5 params, 2 required, full schema coverage, annotations covering safety and idempotency), the description covers the essential behavior. Remaining gaps: no indication of what the response indicates (whether the contact was created or updated) and no clarification of partial-update field semantics — both affect an agent's confidence in interpreting the call's effect. Adequate but with clear 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 100% — email, api_key, list_id, last_name, and first_name all have schema-level descriptions — so the baseline of 3 applies even though the tool description names no parameters. The tool description adds no param-level meaning beyond the schema, and the schema descriptions are terse but present. The description's job here is satisfied by the parameter descriptions in the schema.

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

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

The description states specific verbs (create/update) and a clear resource (contact), and it unpacks the 'upsert' concept in plain conditional terms rather than restating the tool name. It implicitly distinguishes the tool from the create_contact and update_contact siblings by describing the combined create-or-update behavior, though it does not name those siblings explicitly.

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

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

The conditional phrasing ('if it doesn't exist... if it does') implies the natural use case: call this when you want a contact to exist for an email and are unsure whether it is already present. However, there is no explicit guidance on when to prefer alternatives (e.g., batch_create_contacts for bulk creation, update_contact when the contact is known to exist, delete_contact when removal is intended). Usage context is present but only implied.

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