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

Annotations only give the generic flag set (non-read-only, non-idempotent, non-destructive), which understates real impact. The description adds the crucial behavioral fact that adding contacts can fire the organization's active automations and send messages — a non-reversible external side effect an agent must know before calling.

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 tight sentences: the operation and its additive nature come first, the side-effect warning second. Every clause carries information and nothing is padded.

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 two-parameter mutation with no output schema, the description covers the key risk (automation-triggered messages) and the additive semantics. It omits whether the call returns counts or errors on invalid contact ids, but with no output schema that omission is minor.

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 (the list uuid and the contact_ids array with minItems 1 and provenance 'from list-contacts') are already documented. The description adds no format, batching, or limit detail beyond that, 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 concrete verb+resource ('Add contacts to a list') and clarifies the additive semantics with 'keeping their other memberships', which implicitly distinguishes it from remove-contacts-from-list and from any replace-style operation. It does not name a sibling explicitly, so it falls just short of the top tier.

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 named alternative. The sentence about starting automations describes a consequence of invoking the tool rather than a condition for choosing it over remove-contacts-from-list or a tag-based approach.

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 mutation/non-idempotent profile is covered. The description adds genuinely useful context beyond that: tagging can trigger active automations that send messages, a side effect not derivable from 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?

Two tight sentences, zero waste. The core action is front-loaded first, and the side-effect warning follows immediately.

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 two-parameter mutation with full schema coverage and no output schema, the description supplies the key missing piece: the automation/message-sending side effect. It could say more about failure modes (e.g., invalid tag id), but it is largely 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 both 'id' and 'contact_ids' documented, including a helpful pointer that contact ids come from list-contacts. The description adds nothing 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 gives a specific verb+resource ('Add a tag to contacts'), so an agent immediately knows the operation. It does not explicitly name its sibling remove-tag-from-contacts, but the direction of the operation 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?

There is no guidance on when to use this tool versus alternatives such as add-contacts-to-list or remove-tag-from-contacts, and no preconditions are stated. Usage must be inferred entirely 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 cover the safety profile (non-read-only, non-destructive, non-idempotent). The description adds meaningful context beyond them: the output lands in `draft` state and the source campaign is left untouched, which is exactly what an agent needs to avoid surprising 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?

A single tight sentence with the action front-loaded and the rationale trailing. No filler.

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

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

For a one-parameter mutation with annotations covering safety and no output schema, the description is nearly sufficient. It could note that the returned draft is a new id the caller should capture, but that 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?

One parameter with 100% schema description coverage, so the schema already documents `id` as the in-app campaign UUID. The description adds nothing about it; 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 (copy/clone), the exact resource (an in-app campaign), and the resulting state (a new draft). An agent can distinguish it from create-in-app-campaign and get-in-app-campaign without opening a 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?

The 'to rework a live or ended one without touching it' clause gives a concrete use case and implicitly explains why you'd clone rather than update. No alternative siblings are named explicitly, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description usefully adds that the result is an editable copy inside the org's templates, which signals the created resource is a working copy rather than the source. It does not address that repeated calls are non-idempotent (would create duplicates) or any permission requirements.

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

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

A single well-formed sentence with the action verb front-loaded and no filler. It is appropriately sized, though one clause describing the copy's destination and purpose is all it offers.

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

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

For a simple 2-parameter write tool with full schema coverage, complete annotations, and no output schema, the description covers what is needed to call it correctly. It could be stronger by clarifying how the copy relates to existing org templates, but nothing essential 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 description coverage is 100%, with both id and name documented, including the default behavior for name. The description adds no syntax or format detail 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 states a specific verb (copy) and resource (a gallery design) plus the destination (the organization's templates), so the operation is unambiguous. It does not explicitly name how it differs from create-template or clone-in-app-campaign, so it falls short of the 5-tier 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?

Usage is implied by the outcome clause ('where it can be edited and used by campaigns'), giving the agent a sense of why one would copy a gallery template. However, there is no explicit when-to-use guidance, no mention of prerequisites, and no named alternative such as create-template.

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=false and destructive=false, so the safety profile is partly covered. The description adds genuinely new behavioral context: creating a contact can trigger the organization's active automations, which may send messages — a side effect an agent would not learn from the annotations or schema.

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 core action and constraint, with no filler. Every sentence carries distinct information: purpose, identifier requirement, custom-field mechanics, side effect.

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, the description covers the key preconditions (identifier requirement, custom-field keying) and the important side effect of automation triggering. It omits permission requirements and any indication of what the created contact record returns, which are minor given none exist.

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 71% and the schema lists zero required parameters, so the description's 'at least one of email/phone_number/external_id is required' fills a critical gap. It also explains that `properties` keys must match the field keys returned by list-contact-properties, adding meaning beyond the schema's generic 'Custom field values' note.

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 ('Create a contact') and immediately adds scoping detail about identifiers and custom fields. It does not explicitly contrast with siblings like update-contact, but the create action is unambiguous against a family of get-*/update-* tools.

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

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

The 'at least one of email, phone_number or external_id is required' clause is a real usage constraint, and it routes the agent to list-contact-properties for custom field keys. However, it gives no guidance on when to choose create-contacts vs. update-contact or add-contacts-to-list, leaving alternatives to inference.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), lowering the bar. The description adds a genuinely non-obvious behavioral fact not present in any structured field: field_key and data_type are permanently immutable once created. It does not cover what happens on a duplicate field_key or what the call returns, so it is not a 5.

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 filler, and the irreversible constraint is front-loaded as the second sentence where an agent will read it before filling the schema.

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 5-parameter creation tool with no output schema, the description covers the single most consequential gotcha (immutability) but omits which params are required, duplicate-key behavior, and return shape. Annotations carry the safety profile, so this is minimally adequate rather than 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 60%, with field_key (pattern/example), data_type (enum + default), and fallback_value documented in the schema, but display_name and description undocumented. The description only touches field_key and data_type, and does so for immutability rather than semantics, so it roughly matches the baseline rather than compensating for the 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 verb+resource is specific (define a custom contact field), and it is clearly distinct from create-contact, create-tag, and create-event among the siblings. It stops short of explicitly contrasting with update-contact-property, so an agent still has to infer the boundary from the 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?

There is no when-to-use statement, no mention of prerequisites, and no named alternative such as update-contact-property for existing fields. The only guidance is a post-hoc immutability warning, which is not usage 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 non-read-only, non-destructive, non-idempotent. The description adds meaningful context beyond them: everything is optional for stepwise drafting, the result is saved as a draft, and critically that this server cannot send or schedule. It stops short of describing rate limits or return shape.

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?

Four tight sentences, front-loaded with the core action, and each subsequent sentence carries distinct information (optionality, audience composition, draft state, no-send constraint). Slightly dense 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 10-parameter, zero-required creation tool with annotations but no output schema, the description covers the key behavioral facts an agent needs (draft-only, no scheduling, audience math). It does not say what the call returns, which is a minor gap given 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 coverage is 80%, so the baseline is 3; the description earns above that by explaining the union semantics of the three audience arrays and pointing to list-lists/list-tags for valid IDs, which is beyond what the schema states.

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 ('Create an email campaign') and immediately scopes it as a draft-building tool, which cleanly separates it from sibling mutators like update-email-campaign, create-sms-campaign, and create-template.

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 real operational context: all fields optional for incremental building, the audience is the union of list_ids/tag_ids/segment_ids, and it routes to list-lists and list-tags for ID discovery. It lacks an explicit statement of when to prefer this over update-email-campaign or create-template, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful non-annotation fact — the event name is immutable after creation — but says nothing about auth requirements, failure modes (e.g. name collisions), or what the call returns.

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 tightly written sentences with zero waste; purpose is front-loaded and the immutability caveat follows. Nothing could be removed 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 a mutation tool with nested objects and no output schema, the schema carries most parameter detail and annotations cover safety. However, the description omits usage context, the meaning of the conversion setup, and any sense of what happens on success, leaving it adequate but thin.

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 75%, with the nested 'fields', 'conversion', and 'name' properties well documented in the schema itself. The description adds no parameter detail beyond the immutability note on name, and the untouched 'description' parameter is undocumented, so it does not compensate for the remaining 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?

States a specific verb and resource: 'Define an event type that apps can send and automations can react to.' This is clearly distinguishable from the read/update siblings (list-events, get-event, update-event) by implying creation, though it never names those siblings or explicitly contrasts with them.

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-tag or create-contact, and no stated prerequisites. The only constraint given ('The name cannot be changed later') is a behavioral caveat rather than usage direction, so an agent gets no routing help.

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 (not read-only, not destructive, non-idempotent). The description adds genuinely new behavioral context beyond those hints: the object is persisted as a `draft` and the server has no send/schedule capability, which an agent could not infer from the annotations. It doesn't cover failure modes or what happens on duplicate names, so it stops short of a 5.

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, all front-loaded: action first, then the draft state, then the server's limitation. No filler and 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?

For a 15-parameter nested tool with no output schema, the description covers the crucial lifecycle fact (draft, not sendable) and the schema carries the rest with 80% coverage and defaults. It could go further by noting that activation requires a follow-up update/dashboard step or flagging targeting requirements, but it is adequate.

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

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

Schema description coverage is 80%, so the schema itself documents nearly all parameters, including enum and default notes (e.g. display_rules defaults, priority semantics). The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

The description states a specific verb+resource ('Create an in-app message campaign') and names the exact channel, which cleanly separates it from the create-email-campaign, create-sms-campaign, and create-push-campaign 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 discloses an important constraint (the campaign lands as a draft and this server cannot send or schedule), which implies the tool is for authoring only. However, it never routes the agent between alternatives such as clone-in-app-campaign, create-template, or update-in-app-campaign, leaving the when-to-use decision 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 this is a non-destructive, non-idempotent write, so the safety profile is covered. The word 'empty' adds one useful behavioral fact (no contacts are populated at creation), but name-uniqueness rules, duplicate handling, and what is returned are not 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?

A single short, front-loaded sentence with no filler. It is efficient, though arguably under-specified rather than optimally concise.

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

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

For a create tool with no output schema and zero param documentation, the description is too thin — it leaves open whether the new list (and its ID) is returned and gives no parameter guidance, both of which an agent needs to chain calls correctly.

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

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

Schema description coverage is 0% for both parameters, and the description does not mention 'name' or 'description' at all. The agent learns nothing about the required name, length limits, or what the optional description is for.

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 and resource ('Create ... contact list') and adds the scope qualifier 'empty', which an agent can use to distinguish it from add-contacts-to-list. It does not explicitly differentiate itself from other create-* siblings, but the resource noun 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?

There is no when-to-use guidance and no alternative named. The natural follow-up tool (add-contacts-to-list) is never referenced, and nothing states that the list must be created before contacts can be added.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely non-obvious behavior: the campaign is only saved as a draft and cannot be sent or scheduled here, and audience targeting is a union across three id lists. It does not mention any permission/auth requirements or how duplicates across the id lists are resolved.

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?

Four sentences, front-loaded with the core action and audience semantics, then the draft state, then the send/schedule limitation. Every sentence carries distinct information; there is no filler.

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

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

For a mutation tool with 18 parameters, nested objects and no output schema, the description covers the lifecycle constraint (draft-only, no send) and audience resolution. It is slightly incomplete in that it never indicates what the call returns (e.g. whether an id is produced for later use), which matters because the description tells the agent the user must finish the workflow elsewhere.

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%, so the schema carries most of the load. The description adds real meaning for three parameters by defining the audience as a union of list_ids/tag_ids/segment_ids, which is not deducible from the individual schema entries. However, it says nothing about the other 15 parameters (priority, throttle_minutes, data_payload, action_buttons, etc.), so it does not fully 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?

States a specific verb+resource ('create a push notification campaign') and immediately scopes it: the audience is the union of list_ids, tag_ids and segment_ids, and the result is saved as a draft. This distinguishes it from create-email-campaign/create-sms-campaign/create-in-app-campaign siblings without the agent opening any 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?

Explicitly routes the agent to list-lists for lists and list-tags for tags, and states that segments are managed in the Arsel dashboard. It also states a hard when-not: this server cannot send or schedule the campaign, so the user must do that from the dashboard — an unambiguous limitation no sibling could imply.

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 supply the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description contributes beyond them: the result is saved as a `draft`, and the server cannot send or schedule it. This is meaningful lifecycle context an agent could not infer from the structured fields. It stops short of describing auth requirements or segment-size 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?

Four short sentences with the core action front-loaded and each subsequent sentence adding a distinct, non-redundant fact (audience union, ID resolution, draft state, sending limitation). No filler.

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

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

For a 7-param creation tool with no output schema, the description covers purpose, audience composition, how to source related IDs, the resulting state, and the crucial limitation that sending/scheduling happens elsewhere. An agent has everything needed to invoke it correctly and set user expectations.

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 already 86%, so the schema carries most parameter documentation (baseline 3). The description adds genuine meaning by explaining that the audience is the union of list_ids, tag_ids and segment_ids, which no single param description conveys, and points to the tools that resolve list/tag IDs.

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 channel-scoped resource ('Create an SMS campaign'), which immediately distinguishes it from the sibling create-email-campaign, create-push-campaign, and create-in-app-campaign tools. The follow-up sentence defines the tool's audience semantics, reinforcing exactly what this 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?

Gives concrete routing guidance for gathering inputs ('Find lists with list-lists and tags with list-tags; segments are managed in the Arsel dashboard') and explicitly states the boundary that this server cannot send or schedule. It does not contrast with update-sms-campaign or clone-style alternatives, but the when-to-use context is clear.

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=false, so safety basics are covered. However, the description adds no behavioral context beyond those annotations, such as whether duplicates are allowed or what happens on creation.

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 under-specified sentence. It is concise in form but lacks the substance needed for an agent to understand the tool, making it more of an under-specification than effective 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?

For a mutation tool with an output schema absent, the description does not explain what is returned, side effects, or error conditions. The annotations provide some safety context, but the overall definition remains too thin for reliable invocation.

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

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

Schema description coverage is only 50%, with the 'description' parameter undocumented in both schema and tool description. The description says nothing about the 'name' parameter or its constraints, failing to 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 'Create a tag.' restates the tool name and title almost verbatim, providing no additional purpose detail. While it identifies the action and resource, it is tautological rather than informative.

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 such as update-tag or add-tag-to-contacts. The description provides no context, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is covered. The description adds non-obvious behavior beyond that: the HTML is sanitized and an unsubscribe link is injected automatically, which tells the agent the stored result differs from input. 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?

Three short sentences, zero filler. The core action is front-loaded and the sanitization/unsubscribe behavior and the alternative-tool routing each earn their sentence.

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

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

For a two-parameter creation tool with annotations covering the safety profile and no output schema, the description covers action, side effects, and the alternative route. Only minor gaps remain, such as whether the created template returns an id.

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 only 50% (name has no description), but both parameters are simple and self-evident, and the description confirms the html parameter is the email body source. It adds the sanitization note but no format/size detail beyond the schema's 'Full email body HTML.'

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 ('Create an email template') plus the input modality ('from HTML'). It also names the sibling it is not (copy-gallery-template), so an agent can distinguish it from the other template tools without opening schemas.

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 routes the agent to copy-gallery-template for the alternative path ('To start from a professionally designed layout instead'), making the selection condition between the two tools unambiguous.

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. The description still adds real value by disclosing what comes back beyond a bare record: custom properties and suppression status, with a plain-language explanation of suppression.

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, front-loaded with the action and resource, with the return-payload detail appended rather than buried. No filler and nothing repeated from the annotations or schema.

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 usefully tells the agent what the call returns (custom properties and suppression). Missing only minor context such as behavior for an unknown id (error vs empty), which keeps it just short of full marks.

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 single uuid parameter is fully documented in the schema, so the baseline is 3. The description's "by id" adds no syntax or format 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?

States a specific verb and resource ("Get one contact by id") plus the notable contents of the response. The word "one" cleanly separates it from the sibling list-contacts, though it never names that alternative 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 required id ("get one contact by id"), but there is no explicit when-to-use guidance, no statement of prerequisites, and no pointer to list-contacts for looking a contact up by other fields.

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 structurally. The description adds nothing beyond that — no note on what is returned, error behavior for a missing id, or auth requirements.

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

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

A single front-loaded sentence with zero waste. It is efficient, though arguably terse to the point of under-specification rather than optimally concise.

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

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

For a simple one-param read tool with full schema coverage and complete safety annotations, the essentials are present. The gap is that no output schema exists, yet the description says nothing about what a property record contains.

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 schema documents the single "id" parameter as a UUID with a pattern. The description says "contact field" while the schema calls it a "property id," a minor terminology mismatch but no added syntax or meaning. Baseline 3 is appropriate when the schema does the work.

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 ("Get") and resource ("one custom contact field"), and "one" signals single-item retrieval rather than a list. It does not name or differentiate from the sibling list-contact-properties, so it falls short of 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?

There is no explicit when-to-use guidance, no mention of when to prefer get-contact-property over list-contact-properties, and no prerequisites. The single-item framing only weakly implies when it applies.

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 by structured data. The description adds one genuine behavioral detail — that the response includes delivery status — which is not in the annotations. That is useful but minimal, 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 front-loaded sentence with no wasted clauses. Minor grammar awkwardness ('one transactional emails message') slightly hurts readability but does not obscure meaning.

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

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

For a simple single-resource read with full annotation coverage and no output schema, the description is adequate: it identifies the resource and notes the delivery-status return value. It could be complete at 5 with a hint that the id comes from list-emails.

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 a single parameter with 100% schema description coverage (the schema itself documents the UUID id and its pattern), so the schema carries the semantic load. The description adds nothing beyond it, making the baseline 3 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 (get) and resource (one transactional email message) and adds scope ('one' plus delivery status), which clearly distinguishes it from list-emails and the campaign getters. It does not explicitly name a sibling to differentiate against, keeping it at a solid 4 rather than 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 gives no when-to-use or when-not-to-use guidance and never references alternatives such as list-emails or the SMS/push message getters. The single-retrieval scope is implied but never framed as a routing decision for the agent.

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. The description adds useful context by enumerating the returned fields, giving a sense of the object's scope. It does not cover auth requirements or any error/not-found behavior, so it 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 front-loaded sentence that states the action and its output scope with no filler. Every clause 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 single-param read tool with full annotation and schema coverage, the definition is essentially complete. Enumerating returned fields compensates for the absence of an output schema. Additional routing guidance would fully close the 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?

With only one parameter at 100% schema description coverage, the schema fully documents the required uuid 'id'. The description adds no syntax, format, or lookup guidance beyond implying a single campaign is retrieved, 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 (one email campaign), and the singular 'one' distinguishes it from list-email-campaigns. It also enumerates the object's fields (status, sender, subject, template, audience, schedule), so the agent knows what it retrieves. However, it does not name or differentiate from the sibling get-*-campaign 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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as list-email-campaigns for browsing or update-email-campaign for changes. The singular 'one' implicitly suggests it fetches a single known campaign, but nothing routes the agent between options.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing on top of that - no error behavior for missing ids, no note on what is returned. With annotations doing all the work and the description contributing zero additional behavioral context, a 2 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 short sentence with zero filler, front-loaded with the verb. It is efficient, though so terse that it borders on under-specification rather than being tightened prose.

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 trivial read-only single-record fetch, the annotations and 100%-covered schema carry most of the load, so the description is barely adequate rather than deficient. Still, with no output schema it could have said what an event record contains or how a missing id is handled, and the "event type" vs "event id" wording is a loose end.

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 single id parameter is fully typed as a UUID with a pattern and a description. The description adds no syntax or format detail beyond the schema. Per the rubric, one well-documented parameter with full coverage earns the baseline 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?

States a specific verb and resource ("Get one event"), and the word "one" implicitly separates it from the sibling list-events. However, it says "event type" while the schema's only parameter is "The event id", a small terminology mismatch that slightly blurs what is being fetched. No explicit sibling differentiation beyond the singular/plural contrast.

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 list-events, get-contact, or any other single-resource getter. No prerequisites, no mention of what happens with an unknown id. The agent must infer that an id is required to retrieve exactly one record.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description's one addition is that the response includes HTML content, which is genuine context beyond the annotations, though it says nothing about template size or other 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 eight-word sentence with the resource front-loaded and the notable return detail attached. No filler, no restatement of the title beyond what is needed.

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 the burden of describing the response, and it only mentions the HTML payload. For a single-record fetch tool this is minimally adequate but leaves the rest of the returned design shape undisclosed.

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 a single required 'id' parameter and schema description coverage is 100%, so the schema already documents it (type, uuid format, meaning). The description adds nothing about the id's expected form, which is acceptable given the schema 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 and resource ('Get one gallery design') and adds what comes back ('including its HTML'), which separates it from list-gallery-templates and copy-gallery-template by name. It never explicitly contrasts with get-template, though the gallery qualifier in the name does most of that work.

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 at all: nothing says this is for fetching a single template by id versus browsing with list-gallery-templates, nor when to prefer get-template over this. The agent must infer the 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is fully covered without the description. The description adds the shape of what comes back (status, layout, content, trigger, targeting), which is useful, but says nothing about failure behavior for an unknown id or whether the returned data is live or cached.

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 resource comes first and the returned fields follow. It is efficient, though the field list is a bare enumeration that could have been spent on routing guidance instead.

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 usefully summarizes the returned payload, and the annotations cover the read-only, idempotent profile. For a one-parameter getter this is nearly sufficient, with the only real gap being how the id is sourced.

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 the single id parameter, which the schema documents as a UUID with an explicit pattern, so the schema does the heavy lifting. The description never mentions the id or how to obtain one (e.g., from list-in-app-campaigns), adding nothing 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 one in-app campaign') and enumerates the data it returns (status, layout, content, trigger, targeting). The word 'one' implicitly contrasts with list-in-app-campaigns, but the sibling is never named, so differentiation is inferential rather than 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?

There is no statement of when to use this tool versus list-in-app-campaigns, update-in-app-campaign, or clone-in-app-campaign. The usage is only implied by the singular resource and the required id parameter, leaving the agent to infer the retrieval-by-id scenario.

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 covered externally. The description adds the return payload (contact count) and a cross-reference, but says nothing about missing-id errors, permissions, or auth needs. Adequate but not rich 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?

Two short sentences, zero filler, with the core behavior front-loaded and the cross-reference immediately after. Every clause 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 single-param read tool with no output schema, the description covers what is returned (the list plus its contact count) and how to get related data. Only error behavior for an invalid/nonexistent id is unaddressed, which 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 coverage is 100% (the single `id` param is documented as 'The list id'), so the schema carries the parameter meaning. The description refers to it as `list_id` rather than `id`, a minor naming mismatch that adds no new semantic detail.

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

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

States a specific verb and resource ('Get one contact list') plus the notable payload ('its contact count'), which distinguishes it from list-lists (plural) and list-contacts (members). An agent can tell what this returns without opening the 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?

Explicitly routes the agent to the alternative for members: 'To see its members, call list-contacts with `list_id`.' This is clear context for the most likely follow-up need, though it gives no guidance on when to prefer get-list over list-lists or get-contact.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the set of fields returned, not behavioral traits like error behavior or permission requirements, which is acceptable given 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?

A single front-loaded sentence with the verb and resource first and the field enumeration second. No filler, no repetition of the title, 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?

With no output schema, the description usefully names what the response contains (status, content, targeting, schedule), and annotations cover safety. For a one-parameter read tool this is largely complete, though it omits anything about failure modes or lookup scope.

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 the single 'id' parameter, so the schema already documents it as a UUID push campaign id. The description adds no format, constraint or meaning beyond what the schema provides, which is the expected baseline at full 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 ('Get') and resource ('one push campaign') and enumerates the returned facets (status, notification content, targeting, schedule). The resource name cleanly separates it from get-email-campaign, get-sms-campaign and get-in-app-campaign, though it never disambiguates against the nearby get-push-notification 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?

Usage is only implied: the phrase 'one push campaign' hints that this is the single-item counterpart to list-push-campaigns. There is no explicit when-to-use, no prerequisites, and no stated alternative for retrieving push notification data instead.

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

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

Annotations already carry the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds the response shape (progress plus per-row errors), which is genuinely useful, but says nothing about pagination, limits, or error/pending states.

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 that covers both the action and its return value. Nothing to trim and nothing misplaced.

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 one-parameter status tool with no output schema, the description usefully names what comes back (progress, per-row errors). It is nearly complete, though it omits behavior around job lifecycle states or large error sets.

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 a single self-describing UUID parameter, so the schema does the heavy lifting. The description adds no syntax, format, or sourcing detail beyond what the schema already provides; 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 (push-device import), and even names the return content: progress and per-row errors. There is no direct sibling for import jobs in the sibling list, so no differentiation is possible, which caps it at 4 rather than 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 mention of 'progress' and 'per-row errors' implies the tool is used to poll a previously-started bulk import, but it never states when to call it, prerequisites, or what alternatives exist. Usage 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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added behavior context is that the response includes delivery status, which is useful but thin.

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 resource and the returned attribute are both stated immediately.

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 single-parameter read tool with full annotation coverage, the definition is nearly sufficient, and mentioning 'delivery status' partially compensates for the absent output schema. It could say more about what fields accompany the status, but nothing critical for correct invocation is missing.

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

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

The schema documents the single 'id' parameter at 100% coverage including format and pattern, so the description rightly does not repeat it. Baseline 3 applies since the schema does the heavy lifting and the description adds no extra meaning about the 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'), resource ('transactional push message'), and cardinality ('one'), which separates it from list-push-notifications and from the campaign-level get-push-campaign. It never names a sibling explicitly, so it stops short of 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 word 'one' weakly implies a lookup-by-id as opposed to a list, but there is no statement of when to use this tool versus list-push-notifications or get-push-campaign, and no prerequisites. Callers must infer the usage scenario 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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds only the set of returned fields, not any behavioral context such as behavior for a missing/invalid id or whether the campaign is draft vs scheduled, so it is minimum-viable.

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 compact sentence with the verb and resource front-loaded and a tight field enumeration; nothing is padded or repeated.

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 single-id read with full annotation coverage and no output schema, the description does the useful extra work of listing the returned fields, which compensates for the absent output schema. It could go slightly further by noting how the id is obtained or what happens if it does not exist.

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 a single 'id' parameter whose schema description ('The SMS campaign id.') and UUID format/pattern are already 100% documented in the schema. The description adds no extra meaning about the id (e.g. where to obtain it), so baseline 3 applies.

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

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

The description states a specific verb and resource ('Get one SMS campaign') and enumerates the returned fields (status, content, sender, segment count, schedule), so the agent knows exactly what it retrieves. Sibling get tools differ by resource type, which the name makes clear, but the description itself never names or contrasts an 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?

Usage is only implied by 'Get one SMS campaign' — an agent infers it is for fetching a single campaign by id, most likely after list-sms-campaigns. There is no explicit when-to-use, no when-not-to-use, and no mention of the list/update siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description's only added behavioral value is revealing that the response includes delivery status; it says nothing about auth requirements, error behavior, or what happens with an unknown id.

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 states scope or content, and nothing needs to be trimmed or reordered.

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 one-parameter read-only getter whose annotations fully cover safety and idempotency, the description is nearly sufficient, especially since the mention of delivery status hints at the return content despite there being no output schema. Only the absence of sibling routing keeps it from being 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 coverage is 100% and the sole 'id' parameter is fully documented as a UUID with a pattern, so the schema carries the semantics. The description adds no format or lookup guidance beyond it, which is the expected baseline when schema coverage is high.

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 ('transactional sms message') scoped to a single record, and it names the returned payload ('delivery status'), which distinguishes it from sibling listing tools like list-sms-messages and campaign tools like get-sms-campaign. It stops short of explicitly naming those alternatives, so an agent must infer the single-vs-list distinction.

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

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

Usage is only implied: the singular 'one ... message' plus a required id makes it clear this is a fetch-by-id tool, but there is no explicit when-to-use statement, no prerequisites, and no routing to list-sms-messages or get-sms-campaign for the agent to choose between siblings.

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

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

Annotations already establish readOnlyHint, idempotentHint and destructiveHint=false, lowering the burden. The description still adds real value by disclosing the return shape (tag plus contact count) and pointing to the follow-up call for membership, which is exactly the information an agent lacks when no output schema exists.

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

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

Two sentences, both front-loaded with the important information and no filler. The output detail comes first and the routing hint second, which matches how an agent reads the definition.

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 trivial single-parameter read with no output schema, the description covers purpose, a return-value hint, and a next step. It omits what fields the tag object contains, but that gap is small given the low complexity.

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

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

Schema coverage is 100% and the single `id` parameter is fully documented as 'The tag id.', so the schema does the work. The description mentions 'tag_id' only in the context of the list-contacts call, adding no semantics for this tool's own parameter; baseline 3 applies.

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

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

The description opens with a specific verb+resource ('Get one tag') and adds the key payload detail (its contact count), which separates it from the bulk list-tags operation. It also names the sibling to use for a related-but-different need, so an agent can distinguish it without opening the 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?

It gives explicit routing for one adjacent task: 'To see who has it, call list-contacts with tag_id.' That is clear conditional guidance, but it never states when to use this tool versus list-tags when scanning for a tag by name, so the guidance is one-sided rather than complete.

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 this readOnly, idempotent, and non-destructive, so the safety profile is covered externally. The description adds a genuine behavioral fact beyond those annotations and beyond the schema: the returned payload includes the template's HTML, which is the only clue about response content given there is no output schema.

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 short sentence that front-loads the action and resource, with the payload detail placed where it is most useful. 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?

For a one-parameter read tool with annotations covering safety, this is nearly complete, and the HTML hint partially compensates for the absence of an output schema. Missing only error/not-found behavior and any statement about payload size for templates with large HTML.

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 single id parameter is fully documented (uuid with a pattern), so the description need not restate it. "one email template" only weakly echoes what the schema already makes clear, 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 pairs a specific verb ("Get") with a specific resource ("one email template") and clarifies scope with "one," distinguishing it from list-templates. It does not, however, contrast itself with the sibling get-gallery-template, so the agent must infer that this operates on stored user templates rather than gallery templates.

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 only implied: the single-id retrieval shape makes the intent obvious, but there is no explicit statement of when to reach for this over list-templates or get-gallery-template, and no mention of prerequisites such as needing a valid template id.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only that the result includes delivery status, a small but useful value-add beyond the annotations. No return format, not-found behavior, or rate limits are 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?

A single front-loaded sentence with no filler; every word contributes to identifying the resource and the returned content.

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

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

For a one-parameter read tool with full annotation coverage and complete schema documentation, the description is nearly sufficient; it even notes the delivery-status payload. It is slightly thin on how the result differs from list-whatsapp-messages, but no output schema is needed for return 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%, with the single id parameter fully documented (UUID format and pattern). The description adds nothing about the id 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?

States a specific verb (Get) and resource (transactional WhatsApp message) with singular scope, which contrasts reasonably with the sibling list-whatsapp-messages. It does not explicitly name or contrast the sibling that retrieves the same resource, so it stops short of 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 singular phrasing 'one ... message' implies it is used to fetch a single record, typically by id, but there is no explicit when-to-use, when-not, or comparison to list-whatsapp-messages or get-sms-message. Usage is implied rather than 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 already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral instruction beyond structured fields – presenting the returned ids/timestamps only on request – which is useful output-handling 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?

Two tight sentences, front-loaded with the core purpose followed by a presentation caveat. Nothing is wasteful, though the second sentence is a slightly tangential aside rather than essential task information.

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

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

For a read-only list tool with no output schema and fully documented params, the description conveys what is returned (property keys usable as merge tags) and how to surface them. Pagination behavior is left to the schema, which handles it adequately.

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 fully documents after/before/limit/search, so the baseline is 3. The description adds no parameter-level meaning (e.g. it never mentions searching or pagination), so it neither compensates nor detracts.

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) plus the exact resource (organization's custom contact fields) and clarifies what those fields are: the keys a contact's `properties` can hold and merge tags in messages. This clearly distinguishes it from the singular get-contact-property / create-contact-property 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?

Usage is only implied – the agent can infer this is the way to enumerate available contact property keys, but no explicit when-to-use, when-not, or alternative (e.g. get-contact-property for a single field) is named. Adequate but leaves routing to inference.

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 covered. The description adds a functional use-case but omits a materially useful behavior: that the default status filter includes revoked and expired devices (only stated in the schema). 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, front-loaded sentence that names the resource and its purpose with zero filler. Nothing extraneous or repeated.

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 list tool with no output schema, the description covers what it does and why. It could be slightly more complete by noting that revoked/expired devices are returned by default, but the schema fills most of that 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 83%, so the schema already documents contact_id, pagination cursors, limit, status, and platform. The description adds no additional parameter meaning beyond what the schema 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 a contact's registered push devices') clearly, and the phrase 'registered push devices' distinguishes it from notification-oriented siblings like list-push-notifications. However, it does not explicitly contrast with near neighbors such as get-push-device-import or get-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?

The clause 'to check whether they can receive push notifications' gives a use-case context, which is more than nothing. But there is no explicit when/when-not guidance and no named alternative, so the routing guidance is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds non-obvious behavioral context: exact-match lookup semantics for identifiers versus audience filtering, and a presentation rule about not surfacing ids/timestamps unprompted. It stops short of describing pagination or result-size behavior, which the schema partially covers.

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?

Front-loads purpose, then usage, then exclusions in three tight labeled blocks. Every sentence carries routing or behavioral instruction; nothing is redundant with the schema or 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?

With no output schema, the description still tells the agent what the results mean and how to present them. All 8 parameters are documented in the schema and grouped in the description. Minor gap: it doesn't restate pagination/default-limit behavior, though the schema's cursor and limit descriptions cover that adequately.

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 adds real semantic value beyond the schema by grouping the eight parameters into lookup-by-identity (email/phone_number/external_id) versus filter-by-audience (list_id/tag_id), which tells the agent how to choose among them rather than just what each does.

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 contacts, or look one person up') and immediately distinguishes the two modes of operation. An agent can tell it apart from the singular get-contact sibling and from get-list/get-tag without opening any 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?

Explicit 'Use when' section maps real user phrasings ('is X a contact?', 'who has this tag?') to the correct parameter choice, and the 'Not for' section routes counting requests to get-list/get-tag by naming their contact_count output. Both when-to-use and when-not-to-use are covered with named alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds one non-obvious trait — suppressing ids/timestamps in the reply unless asked — which the annotations do not convey. It says nothing about pagination behavior, defaults, or result ordering, so it goes slightly beyond but not richly 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?

Two tight sentences with the core purpose front-loaded and no filler. The second sentence is an operational directive rather than description, but it earns its place as an agent-facing instruction and the whole definition is well within a reasonable length.

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 gives the agent a handling rule for the returned fields and names the filtering surface, while the schema fully documents pagination. Annotations carry the safety profile, so nothing critical is missing, though a note on pagination default or result volume would round it out.

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%, covering after/before cursors, the 1-100 limit default, case-insensitive search, and the full status enum. The description only restates the name/status filters, adding no syntax or format detail 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 (List) and resource (email campaigns) with the filterable dimensions named, which cleanly separates it from get-email-campaign, create-email-campaign, and list-sms-campaigns. It does not explicitly name those siblings, but the resource qualifier 'email campaigns' is unambiguous among the list-* family.

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?

Implies usage through 'optionally by name or status', telling the agent these are optional filters, but never states when to prefer this over get-email-campaign (single fetch) or list-sms-campaigns. The second sentence is a presentation rule rather than invocation guidance, so the when-to-use picture stays at the minimum viable level.

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, destructiveHint=false and closed-world, so the safety profile is fully covered. The description adds domain context (what counts as transactional) and a display guideline about not surfacing ids/timestamps, but says nothing about pagination behavior or result volume. Adds some value over annotations without being 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?

Three short sentences, front-loaded with the purpose before the disambiguation and the display note. The final sentence about not echoing ids/timestamps is response-presentation guidance rather than invocation guidance, but it is brief and non-redundant.

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

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

For a read-only, zero-required-parameter list tool with full param coverage and closed-world annotations, the description supplies the one thing the structured fields cannot: the definition of 'transactional' that separates this from the campaign siblings. Nothing critical is missing, though a pointer to the campaign alternative would make it 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 the cursor parameters (after/before, and the mutual-exclusion rule) and the limit range are already fully documented in the schema. The description contributes no additional parameter meaning, making the baseline 3 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 ('List transactional emails') plus what the listing contains ('with their delivery status'). It also disambiguates the resource type from the sibling family of campaign listers ('not campaigns'), so an agent can pick this over list-email-campaigns 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?

Clearly delimits the resource ('one-off sends ... receipts, one-time passwords, not campaigns'), which is exactly the condition separating it from list-email-campaigns and list-sms-messages. It stops short of naming the alternative sibling explicitly, so it does not reach full when-to-use/when-not routing, but the context is unambiguous.

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 behavior, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the returned data (event types plus payload schemas and conversion setup) and an output-handling constraint for the agent; only pagination behavior is left to the schema.

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, no filler, with the core purpose and example front-loaded before the smaller presentation caveat. Every sentence carries information the agent needs.

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 correctly carries the burden of describing the return contents (event types, payload schemas, conversion setup), which it does. Pagination and filtering details are adequately covered by the fully documented schema, leaving only a minor gap around result ordering.

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 after/before/limit/search fully. The description mentions payload schemas and conversion setup but adds no parameter-level syntax or semantics beyond what the schema provides, making 3 the correct 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 (event types the organization tracks) with a concrete example (order.completed) and enumerates what is returned (payload schemas, conversion setup). This cleanly separates it from the sibling get-event, which retrieves a single event.

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 listing context and gives a presentation rule ('Don't read ids or timestamps back to the user unless they ask'), but it never states when to call this versus get-event or other list-* siblings. Usage 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the scope of what is listed (filter categories), with no detail on return shape, ordering, or size — adequate but not rich given the annotations do the heavy lifting.

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 that states what is returned and why it matters, with zero padding or repetition 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?

For a parameterless enumeration helper with no output schema, the description gives the agent enough to know what it will get back and how to use it. It stops short of describing the result structure, which is the only 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?

The tool takes zero parameters, so the baseline is 4 and there is no argument syntax an agent could get wrong.

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 (List) plus resource (gallery categories) and it enumerates the four category kinds returned (types, seasons, features, industries). It also ties itself to the sibling list-gallery-templates, so an agent can distinguish it from the other list-* tools, though it never contrasts with any alternative beyond that.

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 only implied: by saying these are the filters list-gallery-templates accepts, an agent can infer it should be called to discover valid filter values before using that tool. There is no explicit when-to-use, prerequisite, or 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that these are ready-made designs intended to be copied, with no extra behavioral detail on pagination behavior or result shape.

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, and the core purpose is front-loaded ahead of the follow-up 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?

For a read-only listing tool with a fully documented 8-parameter schema and no output schema, the description covers purpose and the intended next step well. A brief note on category-id sourcing or pagination would make it fully self-sufficient, but nothing critical 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 description coverage is 100% and all 8 parameters (cursors, limit, search, and the four comma-separated id filters) are documented in the schema itself. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb (Browse) and resource (Arsel's gallery of ready-made email designs), which distinguishes it from the sibling list-templates that covers the organization's own templates. It stops short of explicitly contrasting with list-templates/get-gallery-template, but the 'gallery' framing plus the named follow-up tool makes the role 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?

The description points to the natural next action (copy-gallery-template), which implies a browse-then-copy workflow, but gives no explicit when-to-use versus list-templates or when-not guidance, and does not mention that filter ids must come from list-gallery-categories (that fact lives only in the schema).

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. The description adds a useful presentation directive ('Don't read ids or timestamps back to the user unless they ask'), but discloses nothing about result volume, ordering, or pagination behavior beyond the schema.

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, no padding, and the resource definition is front-loaded before the filtering clause. The second sentence is a distinct output rule rather than filler, so almost 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 read-only listing tool with no output schema, full param coverage and clear annotations, the definition gives enough to call it correctly. A brief note on pagination shape or default ordering would close the remaining gap, but nothing essential 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 description coverage is 100% and the schema documents after/before cursors, limit, search and the status enum in detail. The description only echoes the search and status filters, adding no syntax or format meaning 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 and resource ('List in-app message campaigns') and defines the resource domain ('messages shown inside the organization's app or website'), which implicitly separates it from the email/SMS/push siblings. It stops short of naming a sibling or stating scope boundaries explicitly, so it lands just below the top tier.

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 filtering conditions ('optionally by name or status') suggest when the tool is appropriate, but there is no explicit when-to-use versus alternatives guidance and no mention of the get-in-app-campaign or create/update siblings that share the resource. Usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description still adds real value beyond that by disclosing what the response carries (contact counts) and a presentation constraint (don't surface ids/timestamps unless asked), though it says nothing about pagination behavior for a paginated endpoint.

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 with zero filler; the core purpose is front-loaded and each following sentence adds a distinct piece of information (domain meaning, output-presentation rule). Nothing is redundant with the schema or 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?

With no output schema, the description usefully names what comes back (lists with contact counts) and how to present it. Pagination semantics are fully covered by the schema's cursor descriptions, so the remaining gap — return shape details such as fields beyond counts — is minor for a read-only listing 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 after/before/limit/search are fully documented in the schema, including the mutual exclusion of after and before and the 1-100 limit. The description adds no parameter information, so the baseline 3 is correct when the schema does all the work.

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 contact lists) and immediately adds scope detail that competitors lack: the results include contact counts and represent static audiences that campaigns target. This reads clearly against siblings like get-list (single item), create-list, and update-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 explicit when-to-use guidance and no routing to alternatives (e.g., search by name vs. paginate through all lists). The domain note that lists are static audiences is context, not a usage rule, and the id/timestamp instruction is about output presentation rather than tool selection.

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 full safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the agent knows this is a safe, repeatable read. The description adds a genuinely useful behavioral instruction about not surfacing ids/timestamps unless requested. However, it says nothing about pagination behavior or result ordering, so the added context is modest.

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, no filler, with the core purpose front-loaded ahead of the presentation guideline. Every clause 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 fully-annotated, read-only list tool with complete schema coverage, this is close to sufficient; the pagination mechanics are fully covered by the schema. The remaining gap is that, with no output schema, the description never describes what a returned campaign contains or how results are ordered, leaving the agent to infer the return shape.

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 fully documented cursors, limit range, search semantics, and a status enum, so the schema carries the parameter burden and a 3 baseline applies. The description echoes 'name or status' but adds no format or syntax detail (e.g., case sensitivity, combinability of search+status) 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 ('List push notification campaigns') and names the two filter dimensions (name, status), which is enough to distinguish it from the parallel list-email-campaigns/list-sms-campaigns siblings by channel. It stops short of explicitly contrasting itself with get-push-campaign (single retrieval) or list-push-notifications, so sibling differentiation is implicit 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?

The description gives no when-to-use guidance, no mention of alternatives such as get-push-campaign for a single campaign, and no note on when filtering is worthwhile. The only additional sentence is about output presentation, not tool selection. An 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 already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that results carry delivery status and a display caution about not surfacing ids/timestamps unprompted, which is useful output-level context, but it says nothing about auth needs, ordering, 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 sentences, each doing work: scope, definition/contrast with campaigns, and a presentation rule. It is front-loaded on what the tool returns, though the final UI-guidance sentence is somewhat tangential to tool invocation.

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

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

With no output schema, the description compensates by indicating the return payload includes delivery status, and the transactional-versus-campaign distinction prevents misuse of the sibling campaign listers. Minor gaps remain around ordering and pagination behavior, but the core is covered.

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 all three cursor/limit parameters fully described in the schema, so the baseline is 3. The description adds nothing about pagination semantics or parameter behavior 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 (List) and resource (transactional push) plus the payload returned (delivery status). It explicitly differentiates from the closest sibling by defining transactional sends as one-off API messages 'not campaigns', so an agent can separate it from list-push-campaigns 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?

The description effectively scopes when this tool applies by defining transactional messages versus campaigns, which routes the agent correctly. However it never names list-push-campaigns or any alternative, and gives no explicit when-not condition, so usage is implied rather than 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 already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds a genuine behavioral constraint not in annotations: suppress ids and timestamps in user-facing output unless asked. That is useful presentation-level guidance 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?

Two short sentences, capability first, behavioral caveat second. Every clause 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 read-only list tool with full schema coverage and safety annotations, the description covers purpose, filters, and an output-display rule; return values need not be explained since no output schema exists and the note about ids/timestamps partly addresses it. Pagination behavior is left entirely to the schema, 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%, so all five parameters (after, limit, before, search, status) are already documented, including the enum values. The description only restates that name/status filtering exists and adds no format, default, or pagination semantics 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 (SMS campaigns), and the noun itself separates it from sibling list tools like list-email-campaigns and list-push-campaigns. It does not explicitly call out alternatives, but the resource scoping makes the target 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 get-sms-campaign (single fetch) or the other list-* campaign tools. The phrase 'optionally by name or status' describes filter capabilities rather than when-to-use or exclusions, so an agent gets no routing help.

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 safety is covered. The description adds a useful presentation constraint ('don't read ids or timestamps back unless asked'), which is real behavioral guidance beyond the structured fields, though it says nothing about pagination or result size.

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 sentences, front-loaded with the core purpose followed by the disambiguating definition. All sentences carry information, though the closing id/timestamp instruction is presentation guidance rather than invocation-critical content.

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

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

A simple read-only list tool with no output schema and fully documented parameters; the description adequately scopes the resource and gives output-presentation guidance. It is complete enough for correct invocation, missing only optional pagination commentary that the schema already covers.

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 all three cursor/limit parameters are fully described in the schema, so the baseline of 3 applies. The description adds no pagination syntax or format 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?

States a specific verb and resource ('List transactional sms') plus the returned content ('delivery status'), and explicitly carves out what transactional means versus campaigns, which cleanly distinguishes it from the sibling list-sms-campaigns. An agent can differentiate this from the other list-* tools without opening a 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?

The definition of 'transactional' (one-off sends like receipts and OTPs, not campaigns) gives clear context for when this list is the right one. It stops short of routing the agent to a concrete alternative such as get-sms-message for a single message, so it lacks explicit 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 cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful return behavior by stating that contact counts are included and that ids and timestamps should not be volunteered to the user unless requested.

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 wasted words. The core purpose is front-loaded, and the output caveat is concise and actionable.

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 robust schema descriptions and annotations, the definition is nearly complete. It covers purpose and output presentation, though it could mention pagination or search behavior at a high level for an agent that has not yet inspected the 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%, so all four parameters are fully documented in the schema. The description adds no parameter-level meaning beyond what is already structured, which matches the baseline of 3 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 gives a specific verb and resource: list tags with contact counts. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as get-tag or list-lists.

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 get-tag, list-lists, or other siblings. The instruction about not reading ids or timestamps back is output presentation guidance, not usage 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes beyond that by defining output presentation behavior ('Don't read ids or timestamps back to the user unless they ask'), which is genuinely useful and not captured in any structured field.

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 core action, each carrying distinct information. 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 no-required-param list tool with no output schema, the description covers scope, purpose, and output handling adequately; pagination and search are handled by the schema. It stops short of noting the related gallery-template tools, which would round it out.

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

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

Schema coverage is 100%, so all four params (after, limit, before, search) are fully documented in the schema itself. The description adds no syntax or format detail beyond that, 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 and resource ('List the organization's own email templates') and the 'own' qualifier usefully distinguishes it from the gallery-template siblings. It doesn't name an alternative sibling by name, so it's clear but not maximally differentiating.

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 mention that 'an email campaign uses one through its template_id' implies why you'd call this (to obtain a template_id), but there's no explicit when-to-use vs. when-not guidance and no pointer to list-gallery-templates for non-org templates. Usage is implied rather than 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 already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds value beyond that by disclosing that results include delivery status and by giving output-presentation guidance (don't surface ids/timestamps unless requested), which is real behavioral context not in 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?

Three front-loaded sentences; the purpose leads and the definition of 'transactional' immediately follows. The final presentation note is slightly tangential but short and useful, keeping the whole thing lean.

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 list tool with no output schema, the description covers the resource, scope, return content (delivery status), and presentation guidance, while pagination lives in the schema. It is nearly complete; only the relationship to single-message fetch tools is 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 description coverage is 100% – after/before cursors and the limit range are fully documented in the schema itself. The description adds no additional parameter meaning, so 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?

States a specific verb (List) and resource (transactional WhatsApp) plus a return attribute (delivery status). It explicitly defines 'transactional' as one-off API sends, not campaigns, which cleanly distinguishes it from campaign-listing and message-fetching 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 definition clarifies scope by contrasting transactional messages with campaigns (receipts, OTPs), which routes the agent correctly away from campaign tools. However, it never names an alternative tool (e.g. get-whatsapp-message) or states when to prefer a single-message fetch over a list, so it falls short of explicit alternatives.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds meaningful context beyond them: only list membership is destroyed while the contact records survive, and user confirmation is required beforehand. It omits any note on idempotency (annotation says false) or partial-failure behavior when some contact_ids are not in the 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?

Three short sentences with the core action and its scoping caveat front-loaded, followed by the operational safeguard. Every sentence carries distinct information with no filler.

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

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

For a two-parameter mutation with no output schema and annotations that already declare the destructive profile, the description covers the essential scope and confirmation requirement. It could go further by noting behavior when an id is absent or repeated, but it is sufficient to invoke the tool correctly.

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

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

Schema description coverage is 100%, with both the list uuid and the contact_ids array fully documented in the schema, so the baseline is 3. The description adds only a light hint that the list should be identified by name during confirmation, which does not extend parameter meaning beyond the schema.

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

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

States a specific verb and resource ('Remove contacts from a list') and immediately scopes the effect by clarifying that 'the contacts themselves are kept', which separates it from a delete-contact operation. It does not name the inverse sibling (add-contacts-to-list), so an agent must infer the pairing, 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?

Provides one concrete procedural guideline ('Confirm with the user first, naming the list'), which is genuinely useful for a destructive operation. However, it offers no guidance on when to choose this over alternatives such as remove-tag-from-contacts or a full contact delete, so usage context is only partially implied.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so safety is covered. The description adds genuinely new behavioral context: removing a tag can trigger the organization's automations, which may send messages. That consequence is not derivable from annotations or schema and materially affects whether an agent should proceed.

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, front-loaded with the action and followed immediately by the risk. Nothing extraneous.

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 two-parameter mutation with full schema coverage and annotations covering safety, the description supplies the key missing piece: the automation side effect. It omits whether the operation is reversible or what the response contains, but with no output schema and a low-complexity call 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%, so both parameters (id, contact_ids) are already fully documented in the schema, including the pointer to list-contacts. The description adds no syntax, format, or batching detail beyond that, matching the baseline for high-coverage schemas.

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 (remove) and resource (tag, on contacts), which is clearly the inverse of the sibling add-tag-to-contacts. It does not explicitly name that sibling, so the differentiation is implied by the tool name 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?

No guidance on when to use this versus alternatives, no prerequisites, no mention of permissions or conditions. The only context given is a side effect, 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 cover the destructive/idempotent/openWorld profile, and the description adds real behavior beyond them: omitted fields are unchanged, null clears a field, the invariant that an email/phone/external id must remain, and the side effect that automations may fire and send messages. The list_ids REPLACE semantics (empty array removes from all lists) is exactly the kind of non-obvious behavior an agent needs.

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 tightly packed sentences, each earning its place: partial-update semantics first, then the lists replacement rule plus the alternative tool, then the automation side effect. The highest-risk behavior (list replacement, message sending) is surfaced without preamble.

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, the description covers partial-update semantics, field-clearing, validation invariants, replacement semantics, an alternative tool, and the automation side effect. Nothing an agent needs to invoke this safely 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 coverage is 50%, and the description compensates meaningfully with the omission/null-clears rule and the required-identifier invariant that the schema doesn't state. It does not explain the custom-field 'properties' object or format expectations for the undescribed fields, so it falls short of full 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+resource ('Update a contact') and immediately scopes it against siblings by naming add-contacts-to-list and the condition that separates them. An agent can distinguish this from create-contact, get-contact, and the list-membership tools without opening any 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?

Explicitly routes one use case to an alternative ('To add without removing, use add-contacts-to-list'), and warns that the call may start automations that send messages. The when-to-use-this-vs-sibling guidance is concrete rather than implied.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the agent knows this mutates state. The description adds real value by explaining that passing null clears description and fallback value, but it omits whether display_name can be cleared, whether the change is immediately live, and any permission requirements.

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

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

Two short sentences, front-loaded with the action and followed by the one non-obvious mechanic. No filler.

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

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

For a mutation tool with no output schema and annotations covering the safety profile, the description plus schema give enough to invoke it correctly. Minor gaps remain around live-effect and non-nullable display_name, but nothing blocking.

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

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

Schema description coverage is only 25% (just id), so the description carries the burden: it enumerates the three mutable fields and, beyond the schema's bare null types, explains that null on description/fallback_value means 'clear'. It does not mention the maxLength constraints or that display_name cannot be null.

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 (Change) plus resource (a custom field) and the exact editable attributes (display name, description, fallback value). It is clearly about contact properties rather than contacts, but does not explicitly distinguish itself from siblings like create-contact-property or update-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 statement of when to use this tool versus the create/get/list contact-property siblings, and no prerequisites. The only guidance is the null-clearing note, which is a mechanic rather than a usage condition.

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

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description explains that editing a scheduled campaign alters what is actually sent at its scheduled time and instructs the agent to confirm with the user first — real side-effect disclosure. It also states patch semantics ('Omitted fields are unchanged'), which annotations cannot convey.

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

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

Four short sentences, all front-loaded: purpose, precondition, side-effect warning, then omitted-field semantics. Nothing is redundant and each sentence carries distinct operational value.

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

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

For an 11-parameter mutation with no output schema, the description covers the key gaps: editability state, side effects, confirmation, and patch behavior. It does not describe the response or list which fields are mutable, but with 82% schema coverage and annotations present this is close to 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 coverage is 82%, so the schema already documents most of the 11 parameters and the baseline is 3. The description adds meaningful optionality semantics with 'Omitted fields are unchanged', telling the agent that any omitted field will not be cleared — a behavior the schema does not spell out.

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 first sentence states a specific verb and resource ('Update an email campaign'), and the follow-up constrains it to draft/scheduled state. It does not explicitly distinguish itself from the sibling update-sms-campaign / update-push-campaign / update-in-app-campaign tools, but the resource name makes the distinction unambiguous on its own.

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 a clear editability precondition ('Only draft and scheduled campaigns can be edited') and a confirmation requirement before mutating a scheduled send. It stops short of naming alternatives or stating when-not to use it versus create-email-campaign, so it is strong context rather than complete 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 destructiveHint=true and idempotentHint=false, so safety is covered. The description adds the key non-obvious behavior that `schema` replaces (not merges) the whole field list, which explains the destructive nature beyond what annotations state.

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, front-loaded with the core action and immediately followed by the one caveat that matters. 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?

For a destructive mutation with nested objects and no output schema, the description is adequate but thin: it omits what happens to unspecified fields, permission/auth needs, and return behavior. It covers the headline change and the replace semantic but leaves meaningful 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 75%, near the point where the schema does the heavy lifting. The description adds a genuinely useful semantic for `schema` — full-list replacement — that the schema itself does not convey, though it says nothing extra about `conversion` or `description`.

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

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

States a specific verb+resource ('Change an event type's ... description, schema or conversion setup') and enumerates the mutable facets, so the scope is clear. It does not explicitly distinguish itself from siblings like create-event or get-event, but the mutation framing 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 when-to-use, when-not-to-use, or alternative guidance. It also doesn't state prerequisites (e.g., that the event must already exist or that fields must be fetched first). The agent must infer usage purely from the name and schema.

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 destructiveHint=true and idempotentHint=false, but the description adds non-obvious behavior the annotations cannot convey: that edits to a live campaign propagate to devices on their next fetch, that only `active` campaigns are editable contrary to other channels, and that omitted fields are left unchanged. This is the kind of lifecycle and confirmation context an agent needs before mutating a live campaign.

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 dense sentences, each carrying distinct load: the action, the editability/live-propagation rule, and the confirmation requirement, then the omit-unchanged semantic. Nothing is redundant and the critical constraint is front-loaded.

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

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

For a 16-parameter mutation tool with no output schema, the description covers the dangerous edges (which states block edits, live propagation, user confirmation, partial updates). It does not touch validation constraints on the nested button/content structures, but the schema carries those, so the remaining gap is minor.

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 a middling 69% across 16 parameters, and the nested `buttons` fields are largely undocumented. The description compensates for the single most important gap by stating "Omitted fields are unchanged," establishing PATCH semantics that the schema never states explicitly.

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 first sentence names a specific verb and resource ("Update an in-app campaign") and the resource word cleanly separates it from the sibling update-email-campaign / update-sms-campaign / update-push-campaign tools. An agent can identify the target entity without opening the 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?

It gives explicit when-not conditions ("ended and archived campaigns cannot be edited") and a mandatory process step ("before editing a live campaign you MUST confirm with the user"), which is unusually actionable. It does not name alternative tools such as create-in-app-campaign or clone-in-app-campaign, so it falls short of full 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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description usefully narrows the scope of mutation to just name and description, but it does not disclose why an update is flagged destructive, whether fields are partial-update, or what happens to omitted 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 well-formed sentence with the action front-loaded and zero 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 small 3-parameter mutation tool with annotations and no output schema, this is adequate but thin: the 33% schema coverage leaves optional-parameter behavior and the destructive/partial-update semantics unexplained.

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 only 33% (only 'id' is documented), so the description must compensate. It maps 'rename' to the name parameter and 'change its description' to the description parameter, adding real meaning, but gives no format, length, or clearing semantics (e.g., empty string behavior).

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

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

States specific verbs (rename, change description) against the resource (contact list), so the operation is unambiguous. It distinguishes itself naturally from siblings like update-contact, update-tag, and update-template by naming the resource, though it never explicitly contrasts with them.

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 context, no prerequisites, and no mention of alternatives such as create-list or list-lists. The agent must infer that this is the only route to modify an existing list.

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