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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the write/non-idempotent profile is covered structurally. The description adds nothing on top of that — notably it doesn't say what happens when the phone number already exists (duplicate vs. error), which is the key behavioral unknown for a non-idempotent create.

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 eight-word sentence that front-loads verb, resource, channel, and identifier. No filler, nothing to trim.

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?

Annotations cover the safety profile and there is no output schema to explain. But for a mutation tool the description omits the duplicate-phone behavior and doesn't mention the account/bot scoping, leaving the agent to infer the main edge case. Adequate but with a real 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%, with clear per-parameter docs for phone (country code format), bot_id (source tool), and account (default). The description only restates the phone-number identifier, adding no format or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource+channel: 'Create a new WhatsApp contact by phone number.' This clearly separates it from read/update siblings like get_contact and set_contact_name. It stops short of naming any sibling or scope constraints, so a 5 isn't warranted.

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

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

No when-to-use or when-not-to-use guidance, no prerequisites, no mention of alternatives such as sendpulse_send_message or sendpulse_send_template for reaching a contact. Usage is only implied by the verb.

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=true, idempotentHint=true, and openWorldHint=true, so the safety profile is known. The description adds the observable effect of stopping bot messages, which is useful context, but it does not explain reversibility, permissions, or what state changes occur.

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 a single efficient sentence that is front-loaded with the action and includes the effect without any wasted wording.

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 two-parameter tool with rich annotations and no output schema, the description covers the core action and effect. However, it omits usage distinctions from related tools and leaves the required contact_id parameter undocumented, making it only minimally 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 50%, and the required contact_id parameter has no description in either the schema or the tool description. The description adds no meaning about how to identify the contact or what the account parameter defaults to, so it does not compensate for the coverage gap.

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

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

The description states a specific verb ('Disable') and resource ('a contact') and adds the intended effect ('stop receiving bot messages'). It is clearly distinguishable from sendpulse_enable_contact, though it does not explicitly name that sibling.

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 when the effect is desired but gives no explicit context or exclusions. Critically, it does not distinguish disabling a contact from sibling tools like sendpulse_pause_contact_automation or sendpulse_resume_contact_automation, leaving the agent to infer the difference.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, readOnlyHint=false, so safety and repeat-safety are covered. The description adds that the contact must be previously disabled, which is useful context beyond annotations, but says nothing about what 'enable' changes, permissions, or side effects on flows/automations.

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 zero waste. Appropriate length for a simple toggle operation.

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

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

Adequate for a simple state-toggle tool but incomplete: no output schema, no guidance on error cases (contact not disabled), no differentiation from sendpulse_resume_contact_automation, and no explanation of downstream effects of re-enabling a contact.

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 50%: account has a description, contact_id does not. The description adds no parameter detail. Baseline 3 applies since half the schema is documented and the rest is self-evident (contact_id is implied by the description's 'contact').

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 (re-enable) and resource (previously disabled contact). Clear purpose but does not differentiate from sibling sendpulse_disable_contact or sendpulse_resume_contact_automation, which an agent could confuse with this.

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

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

The phrase 'previously disabled' implies usage context (only valid for disabled contacts), but there is no explicit when-to-use guidance, no mention of the paired sendpulse_disable_contact sibling, and no error/precondition behavior if the contact isn't disabled.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds a bit by naming the categories returned (subscriber counts, message statistics), but says nothing about time ranges, pagination, or freshness of the stats.

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, which is appropriate for a simple two-parameter read tool. It is efficient though not especially information-dense.

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

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

For a read-only stats tool with no output schema and fully documented params, the description is minimally adequate. It omits any indication of what the statistics response contains structurally or over what period the counts are computed.

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%: bot_id's source (sendpulse_list_bots) and the account default are documented in the schema itself. The description adds no parameter-level detail, 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 gives a specific verb ('Get') and resource ('subscriber counts and message statistics for a specific bot'), which is more precise than the title alone. It does not explicitly differentiate itself from sibling stats/list tools like sendpulse_list_bots, but the scope is clear.

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

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

There is no when-to-use guidance, no statement of prerequisites, and no mention of alternatives such as sendpulse_list_bots (which the schema references as the source of bot_id). Usage is only implied by 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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds no behavioral context beyond annotations — nothing about ordering defaults, pagination limits, rate limits, or what a missing contact yields. 'Message history' is the only added notion, and it is already implied by the tool name.

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

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

A single front-loaded sentence with zero filler. It is efficient, though its brevity shades into under-specification rather than disciplined conciseness.

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 five parameters, no output schema, and a one-line description, the definition is incomplete. Nothing tells the agent the shape of the returned message history, default ordering behavior beyond the schema default, or what happens with an unknown contact_id — information that must come from the description since no output schema exists.

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 80% (size, skip, order, and account are documented in-schema; contact_id is not), which lands at the baseline where the schema does the heavy lifting. The description adds nothing about parameter semantics, so it neither compensates for the undocumented contact_id nor explains how order/skip interact with pagination.

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 message history') scoped to a contact, which is clear enough to distinguish from write-oriented siblings like sendpulse_send_message. It does not, however, explicitly differentiate itself from sendpulse_list_chats or sendpulse_get_contact, leaving the agent to infer which retrieval endpoint applies.

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 contains no when-to-use guidance, no prerequisites, and no mention of alternatives such as sendpulse_list_chats or sendpulse_get_contact. The agent must guess whether this is the right tool for retrieving conversation data.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint:false, and openWorldHint, so the safety profile is covered. The description adds only that this is a WhatsApp contact lookup returning 'details'; it does not mention auth requirements, rate limits, or returned fields.

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

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

A single front-loaded sentence with no filler. It puts the verb and resource first and ends with the identifying parameter.

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

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

For a simple read-by-ID tool, annotations and the schema cover safety and parameter semantics. The description is sufficient for invocation, though it does not enumerate the contact details returned and there is no output schema to compensate.

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

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

Schema description coverage is 100%, and the schema already documents both id and account, including the brand_a default. The description adds no format, syntax, or usage detail beyond 'contact ID'.

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 ('Get') and resource ('WhatsApp contact's details'), and scopes retrieval by contact ID. The singular 'a contact' contrasts with sibling sendpulse_get_contacts_by_tag without needing to inspect either schema.

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

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

Gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. Usage is only implied by the required contact ID parameter and the name of the sibling list tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only the scoping detail ('all contacts' matching a tag) and says nothing about result size, pagination, or limits, which matters for a potentially unbounded list.

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 short, front-loaded sentence with zero filler. Nothing could be removed without losing meaning.

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

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

With no output schema, the description carries some burden for describing the return shape, and it only vaguely implies a collection of contacts. For a read-only lookup tool whose annotations and schema are complete, this is adequate but leaves return format and result-size behavior unspecified.

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 (tag, bot_id, account) are documented in the schema, including the pointer to sendpulse_list_bots for bot_id. The description only echoes the 'tag' parameter and adds no format or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Get') and resource ('contacts that have a specific tag'), which clearly separates it from sendpulse_get_contact (single contact) and sendpulse_list_tags. It does not, however, explicitly name or contrast with those 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?

There is no guidance on when to prefer this tool over sendpulse_get_contact or sendpulse_list_tags, and no prerequisites or exclusions are given. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is fully covered by structured data. The description's only addition is workflow context ('use this first'), not behavior such as pagination, result limits, or empty-list behavior. A 3 reflects added value on top of already-rich annotations.

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

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

Two short sentences, zero waste, with the purpose front-loaded and the workflow hint immediately after. Nothing to trim.

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, zero-required-param list tool with full schema coverage and annotations covering the safety profile, the description is essentially sufficient. Minor gap: no hint about the shape of the returned items beyond 'bot IDs' despite there being no 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 coverage is 100% and the single 'account' parameter already carries its own description with default and the note that only brand_a is configured. The description adds nothing beyond the schema, so baseline 3 applies.

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

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

States a specific verb (List) and resource (connected WhatsApp bots) with clear scope ('for an account'). No sibling tool lists bots, so an agent can route here without ambiguity versus sendpulse_list_chats, sendpulse_list_flows, or sendpulse_get_bot_stats.

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

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

Explicit sequencing guidance: 'Use this first to get bot IDs,' which tells the agent this is a prerequisite discovery step. It stops short of naming when-not-to-use or which tools consume the returned IDs, so it's clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds only the 'active' filtering qualifier, which is meaningful scope information, but does not cover pagination, result volume, or rate limits.

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; the scope qualifier ('active') comes before the resource qualifier. Nothing to trim.

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

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

No output schema exists, so the description is the only place to learn what a 'chat' entry contains or whether results are paginated, and it says nothing about either. For a simple read-only list tool with full schema coverage this is adequate but leaves a real 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 coverage is 100% and both parameters (bot_id, account) are already documented in the schema, including the derivation hint for bot_id. The description adds nothing about parameter formats or defaults, so baseline 3 applies since the schema carries the load.

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 ('List all active chats') scoped to a WhatsApp bot, which cleanly separates it from sendpulse_get_chat_messages. It does not, however, explicitly name a sibling or state what is excluded from 'active', so differentiation is implied rather than stated.

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 call this versus sendpulse_get_chat_messages or sendpulse_list_bots. The bot_id description implies a prerequisite in sendpulse_list_bots, but the description itself offers no usage 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 readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description only adds the scoping fact that results are per-bot; it says nothing about ordering, result size, or what happens if the bot has no flows.

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. Nothing is wasted.

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

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

For a simple read-only list tool with full schema coverage and complete safety annotations, this is nearly sufficient. Only pagination/return-shape detail is missing, and no output schema exists to cover it.

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

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

Schema description coverage is 100% and the bot_id description even cross-references sendpulse_list_bots, so the schema carries the parameter burden. The description adds no syntax or format detail beyond that baseline.

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

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

States a specific verb (List) and resource (automation flows) with scope limited to a bot. It does not explicitly differentiate itself from siblings like sendpulse_run_flow or sendpulse_list_triggers, but the 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 on when to use this versus alternatives such as sendpulse_run_flow or sendpulse_list_triggers, and no preconditions beyond the implicit need for a bot_id. Usage is only inferable from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the safety profile is fully covered structurally. The description adds no behavioral context beyond restating that it lists tags — no note on scope (all tags vs paginated), permissions, or whether tags are bot-level.

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 or redundancy. Every word contributes to identifying the operation and its scope.

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

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

For a simple read-only list tool with full schema coverage this is minimally adequate, but with no output schema the agent gets no hint about the return shape (tag names/ids) and the description omits any relation to sibling tag tools.

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

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

Schema description coverage is 100% for both parameters, including the hint that bot_id comes from sendpulse_list_bots, so the schema carries the semantics. The description adds nothing about the parameters, which is acceptable at full coverage but warrants only the baseline.

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

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

States a specific verb ('List') and resource ('contact tags') with an explicit scope ('defined for a bot'). It is clear enough to distinguish from most siblings, though it does not name the nearest alternatives (sendpulse_list_variables, sendpulse_get_contacts_by_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?

Provides no when-to-use or when-not-to-use guidance. It does not tell the agent the prerequisite (a bot must exist) or point to the closely related sendpulse_get_contacts_by_tag / sendpulse_set_contact_tags alternatives, so selection rests entirely on the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the full safety profile is covered structurally. The description adds only the notion that results are keyword triggers scoped to a bot's flows; it says nothing about return shape, pagination, or whether triggers span multiple flows.

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 with zero filler, front-loading the action and object. Nothing is repeated from the name or title in a wasteful way.

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, two-parameter list tool with complete annotations and full schema coverage, the definition is nearly sufficient. The only modest gap is that it does not indicate what a trigger entry contains or whether results are paginated, though no output schema exists to carry that.

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

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

Schema description coverage is 100% and both parameters (bot_id, account) are fully documented in the schema, including the 'from sendpulse_list_bots' provenance hint and the single-account default. The description adds no syntax or constraint beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb and resource ('List all keyword triggers') and scopes them to 'a bot's flows', which separates it from sendpulse_list_flows and sendpulse_run_flow_by_trigger at a glance. It stops short of explicitly naming a sibling for contrast, so it lands at clear-but-undifferentiated.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of prerequisites (such as obtaining bot_id from sendpulse_list_bots). The only routing signal is the implied link to flows, which the agent must infer.

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=false, so the safety profile is fully covered. The description adds only the scoping detail that variables belong to a bot, contributing little beyond the structured fields.

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

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

A single front-loaded sentence with no filler or redundancy. 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?

Adequate for a simple read-only list tool with rich annotations and no output schema. However, it omits the return shape (e.g. whether variables come with IDs/names) and does not flag the required bot_id dependency, leaving 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?

Schema coverage is 100%; the schema explains bot_id's origin (from sendpulse_list_bots) and the account default. The description provides no parameter detail, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (custom contact variables scoped to a bot), which is clearly distinct from siblings like sendpulse_list_tags or sendpulse_list_bots. It stops short of explicitly differentiating why an agent would pick this over those other list tools.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as sendpulse_set_contact_variable (the write counterpart). The agent must infer that this is the read side of that pair.

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, idempotentHint=false, and openWorldHint=true, so the agent knows this is a non-destructive, non-idempotent mutation. The description adds that the pause has a bounded duration and covers *all* flows, but says nothing about what happens after the timer expires, whether in-flight messages are halted, or whether re-pausing extends the window.

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

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

One tightly written sentence; the core action and its temporal scope are front-loaded before the illustrative example. Nothing is wasted.

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 3-param mutation with annotations covering the safety profile and no output schema, the definition is adequate but leaves gaps: the undocumented contact_id, post-expiry behavior, and interaction with the resume sibling are all unaddressed.

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

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

Schema coverage is 67%: 'minutes' and 'account' are documented in-schema, but 'contact_id' is a bare string with no description in either place. The description restates the time-bound meaning of 'minutes' but adds no format, identifier-shape, or default-value 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 (pause), resource (automated flows), and scope (all flows for one contact, time-bounded). It's clearly distinguishable from sendpulse_disable_contact (permanent disable) and sendpulse_resume_contact_automation. It does not name the resume sibling explicitly, so it falls just short of 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 parenthetical '(e.g. while a human agent is handling the chat)' supplies a concrete when-to-use scenario, which is more than most siblings offer. It stops short of naming the resume counterpart or stating when *not* to pause (e.g. already-paused contacts).

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 destructiveHint=true and idempotentHint=true, but the description adds nothing about irreversibility, permissions, or side effects. With destructive annotation, the description should warn or clarify. It merely restates the action.

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?

Extremely concise single sentence, front-loaded with the action. No extraneous words.

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

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

For a destructive mutation tool with no output schema and incomplete parameter documentation, the description is inadequate. It fails to address what happens if the tag doesn't exist, required permissions, or the response format.

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 67% – tag has a description, contact_id and account do not. The description adds no new parameter meaning beyond the schema. Baseline 3 is appropriate for moderate 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?

Clear verb 'Remove' and resource 'tag from a contact', specific enough to distinguish from siblings like set_contact_tags and get_contacts_by_tag. Missing detail about which tag/contact identifier but core purpose is clear.

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

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

No guidance on when to use this versus alternatives like set_contact_tags (which replaces all tags). No mention of prerequisites or exclusions. Implied usage only.

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

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

The annotations already declare this is a non-read-only, idempotent, non-destructive operation. The description adds one useful behavioral detail beyond the annotations: it cancels any active pause. It does not contradict the annotations, but it also does not disclose permissions, rate limits, or side effects beyond the pause cancellation.

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 filler, and it front-loads the core action before the side effect. 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 mutation tool with annotations covering the safety profile and no output schema, the description states the action and its key side effect. It is nearly complete, though it could say more about when to choose it over pause/enable/disable or run_flow alternatives.

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

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

Schema description coverage is only 50%: the account parameter has a description in the schema, but contact_id has none. The description says 'for a contact' but adds no format, constraint, or semantic detail beyond that, and it does not mention the account parameter or its default.

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: 'Resume automated flows for a contact.' It is clear what the tool does and implies the inverse of the sibling pause tool, but it does not explicitly name that sibling or otherwise differentiate itself from alternatives such as run_flow.

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 'cancelling any active pause' implies this tool is used when a contact's automation has been paused, which gives some usage context. However, it provides no explicit when-to-use guidance, no when-not-to-use guidance, and no alternative tools 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 declare the safety profile (readOnly=false, idempotent=false, openWorld=true, destructive=false), so the description does not need to restate those. But it adds nothing else: no mention of side effects on the contact, how external_data is consumed, or whether re-running enqueues duplicates for a non-idempotent 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 or repetition, which is efficient. It is arguably under-specified for a mutation tool, but nothing is wasted.

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 non-idempotent, open-world mutation that injects a nested external_data object and has no output schema, the description is too thin. It provides no side-effect information, no sibling routing, and no explanation of the contact_id parameter.

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 75%, so most parameters are already documented in the schema (including external_data and flow_id's reference to sendpulse_list_flows). The description adds no parameter meaning of its own, which is acceptable at this coverage level, though the undocumented contact_id remains unexplained in both places.

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 ('Trigger'), resource ('automation flow'), and target ('for a contact'), which is more than a tautology. However, it never distinguishes itself from the very similar sibling 'sendpulse_run_flow_by_trigger', so an agent cannot tell the two apart from the description alone.

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

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

No guidance on when to use this versus sendpulse_run_flow_by_trigger or sendpulse_resume_contact_automation, no prerequisites, and no note on required contact/flow state. The agent must infer usage entirely.

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

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

Annotations disclose openWorldHint=true and idempotentHint=false, but the description does not warn that triggering a flow initiates outbound automation (messages to a real contact) or that repeat calls will re-trigger the flow. For a non-idempotent, open-world side-effecting tool this is a meaningful omission.

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

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

A single tight sentence with the action front-loaded and no filler. It is concise, though it trades away detail that would have been useful.

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

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

With no output schema and a non-idempotent, open-world side-effecting action, the description should say what triggering actually does (sends automated messages, injects external_data as dynamic variables) and what happens on retry. None of that is present.

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

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

Schema coverage is 75%, so the schema already documents account, trigger_keyword, and external_data; only contact_id is undocumented in either place. The description mentions contact and keyword but adds no format, sourcing, or validation 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 ('Trigger') plus resource ('automation flow') and the mechanism ('keyword trigger'), which is clear. However, it never distinguishes itself from the sibling sendpulse_run_flow, so an agent cannot tell which of the two to pick from the description alone.

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

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

No when-to-use guidance, no prerequisites, and no mention of the closely related sendpulse_run_flow or sendpulse_list_triggers alternatives. The agent must infer usage from the name rather than the description.

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, openWorldHint=true and idempotentHint=false, so the safety profile is covered structurally. The description adds only that it targets 'all bot subscribers' and can be scheduled; it says nothing about irreversibility of a sent broadcast, rate limits, partial-failure behavior across recipients, or permission requirements, which is a notable gap for a non-idempotent outbound send.

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

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

A single tight sentence with the core action front-loaded and optional capabilities trailing. No wasted words or redundant restatement of the title.

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

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

This is a non-idempotent, open-world mutation with six parameters, two of them nested free-form objects (messages and filter) whose inner structure is undefined by the schema, and no output schema. The description explains neither the expected shape of a message object nor what a send returns, so an agent lacks the information needed to invoke it confidently.

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

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

Schema description coverage is 100%, so the schema already documents title, bot_id, filter, account, send_at and messages, and the description only echoes send_at and filter. Baseline 3 is appropriate; the description contributes no additional syntax or format 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 ('Send a broadcast message to all bot subscribers') and adds scope ('all bot subscribers') that separates it from point-to-point tools like sendpulse_send_message. It stops short of naming or contrasting with the closest sibling, sendpulse_send_template_campaign, which shares a similar broadcast shape.

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?

'Optionally schedule with send_at or filter recipients' hints at the situations the optional parameters serve, so usage is implied. However, there is no explicit guidance on when to choose this campaign send over sendpulse_send_template_campaign or per-contact sendpulse_send_message, and no stated prerequisites for broadcast sends.

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 readOnly=false, openWorld=true, idempotent=false, destructive=false, so the safety profile is largely covered. The description adds the genuinely useful operational constraint of the 24-hour session window, which annotations cannot express. It stops short of describing delivery/failure behavior or rate limits.

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

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

Three short sentences, front-loaded with the action, then the constraint, then the fallback tool. Every sentence carries distinct, non-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?

With no output schema, the description need not explain returns, and the annotations cover mutation safety. The critical eligibility rule is disclosed, making this nearly complete, though a note on failure behavior inside/outside the window would close the remaining gap.

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

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

Schema description coverage is 100% and the nested message object's type enum, text, and url fields are all documented in the schema, so the baseline is 3. The description adds no parameter-level detail (e.g. which message types consume the window) 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?

States a specific verb (send) and resource (message to a contact), and explicitly distinguishes itself from sibling sendpulse_send_template by naming it. An agent can pick between them without opening either schema.

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

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

Gives an explicit eligibility condition (only within the 24-hour messaging window after the contact last messaged) and names the alternative tool plus the exact condition (outside that window) that selects it. No inference required.

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

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

Annotations cover the safety profile (non-readonly, non-idempotent, non-destructive, open-world), so the description is free to add genuinely new context: the 24-hour-window bypass and the external Meta Business Manager approval prerequisite. It does not describe delivery/failure behavior, but the key gating constraint is disclosed.

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

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

Three short sentences, zero filler, with the core action front-loaded and constraints following. Every sentence carries distinct 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?

With no output schema, an agent still lacks return-value detail, but the description covers prerequisites and channel constraints adequate for invoking the tool correctly. Coverage of failure modes (rejected template, unapproved name) is the only real 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 all five parameters are already documented in the schema. The description adds no syntax or format detail for template_name, language_code, or components beyond what the schema states, so the 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?

States a specific verb and resource: 'Send a pre-approved WhatsApp template to a contact.' Clear on its own, but does not differentiate from close siblings like sendpulse_send_template_by_phone or sendpulse_send_template_campaign, which an agent must distinguish by name alone.

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

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

'Works outside the 24-hour window' is a concrete usage condition that implicitly selects this tool over sendpulse_send_message for out-of-window outreach, and the Meta approval requirement is stated. It stops short of naming alternative tools or stating when-not to use it.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds only that the template must be pre-approved and that the channel is WhatsApp. It says nothing about message delivery semantics, failures, duplicate sends (relevant given idempotentHint=false), or rate limits.

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

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

A single well-formed sentence with the differentiator front-loaded. No filler and nothing that should be pushed later.

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 a 6-parameter mutating tool with no output schema, the description covers the core intent but omits the components/template-variable story and any hint of the result of a send. Adequate to select the tool, thin on how to invoke it fully.

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 67%, so several parameters are documented inline (phone, bot_id, template_name, account). The description reinforces the phone-centric usage but does not clarify the opaque 'components' array (required for template variables) or the language_code default, which are the least self-evident inputs.

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

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

Specific verb (Send) plus resource (pre-approved WhatsApp template) and the distinguishing mechanic: direct-by-phone without a contact ID. This implicitly separates it from the sibling sendpulse_send_template, though it never names that sibling 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?

Usage is implied by the phrase 'without needing a contact ID' — an agent can infer this is the path when it only has a phone number. However, there is no explicit when-to-use/when-not statement and no named alternative to route between.

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

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

Annotations already declare non-idempotent, readOnly=false, openWorld=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact: the send fans out to ALL bot subscribers, making it a mass broadcast rather than a targeted message. It says nothing about rate limits, whether the send is reversible, or account scoping.

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 containing verb, resource, recipient scope, and campaign framing with zero filler. Nothing can be trimmed without losing information.

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

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

For an 8-parameter, non-idempotent mass-send tool with nested objects and no output schema, the description is too thin. It omits scheduling semantics (send_at), recipient filtering via filter, template variable/media handling via components, and the single configured account, all of which matter 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?

With 8 parameters, nested objects, and 88% schema description coverage, the schema already documents title, bot_id, filter, account, send_at, components, language_code, and template_name. The description adds no syntax, format, or constraint detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description gives a specific verb (send), a specific resource (pre-approved WhatsApp template), and a specific scope (all bot subscribers as a campaign). It implicitly distinguishes itself from sendpulse_send_template and sendpulse_send_template_by_phone, which target individual recipients, but it never names those 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?

It states what the tool does but not when to choose it over sendpulse_send_campaign, sendpulse_send_message, or the single-recipient template tools. No prerequisites, no exclusions, and no conditions are given; the agent must infer broadcast-vs-single usage from 'all bot subscribers'.

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, and openWorld=true, so the safety profile is covered structurally. The description adds nothing beyond the purpose line: no note that an existing name is overwritten, no auth/account scoping (the account param defaults to the single configured brand_a), and no rate-limit or failure context.

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

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

A single, front-loaded sentence with no filler, which is appropriate for a narrow setter. It is efficient, though the terseness contributes to the transparency and parameter gaps noted elsewhere.

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 three-parameter setter with annotations covering the safety profile and no output schema, the definition is minimally workable. It omits what the tool returns or confirms, how it behaves on an invalid contact_id, and any account/scope caveats the agent would need.

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 67%: name and account are documented in the schema, but contact_id has no description anywhere. The description does not compensate by clarifying what contact_id refers to (WhatsApp contact identifier) or the account default, leaving one parameter semantically thin.

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 (Update) and resource (display name of a WhatsApp contact in SendPulse), which separates it from cousins like sendpulse_set_contact_variable and sendpulse_set_contact_tags. It stops short of explicitly naming a sibling, so it is clear but not maximally differentiated.

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 versus set_contact_variable, set_contact_tags, or create_contact, and no prerequisites are stated. The agent must infer usage entirely from the name and description.

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 disclose the full behavioral profile: readOnlyHint=false (mutation), idempotentHint=true, destructiveHint=false, openWorldHint=true. The description adds nothing beyond this—it doesn't say what happens to tags already on the contact, whether new tag names are auto-created, or whether the contact must exist.

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; every word earns its place and the action is immediately clear.

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

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

For a simple non-destructive mutation, annotations carry the safety profile and no output schema is needed, so the core is adequate. But it omits tag-creation semantics, contact-existence behavior, and routing against remove_contact_tag, leaving real gaps for an agent choosing among tag-related siblings.

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 67%: 'tags' and 'account' carry schema descriptions, while 'contact_id' is undocumented. The description's 'one or more tags' merely echoes the array type the schema already expresses, so it neither compensates for the coverage gap nor adds 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?

States a specific verb ('Add') and resource ('tags to a contact'), which is clear enough to act on. It does not, however, differentiate itself from the closely-named sibling sendpulse_remove_contact_tag or explain how it relates to 'set' (given the tool name is set_contact_tags).

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

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

No when-to-use guidance, no prerequisites (e.g., must the contact already exist?), and no reference to alternatives such as remove_contact_tag for the inverse operation. The agent must infer usage purely from the name.

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

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

Annotations declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false, which already tell the agent this is a safe, repeatable mutation. The description adds no behavioral context beyond 'set' – it doesn't disclose what happens to unspecified variables, whether variables must pre-exist, or any constraints. It meets the minimum bar thanks to annotations but adds little.

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 is front-loaded with the action and resource. No wasted words.

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

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

For a mutation tool with no output schema and only 67% schema coverage, the description is minimal. It states what it does but omits whether variables must be pre-created, how conflicts are resolved, and what the response looks like. Sufficient to attempt a call but incomplete 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 coverage is 67%, with the variables array and its sub-properties documented in the schema. The description adds no parameter details – it doesn't clarify whether 'id' or 'name' should be prioritized, what value types are accepted, or how multiple variables are handled. Baseline 3 given moderate schema coverage.

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

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

States a specific verb (Set) and resource (contact variables), clearly distinguishing it from siblings like set_contact_tags and set_contact_name. It's clear what the tool does, though it doesn't explain the relationship to list_variables or how variables are identified.

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 like sendpulse_set_contact_tags or sendpulse_list_variables, nor does it mention prerequisites such as needing existing variable definitions. 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.