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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates state. The description adds only the null-unassign semantic and reveals nothing about what the destructive behavior entails — whether an existing assignment is overwritten, whether the prior assignee is notified, or what permissions are required.

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, front-loaded sentences with zero filler; the operation is stated first and the non-obvious null convention immediately follows.

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 core action and the null convention but omits permission/authorization requirements, overwrite semantics for reassignment, and any side effects (notifications, state changes) an agent would need to call it safely.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It meaningfully clarifies assignee_id=null as the unassign signal, which the schema's anyOf string/null typing does not explain on its own. conversation_id is left entirely to inference, so it only partially compensates 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 pair (assign/unassign) and resource (conversation) plus the target (team member), which is unambiguous and distinguishable from siblings like close_conversation or send_message. It does not, however, explicitly contrast itself with any sibling or note scope boundaries (e.g., single vs bulk).

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 sentence 'Pass null to unassign' gives one concrete usage condition, but there is no guidance on when to use this versus close_conversation, what permissions are needed, or what happens to a pre-existing assignee when reassigning. 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 and destructiveHint=false, so safety is covered. The description adds that the call surfaces a failure explanation, not just a status, which is useful context, but says nothing about scoping, eventual consistency, or what happens for enrollments still in progress.

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 verb and the two things returned. 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 single-parameter read tool with no output schema and annotations covering safety, the description covers the essentials. It still leaves ambiguity about what status values exist and how this differs from explain_delivery_failure, which is material given the sibling list.

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%, so the bare uuid parameter carries no documentation. The description ties the input implicitly to a 'journey enrollment', which narrows what enrollment_id means, but adds no format or sourcing detail beyond that.

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

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

Clear specific verb ('Check') plus resource ('delivery status and failure explanation for a journey enrollment'). An agent understands what it returns, but the description does not distinguish it from the sibling explain_delivery_failure, which appears to overlap.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives. The presence of explain_delivery_failure and list_journey_history among siblings makes the absence of routing guidance a real gap.

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 readOnlyHint=false, so the agent knows this mutates state. The description adds only the 'active' state qualifier; it does not say whether closing is reversible, whether history is preserved, or what happens to in-flight messages. Given annotation coverage, a moderate score is fair.

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, front-loaded with the verb and resource, with no wasted words. It is efficient, though arguably too terse for a destructive operation.

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

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

For a destructive mutation with no output schema, the definition omits prerequisites, reversibility, error/edge behavior, and any indication of what the result looks like. With only one undocumented parameter and no return contract, the agent is left to guess at important 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?

There is one parameter (conversation_id) with 0% schema description coverage, so the schema alone leaves the agent without guidance. The description does not clarify what ID is expected, where to obtain it, or whether it accepts other identifiers, so it fails 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 gives a specific verb (close) and resource (conversation), so the action is unambiguous. However, it does nothing to differentiate this from siblings like list_conversations, get_conversation, or assign_conversation, which are all conversation-scoped.

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

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

The phrase 'an active conversation' hints that the target must currently be open, but there is no explicit when-to-use guidance, no prerequisites (e.g. permissions, state), and no mention of alternatives or follow-up behavior. An agent gets almost nothing about when this tool is the right choice.

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

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

The annotations already mark it as destructive and non-read-only. The description adds valuable context beyond annotations by specifying that deletion affects both Meta and a local registry row, and by requiring explicit user confirmation. It does not cover reversibility, error behavior, or auth details, but it meaningfully improves behavioral understanding.

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, front-loaded with the core action and followed by a critical safety constraint. Every phrase earns its place, and there is no redundant restatement of the tool name 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?

Given a destructive mutation with two required parameters, no output schema, and external side effects, the description covers the essential action, dual deletion targets, and confirmation requirement. It could better address the required id/reason parameters or failure cases, but the annotations and schema fill some 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 50%: the 'reason' parameter is well documented in the schema, but the required 'id' parameter has no schema description. The tool description adds no parameter meaning at all, so it fails to compensate for the undocumented id or to reinforce the required reason. The agent must infer that id is the template identifier from the tool name alone.

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

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

The description states a specific verb and resource ('Delete a WhatsApp template'), and adds both effects: removal from Meta and from the local registry row. It clearly distinguishes the tool from siblings like get_template, list_templates, and submit_template. An agent can tell exactly what this tool does 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 a clear usage condition: 'only use after explicit user confirmation.' This is a strong safety-oriented guideline for a destructive operation. However, it does not name alternatives or explain when not to use the tool beyond the confirmation requirement, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing what the caller gets back (a plain-English explanation plus next steps), which is important since 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?

One sentence, zero filler, with the purpose and output form front-loaded. Nothing is redundant with the name 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?

For a read-only, single-parameter lookup with no output schema, the description covers purpose, parameter domain, and the shape of the result. It stops short of examples of accepted code formats, 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?

Schema coverage is 0% and the schema only types 'code' as a non-empty string, so the description carries the burden. It does narrow the parameter's domain to Meta/WhatsApp delivery or template error codes, which is meaningful, but it gives no format detail (numeric vs string, code families) or examples, so it only partially compensates.

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

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

The description states a specific verb (explain), a specific resource (Meta/WhatsApp delivery or template error code), and even the output form (plain English with next steps). This cleanly separates it from all siblings, which are lookup, CRUD, or send operations rather than diagnostics.

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

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

The phrase 'delivery or template error code' implies the triggering context, so usage is inferable. However, there is no explicit statement of when to call this versus other troubleshooting paths, nor any exclusions, and no sibling is named as an alternative.

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

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

Annotations indicate this is a read-only, non-destructive operation, so the safety profile is covered. The description adds that it returns aggregated analytics metrics, but it doesn't specify whether results are scoped to a time range (though parameters imply this), what the granularity is, or any limitations (e.g., data retention). With annotations providing the core behavioral hints, a 3 is appropriate – some value is added by listing metric categories, but deeper behavioral context is absent.

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

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

The description is a single, front-loaded sentence that efficiently conveys the purpose and key metrics. No redundant or filler content is present. It is appropriately sized for the tool's complexity.

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 analytics tool with full schema coverage and no output schema, the description provides a basic list of metrics but lacks details on return format, aggregation level, or time zone handling. Given the absence of an output schema, the description should ideally explain the shape of the response (e.g., what fields are returned). It is minimally adequate but leaves gaps.

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

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

Schema coverage is 100%, so both parameters (start_date and end_date) are fully documented in the schema, including ISO format examples. The description doesn't add any syntax or default behavior beyond what the schema provides. Baseline 3 is correct when schema already covers parameter semantics.

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

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

The description clearly states a specific verb ('Get') and resource ('inbox analytics') and enumerates what the metrics cover (message volume, response times, AI usage, conversion stats). This distinguishes it from sibling tools like get_usage, which focuses on usage metrics rather than inbox analytics. However, it doesn't explicitly name that sibling or clarify the boundary, 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 guidance on when to use this tool versus alternatives like get_usage (which likely covers plan usage) or other analytics-related tools. No preconditions or exclusions are mentioned. The agent must infer context from the name and description alone.

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

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

Annotations already establish read-only, non-destructive safety, so the bar is lower. The description adds real behavioral value beyond them: it discloses what the content actually contains (where the user clicks, Meta prerequisites, realistic timeframes) and concrete outcomes like Instagram same-day vs WhatsApp 2-6 weeks.

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. The valuable routing guidance ('call this before advising...') and the concrete timeframe contrast are front-loaded and each sentence earns its place.

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

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

For a no-parameter read-only guide with no output schema, the description tells the agent what the returned content covers and when it matters. No return-format explanation is needed, and nothing an agent requires to call it 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 tool takes zero parameters, so the baseline is 4. The description correctly implies no input is needed by describing the guide as covering all channels generically.

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) plus resource (connection guide) and enumerates the covered channels (Instagram, WhatsApp, Messenger, Telegram, Shopify, calendars). This clearly distinguishes it from siblings like list_channels, which only lists channels rather than explaining setup.

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

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

Explicitly says 'Call this before advising anyone which channel to set up', giving a clear trigger condition. It does not name a competing sibling tool to use instead, so it falls just short of the 5-level when/when-not/alternatives bar.

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

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

readOnlyHint=true and destructiveHint=false already declare the safe-read profile, so the description could have added value elsewhere but adds nothing. It doesn't say whether a missing ID errors or returns null, nor anything about the response 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?

A single short sentence with the resource and scope front-loaded. Efficient, though it is arguably under-specified rather than maximally 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 one-parameter read tool with safety annotations, this is minimally adequate. However there is no output schema, so the description provides no notion of what a contact record contains or what happens on failure.

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%, so the description carries the burden, yet 'by ID' only restates the obvious id parameter and adds no format (UUID), validation, or lookup semantics beyond what the schema's format field already implies.

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 clear verb (Get) and resource (contact) with scope qualifier (single, by ID). Among siblings like list_contacts and update_contact, it implicitly differentiates by retrieval of one record, though it never names an 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?

No guidance on when to use this vs list_contacts or get_conversation, and no prerequisites or error conditions mentioned. The agent must infer usage 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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes beyond them by disclosing the returned payload ('customer details and last message'), which is valuable since there is no output schema. It does not state behavior when the ID is not found, but the safety profile and content disclosure are strong.

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

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

A single sentence with no filler, front-loading the action and identifier. The payload clause adds useful detail rather than padding.

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 single-resource getter with one fully documented parameter, the description covers the essentials and compensates for the absent output schema by naming what is returned. Minor gap: no note on not-found behavior.

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

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

Schema description coverage is 100% and the single 'id' parameter is fully documented in the schema, so the baseline of 3 applies. The description's 'by ID' merely restates 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 a single conversation by ID') and clarifies the payload ('customer details and last message'). The word 'single' implicitly distinguishes it from list_conversations, though that sibling is never named.

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?

'by ID' implies the tool needs a known identifier, but there is no explicit when-to-use guidance and no mention of list_conversations or list_messages as alternatives for the discovery path. The agent must infer the selection criteria.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds the scoping context (API key scopes and plan tier) but does not describe the return shape, which is a gap given 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?

A single front-loaded sentence with no wasted words. It delivers the purpose and the determining factors without padding.

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 read tool with annotations covering safety, the description is almost sufficient. However, with no output schema, it does not indicate what the returned capability list looks like — e.g., whether it enumerates permitted API/MCP operations or just summarizes them — leaving a small but real gap.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies that the result is determined entirely by the ambient API key and plan tier, which is enough for a parameterless tool.

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

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

States a clear verb (show) and resource (API/MCP capabilities), specifying what determines the result (API key scopes and plan tier). This distinguishes it from usage-related siblings like get_usage or get_developer_limits, though it does not explicitly name those alternatives.

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

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

Usage is implied — checking what the current API key is permitted to do — but the description offers no explicit when-to-use guidance or contrast with sibling tools such as get_developer_limits or get_developer_onboarding.

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

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

Annotations already establish the safe read-only profile, so the description needn't restate safety. It does add useful framing that the values are plan-tier limits rather than observed usage, but it says nothing about authentication scope or whether limits are cached/refreshed.

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 the scoping qualifier with no filler. Every clause maps to a real part of the return.

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 parameters, no output schema, and read-only annotations, the description covers the essentials by naming the three returned quantities and their scope. It would be stronger if it hinted at the shape of the response (e.g., nested per-endpoint rate limits), but nothing needed to invoke it correctly 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 tool takes zero parameters, so the schema carries no semantic burden and the baseline is 4. There is nothing for the description to disambiguate or compensate 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?

States a specific verb ('Get') and enumerates the three resources returned (API rate limits, API key quota, webhook endpoint quota), which is more concrete than the bare name. It also scopes the result to 'the current key plan tier', which implicitly separates it from usage-oriented siblings like get_usage, but no sibling is named explicitly.

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

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

The description never says when to reach for this tool versus get_usage or get_developer_capabilities, nor does it mention prerequisites. Usage is only inferable from the fact that it reports limits, which is weak guidance for an agent choosing among many getters.

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 safe read-only, non-destructive operation, so the safety profile is fully covered. The description adds the scoping constraint ('current workspace') but nothing about auth needs, checklist composition, or freshness. With annotations carrying the safety burden, this is adequate 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?

One sentence, front-loaded with the verb, and it earns its place by naming the resource and scope. 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 zero-param, annotation-covered read tool, the essentials are present. However, it lacks any hint of what the checklist contains or when an agent should reach for it, which matters given the dense sibling cluster of developer-oriented tools.

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

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

Zero parameters, so baseline is 4. The description correctly frames the implicit workspace context rather than pretending there are inputs. Nothing further is needed.

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

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

States a specific verb (Get) and resource (developer onboarding checklist) scoped to the current workspace. It's clear what the tool returns, but it doesn't distinguish itself from siblings like get_developer_limits or get_developer_capabilities — the reader must infer the difference from the resource noun alone.

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

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

No indication of when to use this versus siblings like get_developer_capabilities or get_connection_guide. The 'current workspace' scoping implies a context but provides no conditions, prerequisites, or 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=true and destructiveHint=false, so safety is covered. The description adds only that the template is 'stored' (as opposed to a draft), which is a small but real distinction; it says nothing about lookup failure behavior or whether a missing ID errors.

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. Every clause carries information: the cardinality (one), the resource, and the identifier type.

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 lookup with annotations covering the safety profile and no output schema required, the description is essentially sufficient. A note on where to obtain the ID or on lookup-miss behavior would complete it.

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

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

Schema coverage is 0% – the sole 'id' parameter has no description or format note in the schema. The description partially compensates by identifying it as the InstantReply template ID (not a phone number or channel ID), which is meaningful, but gives no format or sourcing guidance (e.g. from list_templates).

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 (Get) and resource (stored WhatsApp template) with a scope qualifier (one, by InstantReply template ID) that separates it from the sibling list_templates. It does not explicitly name that sibling, 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?

Usage is only implied: the phrase 'by InstantReply template ID' suggests you need a known ID already in hand, but there is no statement of when to prefer this over list_templates or validate_template, and no prerequisites noted.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully discloses the shape of the return (counts, error rates, top endpoints) but says nothing about the time window, aggregation behavior, or any rate-limit/permission context, leaving it only somewhat 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?

A single sentence with zero waste; the resource and scope are front-loaded before the enumerated metrics. Nothing to trim.

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

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

For a read-only stats tool with one optional parameter and no output schema, the description is nearly sufficient, but the undocumented time-window parameter leaves an agent guessing about the reporting period. It should at least state that results cover a configurable recent window.

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

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

Schema description coverage is 0% and the lone 'days' parameter (default 30, max 90) is never mentioned in the description. With coverage below 50%, the description should have compensated by explaining the time-window semantics, but it is silent on it.

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

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

States a specific verb and resource ('Get API usage stats') along with the scoping constraint ('for the current workspace') and enumerates the returned metrics (request counts, error rates, top endpoints). It is clear, but it does not differentiate itself from similarly scoped siblings such as get_developer_limits or get_analytics_summary.

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 offers no guidance on when to call this versus get_analytics_summary or get_developer_limits, nor any prerequisites or exclusions. 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the enumeration of channel types; it says nothing about pagination, ordering, or what a returned channel contains, which is a modest but real gap.

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

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

A single front-loaded sentence with the core purpose first and the clarifying examples second. Nothing is redundant or 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 zero-param, read-only listing tool with no output schema, the description covers what the agent needs in order to select and invoke it, and the examples give a usable sense of the result set. It stops short of describing return fields or pagination behavior, which would be the remaining detail worth adding.

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 there is nothing for the description to disambiguate. Baseline 4 applies: no parameter semantics are needed because the schema is empty.

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

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

States a specific verb ('List') and resource ('connected social channels'), and clarifies the resource by naming concrete channel types (Instagram, WhatsApp, Messenger pages). No sibling tool lists channels, so no differentiation is required, but the description also doesn't scope what 'connected' means beyond the parenthetical examples.

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 name and the zero-parameter signature: an agent calls this to discover which channels are available. There is no explicit when-to-use statement, no mention of prerequisites (e.g., authentication or account connection), and no named alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered without the description. The description adds only the 'leads' framing and the workspace scope, not pagination or return-shape behavior. With annotations doing the heavy lifting, this is a baseline 3.

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 zero filler, and the primary purpose is front-loaded before the modifier. Efficient, though the brevity contributes to the under-specification noted elsewhere.

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

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

For a paginated list tool with a cursor/limit pair and no output schema, the description omits how results are paged and how many come back, which an agent needs to call it correctly. It is incomplete despite its compact subject.

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%, so the description carries the burden for three parameters. It only gestures at the 'platform' filter and says nothing about 'limit' or 'cursor' (pagination), leaving two of three parameters entirely undiscussed despite no schema help.

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 clear verb+resource ('List contacts (leads) in the workspace') and clarifies the 'leads' synonym, which is useful terminology bridging. However, it does not distinguish itself from the sibling get_contact or explain its relationship to list_conversations/list_messages.

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?

Only 'Filter by platform' hints at usage. There is no explicit when-to-use guidance, no statement of when to prefer this over get_contact, and no mention of pagination behavior an agent must handle. The implied context is thin.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds filter semantics but says nothing about pagination (limit/cursor), ordering, or result volume, which is meaningful behavioral context for a list tool.

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

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

Two sentences, front-loaded with the core operation and then the filter options. No wasted words.

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

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

No output schema exists, so the description needn't explain return values, but for a paginated list tool it omits how pagination and result limits work. Adequate for basic invocation, incomplete for correct iterative use.

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

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

Schema description coverage is 0%, and the description explains the meaning of status, platform, and assignee by enumerating their values. However, limit and cursor — the pagination controls — are undocumented in both schema and description, leaving a real gap for a list operation.

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+resource ('List inbox conversations') that an agent can distinguish from sibling get_conversation or list_messages by its plural scope. It never explicitly names those alternatives, so it is clear but not sibling-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 description lists the three filter dimensions, which implies when the tool is useful. It gives no when-not guidance, no prerequisites, and does not route the agent toward get_conversation or list_messages for narrower needs.

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 as a read-only, non-destructive operation, so the safety profile is covered. The description adds only topical scope and does not disclose pagination behavior, authentication requirements, retention limits, or return format details beyond the annotations.

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

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

The single sentence is front-loaded and free of filler, so it is structurally efficient. It is arguably too sparse for a 7-parameter filtering tool, but it wastes no words.

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

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

With 7 parameters, no output schema, and no schema descriptions, the definition lacks sufficient detail about filtering, pagination, and returned fields. It gives only a broad topical summary and is not complete enough for an agent to invoke confidently without opening 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?

The schema has 7 parameters with 0% description coverage, so the description must compensate by explaining their meaning. It does not mention any parameter by name, format, default, or filtering behavior, leaving all parameters undocumented.

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

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

The description states a specific verb (List) and resource (recent WhatsApp journey enrollments and delivery states), making the tool's basic purpose clear. However, it does not distinguish this listing tool from siblings such as check_journey_status or get_analytics_summary.

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 guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The word 'recent' only weakly implies a time-scoped listing context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the useful ordering trait ('most recent first'), but omits pagination behaviour despite a cursor parameter, and says nothing about result limits or truncation.

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 purpose and the ordering trait front-loaded. 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 paginated list tool with no output schema and 0% parameter documentation, the description should explain cursor/limit semantics and what the returned items contain. Instead it supplies only purpose and ordering, leaving the agent under-equipped to call it correctly.

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

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

Schema description coverage is 0% across three parameters (conversation_id, limit, cursor), so the description must carry the load and it does not: limit's default/max, cursor's purpose, and conversation_id's expected format are all unexplained. Only the implicit ordering hints at how cursor works.

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 messages in a conversation'), and the ordering note ('most recent first') adds a distinguishing scope detail. It does not name or contrast with siblings like list_conversations or get_conversation, 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?

Usage is implied by the name and description but there is no explicit when-to-use/when-not guidance or reference to alternatives such as list_conversations (to find conversations) or get_conversation (for conversation metadata). Nothing is misleading, but the agent must infer the context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that usage stats are optional, which is really parameter behavior rather than new behavioral context — no pagination or result-volume guidance.

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 zero waste; the purpose is front-loaded and the usage hint follows. 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?

With no output schema, listing the returned fields (status, category, language, components) is a genuine contribution. However, the filtering semantics of channel_id and how status/category combine are left unaddressed for a four-parameter list 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 0%, so the description must carry the burden. It hints at the 'stats' flag and the status/category filters, but says nothing about channel_id (a uuid scoping the channel), leaving one of four parameters entirely unexplained in both schema and 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?

Specific verb+resource: 'List WhatsApp templates' plus the attributes returned (status, category, language, components, usage stats). The plural 'List' implicitly separates it from the sibling get_template, but no sibling is named 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?

'Use this before recommending sends or cleanup' gives a concrete, actionable when-to-use trigger. No when-not-to-use or named alternative (e.g., get_template for a single template) is provided, 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?

With annotations already declaring readOnlyHint=true and destructiveHint=false, the safety profile is covered. The description goes further by disclosing the exact return shape: a recommendation with plain-language reasons, a cheaper alternative when one fits, and a WhatsApp Meta Business Verification warning. This is exactly the kind of output-shape behavioral context annotations cannot express.

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: the first front-loads the action and its inputs, the second front-loads the return value and usage trigger. Every clause earns its place with no filler.

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

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

No output schema exists, so the description must explain returns — and it does, naming the recommendation, the cheaper alternative, and the WhatsApp verification warning. All 6 parameters are documented in the schema, and the usage trigger is explicit. Nothing needed to call this tool correctly 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%, so baseline would be 3. The description adds meaning by framing the parameters as discovery signals ('what you learn about the business in conversation'), telling the agent that these inputs are gathered progressively during dialogue rather than passed all at once. It doesn't add syntax details, which is appropriate given full schema coverage.

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

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

States a specific verb (recommend) and resource (InstantReply plan) plus the inputs it consumes (channels, monthly volume, team size, API/webhook access). No sibling tool does anything similar, so it distinguishes itself implicitly and explicitly within a conversational sales context.

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 final sentence 'Use this before telling a user what to sign up for' gives a clear when-to-use trigger. The phrase 'from what you learn about the business in conversation' establishes the prerequisite context, leaving no ambiguity about timing.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds that this is a reply inside an existing conversation (hence conversation_id is required), but omits materially relevant behavior such as messaging-window restrictions, rate limits, or failure semantics.

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

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

Two short, front-loaded sentences with no filler; the action is stated first and channel scope second. Minor overlap between the two sentences keeps it from being maximally economical.

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

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

For a mutation tool with no output schema and only partial parameter documentation, the description is just adequate. It should cover the messaging-window constraint, what content_type expects for non-text sends, and what a caller gets back on success or failure, none of which is present.

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

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

Schema description coverage is only 33%: only 'content' is documented, while conversation_id and the content_type enum (text/image/document/audio/video) are undocumented. The description says nothing about any parameter and does not compensate for the gap, leaving an agent to guess how content_type interacts with the message body.

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

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

States a specific verb and resource ('Send a reply message in a conversation') and names the supported channels, which implicitly separates it from channel-specific siblings like send_whatsapp_template. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully differentiated.

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

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

'Use for responding to customers' implies the conversational-reply context, but there is no when-not guidance, no mention of the 24-hour messaging window, and no pointer to send_whatsapp_template as the alternative for out-of-window or template-based sends. Usage is inferred 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 flag destructiveHint=true, but the description adds genuinely new context: the consent/transactional restriction and the requirement to confirm before sending. It omits other behavioral facts such as idempotency behavior or failure/return characteristics for a 6-param mutation.

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 constraint; 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 destructive, 6-parameter write with no output schema and zero schema descriptions, the description covers selection and consent but leaves most parameters, idempotency semantics, and expected results undocumented.

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%, so the description carries the full burden, and it only explains the two selector parameters (trigger_name vs journey_id). Phone, metadata, the message_type enum, and idempotency_key are left entirely to the schema.

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

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

States a specific verb (trigger/send) and resource (WhatsApp journey/template) and clarifies the two ways to select the target (trigger_name or journey_id). It does not, however, distinguish itself from close siblings like trigger_journey or send_message, which an agent could easily confuse it with.

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

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

Gives an explicit eligibility condition ('only for consented or transactional sends') and a behavioral rule ('ask before sending'), which is real usage guidance. It stops short of naming the alternative tools or stating when to prefer trigger_journey over this one.

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

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

Annotations declare destructiveHint=true, so the irreversibility bar is partly covered, but the description adds meaningful beyond-schema context: the target is an external approval system (Meta) and user confirmation is required before invoking. It still omits what happens on rejection/failure, but the external-submission and confirmation cues are valuable additions.

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 action and target front-loaded and the caution placed immediately after. Every sentence earns its place.

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

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

For a one-parameter mutation tool with no output schema and destructive annotations, the description covers the essentials (what, where, confirmation) but drops operational detail: whether submission is one-way, what a valid id looks like, and what the agent should expect after approval.

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 0% schema description coverage, so the description must compensate. 'Existing stored template draft' implies the id identifies a previously saved draft, but format (UUID), lookup behavior, and error cases for an invalid id are not addressed.

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 (submit) plus resource (existing stored template draft) and destination (Meta for approval). It implicitly distinguishes itself from the sibling submit_template by scoping to an already-stored draft, though it never names the 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?

Adds a procedural caution ('Ask for confirmation before use'), which is real usage guidance. However, it never states when this should be chosen over validate_template_draft, validate_template, or submit_template, leaving the agent to infer the workflow position.

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 readOnlyHint=false, so the mutation profile is covered. The description adds the confirmation-before-use requirement, which is real extra context, but omits what submission actually entails (Meta review/approval, irreversibility of an approved template, rate limits, required prior validation).

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, purpose front-loaded and no filler. The closing phrase 'before use' is slightly ambiguous about what 'use' refers to (submission, sending, or template activation), which costs a point.

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, nested-object, no-output-schema mutation that publishes content to an external platform, the description is far too thin. It should cover the validate-then-submit pattern, name format constraints, variable example requirements, idempotency behaviour, and what a rejection/approval response implies.

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% across 10 parameters, several nested (header, buttons with three variants). The description's only hint is 'flat developer-friendly shape', which explains the overall input convention but documents none of name, body, category, language, variable_examples, or idempotency_key.

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 pair and resource: 'Create and submit a WhatsApp template to Meta', plus the qualifier 'from a flat developer-friendly shape'. That is clear and distinctive, but it does not separate itself from close siblings like submit_stored_template or validate_template, which an agent will likely be choosing between.

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 only guidance is 'Ask for confirmation before use', which is an interaction instruction rather than a when-to-use rule. It never says when to prefer this over validate_template, validate_template_draft, or submit_stored_template, nor that validation should precede submission.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating operation. The description adds that it returns an enrollment_id for polling, which is genuinely useful, but it omits other behavior: whether re-enrolling is idempotent, what metadata does, and that the operation sends real WhatsApp messages to a live contact.

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 filler; the primary action and the return contract are both front-loaded. Nothing could be cut 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?

With no output schema, the description correctly states the return value (enrollment_id), which is the key missing piece. However, for a 5-param destructive mutation it does not explain idempotency semantics, metadata propagation, or what happens on duplicate enrollment, so an agent still has open questions.

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

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

Schema coverage is 0% across 5 parameters, so the description carries the full burden but only clarifies that trigger_name and journey_id are alternative selectors. It says nothing about metadata, idempotency_key, or the phone format constraints, leaving the two most behaviorally significant optional params undocumented.

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

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

The description gives a specific verb (enroll) and resource (one phone number in a WhatsApp journey), which is more precise than the tool name alone. It implicitly distinguishes itself from trigger_journey_batch by emphasizing a single number and from validate_journey_trigger by implying actual enrollment, though neither sibling is named.

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 through the name and the 'one phone number' phrasing; there is no explicit when-to-use or when-not statement. It does hint that enrollment_id can be used with check_journey_status, which is a useful breadcrumb but not a routing 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 declare destructiveHint=true, and the description usefully adds an explicit confirmation requirement plus a pre-flight sample validation, which is exactly the kind of behavioral caution a bulk mutation needs. It does not, however, describe partial-failure or rollback behavior.

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

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

Two sentences, roughly twenty words, front-loaded with the action and scope followed by the safety guidance. No filler and nothing 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 destructive bulk-write tool with no output schema and zero schema description coverage, the confirmation/validation guidance is valuable, but the unexplained journey_id and trigger_name parameters leave gaps an agent must guess at.

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

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

Schema coverage is 0% and the description only echoes the recipient limit already enforced by maxItems: 100. Neither journey_id nor trigger_name is explained, so the description does not compensate for the empty schema documentation.

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

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

States a specific verb (bulk-enroll), the resource (recipients), the target (WhatsApp journey) and a hard limit (up to 100). The 'bulk' framing distinguishes it from the single-recipient sibling trigger_journey, though no sibling is named 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?

Implies a workflow — confirm explicitly, validate a sample first — which points toward validate_journey_trigger, but never names the alternative or states the condition for choosing it. Usage context is implied rather than spelled out.

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 readOnlyHint=false and destructiveHint=true, so the agent knows this is a destructive mutation. The description adds no behavioral context beyond that – it doesn't explain partial-update semantics, required permissions, reversibility, or what happens to fields not mentioned.

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

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

A single front-loaded sentence with no filler. It is appropriately sized, though its brevity reflects under-specification rather than tight editing.

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 destructive mutation with no output schema and 0% schema coverage, the description is too thin: it omits three parameters and all behavioral detail about the update. It is not completely absent, but it leaves major gaps an agent needs filled.

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

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

Schema description coverage is 0% and there are 5 parameters, so the description must carry the load. It names only 'name' and 'lead stage', leaving 'id', 'email', and 'lead_temperature' completely unexplained, so it compensates only partially.

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

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

States a specific verb (update) and resource (contact) plus the two fields it targets, so the purpose is clear. It doesn't differentiate from siblings, but the sibling list contains no competing update tool, so the gap is minor.

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, prerequisites, or alternatives are given. The description doesn't say whether this is a partial patch or full replace, when to call it versus get_contact, or what conditions must hold.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and 'Dry-run' is consistent with that safe-read profile. The description adds value by naming the specific error classes it surfaces (phone, journey, duplicate, metadata), though it says nothing about return format or whether it actually hits the network.

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, zero filler, and the definition is front-loaded with the purpose before the usage routing. 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?

No output schema exists, so for a validator the description should explain what a successful vs. failed dry-run returns and how errors are surfaced. It only gestures at 'catching errors' without describing the response, leaving a meaningful gap for a validation 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 0%, so the description must carry parameter meaning. The error categories (phone, journey, metadata) loosely map to phone, journey_id, and metadata, but trigger_name is unmentioned and no format/constraint details (uuid format, trigger_name pattern, metadata shape) are given.

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: 'Dry-run a journey trigger request.' It makes clear this is a validation no-op rather than an actual send, distinguishing it from send_whatsapp_template and trigger_journey, which it names 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?

Gives an explicit when-to-use ('Use before send_whatsapp_template or trigger_journey') and states the goal ('to catch phone, journey, duplicate, and metadata errors'), so the agent knows both the trigger condition and the alternatives it guards.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe, non-mutating check. The description adds the useful context that validation targets Meta's submission rules, but says nothing about what a failure looks like (errors returned vs. thrown) or whether it can be re-run freely.

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 purpose leads and the usage condition follows naturally.

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 validation tool with no output schema, the description covers purpose and timing but omits what the validation returns or how failures surface. An agent can invoke it correctly but cannot predict the outcome 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 0% for the single 'id' parameter, so the description would ideally clarify it. It only implicitly conveys that the id is the stored template's identifier; given how self-evident a single required template id is, this is acceptable but not 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?

States a specific verb (validate) and resource (stored WhatsApp template) plus the rule set it checks against (Meta submission rules). The word 'stored' implicitly separates it from validate_template_draft, though the sibling is never named outright.

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?

'before submitting or rewriting' gives a clear triggering context for when to call this tool. It stops short of naming alternatives (validate_template_draft, submit_stored_template) or stating when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. Beyond that it discloses the shape of the response (policy risk, likely category, issues, UTILITY coaching), which tells the agent this is a non-mutating advisory check rather than an enforcement action.

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

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

Two tight sentences: the purpose and its timing constraint come first, the return payload second. Nothing is redundant and no sentence fails to earn 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?

With no output schema, the description correctly summarizes what comes back, which is a real strength. Against five parameters and an enum, though, the input side is under-specified, so the definition is only adequate for calling the tool correctly.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the burden and it does not. It clarifies only 'objective' (plain-language, free text) and gestures at category via 'likely category'; name, language, variables, and categoryHint are left entirely undocumented.

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

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

States a specific verb (validate) and resource (a plain-language WhatsApp template objective), and the phrase 'before creating it' implicitly separates it from submit_template/submit_stored_template. It never names a sibling, so the differentiation rests on the reader inferring that this is the pre-flight check versus the structured-template validators.

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?

'before creating it' gives an implied usage window, which is more than most sibling tools offer. However, no alternative is named (validate_template, submit_template) and there are no when-not conditions, so the agent must infer the workflow position.

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