Meta Cloud API MCP Server

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the action but omits important details such as required permissions, whether the flow is published by default, reversibility, or what response is returned. The only behavioral nuance is the option to provide inline JSON or clone, but this is minimal for a mutation tool.

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

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

The description is a single sentence that immediately conveys the core purpose and the two main options. It is front-loaded and contains no redundant phrasing or irrelevant details.

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

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

For a 7-parameter create operation with no output schema and no annotations, the description is somewhat thin. It covers the core action and main options but does not mention return values, edge cases, or default behaviors (e.g., what happens when publish is false). The schema fills in parameter details, but the overall context could be richer.

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 value by clarifying that flow_json is for inline definition and clone_flow_id is for cloning from an existing flow, which is not explicitly tied in the schema. This helps an agent understand the relationship between these mutually exclusive parameters.

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

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

The description clearly states the action ('Create') and resource ('WhatsApp Flow'), distinguishing it from sibling tools like list_flows and update_flow_metadata. It also mentions two distinct creation modes (inline JSON or clone), adding specificity beyond a generic 'create' statement.

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

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

The description provides clear context that this tool is for creating a new flow, as opposed to updating or listing. It does not explicitly exclude alternatives or name sibling tools, but the context is unambiguous. Mentioning the two creation paths gives a hint of when to use flow_json vs clone_flow_id, though no detailed guidance is given.

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

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

With no annotations provided, the description carries the full burden of disclosure. It only states the action and component format, but does not mention permissions, validation behavior, side effects, or the expected response. This is insufficient for a mutation tool.

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

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

The description is two sentences, front-loaded with the purpose, and contains no unnecessary words. The second sentence adds relevant context about the component schema without being verbose.

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

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

The tool has 6 parameters and no output schema, and the description explains the action and component requirement but does not mention return values, prerequisites, or post-conditions. The rich schema helps, but the lack of behavioral disclosure and response info 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?

The input schema has 100% coverage with descriptions and examples for all 6 parameters. The description's note about following the Meta template component schema adds slight value but largely duplicates what the schema's components description already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Create a new WhatsApp message template.' The verb 'create' and resource are specific, and the mention of the components schema distinguishes it from sibling template operations like get, update, and delete.

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

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

The description implies usage through the verb 'create' but does not explicitly state when to use this tool versus alternatives like update_template or list_templates. No exclusions or alternative references are provided, so guidance is minimal.

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

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

No annotations are provided, so the description carries the full burden. It discloses the draft-only restriction, which is a key behavioral trait. However, it does not mention side effects, permanence, or error behavior when deleting a non-draft flow, leaving some gaps in transparency.

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

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

The description is extremely concise, consisting of two short sentences. It front-loads the action and adds a critical constraint without any filler or redundant information, making it highly efficient.

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

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

For a simple tool with a single parameter and no output schema, the description covers the essential usage context: what it does and its primary limitation. However, it could mention expected outcomes (e.g., success/failure behavior), but the low complexity warrants a score above the minimum.

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

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

The input schema already provides 100% coverage of the 'flow_id' parameter with a description ('The Flow ID to delete'). The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description uses the specific verb 'Delete' with the resource 'WhatsApp Flow', clearly stating the action. It also includes a critical constraint ('Only DRAFT flows can be deleted'), which distinguishes it from sibling tools like deprecate_flow and publish_flow.

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

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

The description explicitly states when the tool is applicable ('Only DRAFT flows'), which guides the agent to use it only for drafts. It does not explicitly name alternatives, but the constraint implies non-draft flows require other tools, making the usage context 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?

With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the action without mentioning that deletion is permanent, whether authorization is required, or any error conditions. This is a destructive operation, so more transparency is expected.

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

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

The description is a single concise sentence that is front-loaded with the core action and resource. It contains no unnecessary words or repetition of the tool name.

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

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

For a simple one-parameter delete operation, the description covers the essential what and how. However, it lacks any mention of irreversibility or operational context, such as whether this permanently removes the media or if there are restrictions on which media can be deleted. Given the tool's simplicity, the gaps prevent a higher score.

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 media_id parameter, and the description adds no extra meaning beyond what the schema already provides. The baseline of 3 is appropriate when the schema fully documents parameters.

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

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

The description uses a specific verb ('Delete') with a clear resource ('media file from WhatsApp servers') and the identifier ('by media ID'). It distinguishes itself from sibling tools like upload_media, download_media, and get_media_info by focusing on the deletion action.

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

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

No guidance is provided about when to use this tool versus alternatives, or any prerequisites or side effects. The description simply states what it does without explaining when deletion is appropriate, such as after downloading or when media is no longer needed.

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

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

With no annotations provided, the description carries the full burden. It indicates that specifying hsm_id deletes a specific language version, but it does not clarify the default behavior when hsm_id is omitted (likely all versions) or disclose that deletion is irreversible. This is a significant gap for a destructive operation.

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

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

The description is exactly two sentences, front-loaded with the core action and resource, and includes the optional parameter nuance without any fluff. Every word contributes to understanding the tool.

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

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

For a simple delete operation with only two parameters and no output schema or annotations, the description covers the main purpose and the optional version targeting. However, it leaves ambiguity about the default scope of deletion when hsm_id is absent and lacks any warning about permanence, which would be expected for a destructive action.

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

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

The input schema already covers both parameters with clear descriptions (name: 'Template name to delete'; hsm_id: 'Specific template ID to delete a single language version'). The tool description essentially repeats the schema's meaning for hsm_id, adding no new semantic value. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Delete') and resource ('WhatsApp message template') that clearly distinguishes this tool from siblings like list_templates, get_template, create_template, and update_template. It also notes the optional hsm_id to target a specific language version, adding to the specificity.

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

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

The description provides clear context for when to use this tool: when you need to delete a template by name or optionally a specific version via hsm_id. It does not explicitly mention alternatives or when-not-to-use scenarios, but among siblings there is no alternative deletion tool for templates, so the context is sufficient.

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

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

With no annotations provided, the description carries the full burden. It discloses the key behavioral trait: deprecation is irreversible and the flow can no longer be used. This goes beyond a simple mutation statement but does not mention permissions or error cases.

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 action, and every sentence adds value. It is concise and well-structured 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?

The tool is simple with one parameter and no output schema. The description covers the purpose, the precondition (published), and the consequence (irreversible, unusable), making it complete for invocation.

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

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

Schema coverage is 100%, with flow_id already described as 'The Flow ID to deprecate'. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states 'Deprecate a PUBLISHED WhatsApp Flow', using a specific verb and resource. It distinguishes from sibling tools like delete_flow and publish_flow by its irreversible nature and focus on published flows.

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

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

The description gives clear context: only for published flows, and the irreversible consequence. However, it does not explicitly mention when not to use it or contrast with alternatives like delete_flow, 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?

With no annotations provided, the description carries full burden for disclosing behavioral traits. It merely says 'Deregister', which implies a destructive or state-changing action, but gives no details about side effects, reversibility, or consequences such as loss of access or impact on WhatsApp Business features. This is a significant transparency gap.

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

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

The description is a single, focused sentence with no superfluous words. It is appropriately sized for a tool with no parameters and simple purpose, and it front-loads the verb 'Deregister' for immediate clarity.

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

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

While the tool itself is simple (no parameters, no output schema), the description lacks context about the implications of deregistering a phone number. It does not explain what happens afterwards, whether the action is reversible, or any warnings about the destructive nature. More context is needed for an AI agent to safely invoke 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?

The input schema has zero parameters, so the baseline is 4 per the guidelines. The description adds no parameter information because there are no parameters, and the schema coverage is trivially 100%. No further compensation 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?

The description uses a specific verb 'Deregister' with a clear resource 'WhatsApp Business phone number', which immediately distinguishes it from sibling tools like register_phone or get_phone_number. It is direct and unambiguous about what action the tool performs.

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

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

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, such as the number needing to be registered, or exclusions, such as not using it while active conversations are ongoing. The description simply states the action without contextual direction.

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

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

No annotations are provided, so the description carries the full burden. It only states the core action and the prerequisite, but does not disclose potential side effects (e.g., file overwriting, access token requirements, error behavior, or return format). This is a minimal disclosure for a tool with no annotation safety net.

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

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

Two concise sentences, front-loaded with the action and a clear prerequisite. Every word earns its place with no redundancy or filler.

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

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

Given the low complexity (2 params, no output schema) and clear schema, the description is minimally viable. However, it lacks information about return values, error handling, or expected behavior after download, which would be useful for a tool without annotations or output schema. It is adequate but not 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 parameters clearly described (media_url and save_path). The description adds no additional semantic information beyond the schema, so it meets the baseline but does not enhance parameter understanding.

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

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

The description clearly states the specific action (download media content) and the resource (a WhatsApp media URL), distinguishing it from siblings like upload_media and get_media_info. It is not a tautology and provides clear scope.

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

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

The description explicitly instructs to use get_media_info first to obtain the URL, giving clear usage context and a prerequisite. It does not explicitly mention when not to use it, but the prerequisite guidance is strong and implies the intended workflow.

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

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

With no annotations, the description carries the full burden. It discloses the fields that can be retrieved, but does not mention default behavior (e.g., whether omitting 'fields' returns all fields), authentication prerequisites, or error cases. This is a simple read-only operation, so the gap is moderate.

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

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

The description is a single, focused sentence that front-loads the action ('Get') and then concisely lists the returnable fields. There is zero redundant wording or filler.

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

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

For a simple retrieval tool with a single optional parameter and no output schema, the description is almost complete. It names the resource and the fields, and the schema covers the parameter. It does not explicitly state that omitting 'fields' returns all fields, but this is easily inferred from the schema and the tool's purpose.

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

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

The input schema already provides 100% coverage with an enum and a description for the 'fields' parameter. The description lists the same fields in prose, which adds some readability but no new semantic detail beyond the schema.

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

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

The description uses the specific verb 'Get' with the resource 'WhatsApp Business Profile' and enumerates the included fields (about, address, description, email, websites, profile picture URL). This clearly distinguishes it from sibling tools like update_business_profile, which is a write operation.

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

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

The description provides clear context that this tool is for retrieving a business profile and lists the available fields. It does not explicitly name alternatives or state when not to use this tool, but the retrieval intent is unambiguous, so it earns a 4 rather than a 5.

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

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

With no annotations, the description carries the full burden. It discloses the type of information returned (status, categories, validation errors) but does not explicitly state that it is read-only or mention potential errors, permissions, or side effects. The verb 'Get' implies a safe read operation, but more explicit behavioral disclosure would be helpful.

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

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

The description is a single concise sentence, front-loaded with the action and resource, and contains no unnecessary words. It effectively communicates the core purpose.

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

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

For a simple GET tool with full schema coverage and no output schema, the description adequately explains the resource accessed and the data included. It is complete enough to guide an agent, though it could mention the return format or explicitly state the read-only nature to be fully comprehensive.

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 description need not repeat parameter details. The description adds a small amount of context by mentioning specific fields like status and validation_errors, which hints at possible values for the 'fields' parameter, but this overlaps with the schema's example and does not significantly enhance understanding.

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

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

The description clearly states the tool retrieves details of a specific WhatsApp Flow by ID, which distinguishes it from siblings like list_flows (list all) and create_flow (create new). The verb 'Get' and resource 'details of a WhatsApp Flow by ID' are specific and direct.

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

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

The description implies the tool is used when you have a flow_id and need detailed information, as opposed to list_flows for browsing or create_flow for creation. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for a simple get operation.

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

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

No annotations are provided, so the description carries the full burden. It clearly discloses the primary behavior (retrieving metadata) and lists the specific return fields, giving the agent a good sense of what to expect. It does not mention error cases or permission requirements, but for a simple getter, the main behavioral trait is covered.

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

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

The description is a single sentence that front-loads the primary action and immediately lists the returned metadata fields. Every word earns its place, with no redundancy or extraneous detail.

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

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

For a tool with one simple parameter and no output schema, the description adequately explains what the tool does and what it returns (URL, MIME type, file size, hash). It lacks explicit error-handling or edge-case information, but for a read-only metadata getter, the description is sufficiently complete.

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

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

The input schema has 100% coverage with a clear description for media_id ('The media ID to retrieve info for'). The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Get') and resource ('metadata for a media object by ID'), and explicitly lists the returned fields (URL, MIME type, file size, SHA-256 hash). This clearly distinguishes it from sibling tools like download_media (content retrieval) and delete_media (destructive operation).

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

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

The description implies usage for fetching metadata rather than content, but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or conditions, leaving the agent to infer from the word 'metadata'.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. 'Get information' implies a read-only operation, but it does not explicitly state that there are no side effects, whether authentication is required, or what happens if the number is not configured. The behavior around the optional 'fields' parameter (e.g., default return set) is also left undisclosed.

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

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

The description is a single, tightly written sentence that front-loads the action and resource, then lists representative outputs. No redundant words or filler, making it highly efficient and well-structured.

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

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

The tool is simple with one optional parameter, and the schema covers parameters, so the description is mostly adequate. However, it lacks explanation of what 'configured' means in terms of which number is targeted, and how the fields parameter affects the response, leaving some contextual gaps for an agent deciding how to invoke 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?

The schema provides 100% coverage of the only parameter ('Specific phone number fields to retrieve') and enumerates all accepted values. The description adds minimal value by mentioning a few example fields, but these are already in the enum, so it does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the action ('Get information') and the specific resource ('configured WhatsApp Business phone number'), which distinguishes it from sibling tools like list_phone_numbers (which enumerates numbers) and get_waba_account (which targets the WABA). It also lists key data points (display number, verified name, quality rating, status), making the tool's purpose unambiguous.

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

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

The description gives no explicit guidance on when to use this tool compared to list_phone_numbers or get_waba_account. There is no mention of whether to leave fields empty for default behavior or how to filter results, leaving the agent to infer usage from the sibling names 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?

With no annotations provided, the description carries the full burden. It indicates a read-like operation ('Get') and notes that the response includes 'full definition including components,' but it does not disclose error behavior, permissions, rate limits, or any side effects. This is minimal but adequate for a simple retrieval tool.

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

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

The description is a single concise sentence, front-loads the core purpose, and includes no redundant or unnecessary wording. It earns its place with high information density.

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

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

For a tool with one required parameter and no output schema, the description is complete: it specifies what is retrieved ('single template by ID') and what the response includes ('full definition including components'). No additional context is needed for an agent to invoke it correctly.

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

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

The schema description covers 100% of the parameter (template_id with description 'The template ID to retrieve'). The description adds no extra semantic value beyond restating that it fetches by ID, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool 'Get a single WhatsApp message template by ID with full definition including components.' It specifies the action (get), the resource (template), the selection method (by ID), and the return content (full definition including components), which distinguishes it from list_templates, create_template, update_template, and delete_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?

The description implies usage for retrieving a specific template by ID, but it does not explicitly state when to use this over list_templates or mention any alternatives or exclusions. It relies on the verb 'Get' and the resource specificity to convey the intended use case.

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

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

No annotations are provided, so the description carries full responsibility. It discloses the type of information returned, but does not mention the optional fields parameter or the default behavior when it's omitted. The read-only nature is implied by 'Get' but not explicitly stated.

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

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

A single, concise sentence that front-loads the core action and enumerates the key information categories without waste.

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

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

The tool is simple with one optional parameter, but the description omits that details can be customized via the fields parameter and what happens if omitted. The absence of an output schema makes this a gap, though the listed attributes provide some expectation.

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

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

The schema already covers the fields parameter with 100% coverage and a detailed enumeration. The description lists some fields but doesn't add additional semantics like default behavior or formatting.

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

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

The description uses the verb 'Get' with a specific resource 'WhatsApp Business Account information' and lists key attributes (name, status, health, verification, messaging limits). This clearly distinguishes it from sibling tools for templates, flows, messages, etc.

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 context is clear that this tool is for retrieving WABA account details, and sibling tools cover different resources. However, it doesn't explicitly mention when to use this over alternatives or any exclusions.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It correctly states the primary behavior ('List all WhatsApp Flows') but does not disclose additional traits such as read-only safety, pagination, limits, or authentication requirements. The word 'list' implies safety, but this is not explicit.

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

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

The description is a single concise sentence with no redundancy or unnecessary detail. It is front-loaded with the action ('List all WhatsApp Flows') and includes the necessary scope, making it highly efficient.

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

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

The tool is simple with one optional parameter and no output schema. The description clearly states what it does and is sufficient for a basic list operation. However, it could be slightly more complete by mentioning the return value format or pagination, but given the low complexity, 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?

The single parameter waba_id is fully described in the schema (100% coverage) with a clear description including the env var default. The description adds no additional parameter semantics, but the schema already handles it, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('List') and a clearly defined resource ('WhatsApp Flows') with a scope ('for a WhatsApp Business Account'). This distinguishes it from siblings like list_templates (which lists templates) and get_flow (which retrieves a single flow).

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

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

The usage is implied: use this tool to list WhatsApp Flows. However, there is no explicit guidance on when to use it versus alternatives like get_flow or list_templates, nor any exclusions or prerequisites. It provides clear context but lacks when-to/not-to 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?

No annotations are provided, so the description carries the full burden. 'List' implies a read operation, but it does not disclose potential side effects, pagination behavior, authentication requirements, or the exact format of the response. It is minimally transparent but lacks deeper behavioral 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?

The description is a single, concise sentence that immediately states the action and scope. There is no redundant information or unnecessary detail, making it highly efficient.

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

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

Given the tool's simplicity (0 params, no output schema), the description adequately explains its purpose. It could be improved by noting the return structure (e.g., an array of phone number objects), but the core contextual information 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?

The tool has zero parameters, so the schema provides no parameter details. The baseline for 0 params is 4, and the description does not need to explain parameters. No additional parameter information is required.

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

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

The description uses the specific verb 'List' and clearly identifies the resource as 'all phone numbers' associated with the WhatsApp Business Account. This distinguishes it from siblings like get_phone_number, which likely retrieves a single number.

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

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

The description implies when to use the tool (when you need to list all phone numbers) but does not explicitly mention alternatives or exclusions. It lacks guidance on when to prefer this over get_phone_number or other related tools.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the basic list action and optional filters, but omits details like pagination behavior, default limits, or response format, which are important for a list operation.

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

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

The description is a single, well-structured sentence that front-loads the verb and resource, then mentions optional filters. No information is wasted or 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 list tool with no output schema and no annotations, the description is minimally viable but lacks information about pagination, default behavior, or the shape of the response. Given the presence of a 'limit' parameter, some behavioral context would improve completeness.

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

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

The input schema provides 100% coverage with descriptions for all five parameters, including enums. The description's mention of 'optional filters' adds no new meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states 'List WhatsApp message templates' with a specific verb and resource, and mentions optional filters. It distinguishes itself from siblings like get_template (which retrieves a single template) and create/update/delete operations.

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

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

The description provides clear context for when to use the tool (listing templates with filters) but does not explicitly mention alternatives or exclusions such as 'use get_template for a specific template.' This is inferred from sibling names.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects. It clearly discloses that publishing makes the flow JSON immutable, a critical irreversible behavior. However, it does not mention what happens to the flow status, whether the operation is idempotent, or any required auth/permissions.

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

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

The description is two sentences, front-loads the purpose, and every sentence contributes essential information. No fluff 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 simple single-parameter tool with no output schema, the description adequately covers the core behavior and a key side effect. It lacks details on error conditions or return values, but these are not critical for understanding the primary function.

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?

Although the schema already describes flow_id as 'The Flow ID to publish', the description adds crucial context: the flow must be in DRAFT state. This gives the parameter meaning beyond a mere string identifier.

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

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

The description clearly states the action ('Publish') and the resource ('a DRAFT WhatsApp Flow'), distinguishing it from sibling tools that update or delete flows. The additional note about immutability further specifies the scope.

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

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

The description explicitly limits usage to DRAFT flows, signaling that it is not for published flows. The warning that flow JSON cannot be modified after publishing implies that any edits must be done beforehand, but it does not directly name alternatives like update_flow_json or deprecate_flow.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and PIN, but does not disclose side effects, permissions required, rate limits, or what happens after registration. This is insufficient for a state-changing operation.

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

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

The description is a single, clear sentence with no wasted words. It is front-loaded with the action and resource. However, it is slightly too terse given the complexity of the operation, earning a 4 rather than 5.

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

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

The tool has no output schema, no annotations, and a state-changing purpose. The description explains what it does but omits when to use it, prerequisites, or any expected result. This is inadequate for an agent to invoke it confidently in a sequence of related steps.

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

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

Schema coverage is 100%, with both parameters having descriptions. The description merely repeats the '6-digit PIN' detail already in the schema and adds no new meaning for data_localization_region. This meets the baseline but adds no extra value.

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 action ('Register') on a specific resource ('WhatsApp Business phone number') with a key requirement (6-digit PIN). It distinguishes from sibling tools like request_verification_code, verify_phone_code, and deregister_phone.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites such as needing a verification code first, nor does it explain the relationship to request_verification_code or verify_phone_code. The description implies a step but offers no explicit 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the delivery channels (SMS/voice) and the target phone number, but it does not mention prerequisites (e.g., unverified number), rate limits, costs, or expected post-request behavior. The basic action is clear but side effects are not detailed.

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

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

The description is a single sentence that is front-loaded with the action, includes the target resource, and specifies the delivery methods. Every word contributes meaning and there is no redundancy or filler.

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

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

For a simple tool with two fully documented parameters and no output schema, the description covers the core action, target, and method appropriately. It is missing a small amount of context about the expected result and the next step (e.g., using verify_phone_code), but the invocation details are complete enough for correct 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 100%: both 'language' and 'code_method' are documented in the input schema. The description only echoes the SMS/voice options for code_method, adding no meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Request') and clearly identifies the resource (WhatsApp Business phone number) and the two delivery methods (SMS or voice call). It is distinct from the sibling verify_phone_code, which would consume the code rather than request it.

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

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

The description provides no explicit guidance on when to use this tool relative to alternatives. It does not mention that this should precede verify_phone_code or that it is part of phone number registration, nor does it state any exclusions or alternative tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention potential side effects, prerequisites (e.g., prior media upload), what happens if both image_id and image_link are provided, or the response format. For a send operation, this lack of transparency is a significant gap.

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

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

The description is two sentences with no redundant information. It front-loads the primary action and then provides the key parameter guidance. Every word earns its place.

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

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

The tool is relatively simple with all parameters documented in the schema, and the description covers the core either/or constraint. However, it lacks details that would make it fully self-contained: no mention of what both parameters being provided causes, no expected response, and no caveats about image_link accessibility. Given no annotations, these gaps leave the description at a minimum viable level.

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

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

The schema already describes all parameters (100% coverage), but the description adds an important semantic constraint: the need to provide either image_id or image_link. This goes beyond the schema by clarifying the mutual exclusivity and the source of the image, adding value over the structured fields.

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

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

The description clearly states the action ('Send an image message via WhatsApp') and specifies the resource (image message), which distinguishes it from sibling tools like send_text_message and send_template_message. It also mentions the two input modes, adding useful scope.

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

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

The description provides clear context on how to specify the image ('Provide either an image_id... or image_link...'), which is a practical usage guideline. However, it does not explicitly mention when to use this tool over alternatives (e.g., for text or template messages), though the tool name and context make the intended use reasonably 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?

No annotations are provided, so the description bears the full burden. It adds the behavioral constraint that templates must be pre-approved. However, it does not disclose other traits such as delivery behavior, errors, or side effects beyond sending. This is arguably minimal viable transparency, but not rich enough for a score above 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?

The description is a single sentence, 18 words, with the core purpose front-loaded. Every word contributes meaning; there is no wasted phrasing. This is exemplary 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 sending tool with moderate complexity, the description covers the essential context: what it sends, via which channel, and the prerequisite of approval. There is no output schema, but the absence of return-value documentation is not a significant gap given the straightforward nature of the tool. It is complete enough for correct selection and 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?

Input schema coverage is 100%, with each parameter having a description. The tool description itself does not add parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Send' with a clear resource 'pre-approved template message via WhatsApp'. It distinguishes from sibling send tools like send_text_message and send_image_message by emphasizing 'template' and 'pre-approved'. The requirement of creation/approval adds further differentiation.

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

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

The description gives clear context: templates must be created and approved before sending, implying use of template management tools first. It does not explicitly name alternatives or exclusions, but the prerequisite is a strong usage signal. This qualifies as clear context without exclusions.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'send a text message,' with no mention of potential side effects, delivery acknowledgment, failure conditions, 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?

The description is a single, front-loaded sentence that directly conveys the action and resource. It contains no unnecessary words or repeated 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 simple send operation with fully documented parameters, the description is minimally adequate. However, it does not mention return values (no output schema is present), nor does it provide context on when to use this tool versus template/image sending, which is relevant given the sibling tool set.

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 description adds no additional parameter semantics. The baseline of 3 applies because the schema fully documents the parameters, including examples and purposes.

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

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

The description clearly states the action (send), the resource (a text message), and the channel (WhatsApp), distinguishing it from sibling tools like send_template_message and send_image_message.

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

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

No guidance is provided on when to use this tool versus alternatives such as send_template_message or send_image_message. It also lacks any mention of prerequisites like phone number registration or opt-in requirements.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It states the action and that parameters are optional, but does not mention side effects, reversibility, idempotency, or any prerequisites. For a state-changing subscription tool, this lack of transparency is a significant gap.

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

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

The description is a single, direct sentence with one additional clause. Every word serves a purpose—stating the action, the resource, and the optional parameters. There is no redundancy or unnecessary detail.

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

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

The tool has no output schema and no annotations, so the description should explain return values or consequences. It only states the action and options, omitting any outcome or side-effect information. However, given the tool's simplicity, the description is adequate for basic understanding but lacks completeness regarding what happens after subscription.

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

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

The input schema has 100% description coverage for both parameters, so the baseline is 3. The description merely repeats parameter names ('override the callback URL and verify token') without adding meaning beyond the schema. It does not highlight the conditional dependency between verify_token and override_callback_uri, but that is captured in the schema.

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

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

The description clearly states the verb 'subscribe' and resource 'WABA webhooks', making the tool's purpose specific and unambiguous. It also distinguishes from the sibling 'unsubscribe_waba_webhook' by its name and action. The mention of optional override parameters adds further clarity.

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

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

The description implies when to use the tool (when you want to subscribe to webhooks) but provides no explicit exclusions, alternatives, or prerequisites. It does not mention the sibling 'unsubscribe_waba_webhook' or clarify conditions like the conditional requirement for verify_token, leaving usage guidance 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Unsubscribe' implies a mutating action, but the description does not disclose whether the operation is reversible, whether it removes all webhooks, or what the impact on the app is. This lack of detail is a significant gap for a state-changing operation.

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

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

The description is a single, concise sentence with no filler or repetitive content. Every word adds meaning, and it is immediately clear what the tool does.

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

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

For a zero-parameter tool with no output schema, the description is adequate but minimal. It does not explain what 'WABA webhooks' are, whether the unsubscribe is global or scoped, or how to re-subscribe. The sibling 'subscribe_waba_webhook' provides some context, but the description itself lacks completeness.

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

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

The input schema has zero parameters, so the description does not need to explain parameter meanings. Baseline for 0 parameters is 4, and the description provides no conflicting or redundant information.

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

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

The description clearly states the action: 'Unsubscribe your app from WABA webhooks'. It specifies the verb ('Unsubscribe') and the resource ('WABA webhooks'), and it naturally distinguishes itself from the sibling tool 'subscribe_waba_webhook'.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention that it is the inverse of 'subscribe_waba_webhook', nor does it indicate any prerequisites or side effects. The usage context is entirely 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?

No annotations are provided, so the description must disclose behavior. It only states 'update' which implies mutation, but lacks details on partial vs. full updates, required permissions, success/error behavior, or side effects. This is a significant gap for a mutation tool.

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

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

A single concise sentence that front-loads the verb and resource, then enumerates fields. There is no wasted verbiage.

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

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

The tool has zero required parameters, six optional properties, no output schema, and no annotations. The description is adequate for a simple update but lacks behavioral context (e.g., whether it's a partial update) and how it relates to get_business_profile. The schema covers parameter constraints, but the description doesn't enrich operational context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists the same field names as the schema without adding extra meaning, such as constraints or interdependencies. It doesn't compensate beyond the schema's property descriptions.

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

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

The description uses the specific verb 'Update' and identifies the resource as 'WhatsApp Business Profile fields', listing all relevant fields. This clearly distinguishes it from sibling tools like get_business_profile, which reads the profile.

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

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

The description implies usage (to update profile fields) but does not explicitly state when to use this tool versus alternatives (e.g., get_business_profile for reading). No conditions or exclusions are given, so the guidance is only 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does not explain whether the update replaces the entire definition, effects on existing data, validation behavior, required permissions, or response semantics, which are critical for a mutation tool.

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

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

Two concise sentences: the first states the purpose, the second adds input flexibility. No fluff, front-loaded, and every word earns its place.

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

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

For a simple upload/update tool with two parameters, the description is minimal but lacks crucial context: no response format, no error or validation notes, no relationship to other flow lifecycle tools. Given no annotations or output schema, the description should fill more 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 the baseline is 3. The description's statement about accepting JSON as string or object is redundant with the schema's anyOf definition and adds no new semantic meaning beyond what's already structured.

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

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

The description clearly states the tool uploads or updates the Flow JSON definition for a WhatsApp Flow, identifying a specific resource and action. It distinguishes from siblings like update_flow_metadata by focusing on the JSON definition, though 'Upload or update' is slightly ambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives such as create_flow, update_flow_metadata, or publish_flow. The description gives no context for selection among the many related flow tools.

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

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

No annotations are provided, so the description bears the full burden of disclosing behavioral traits. It fails to mention whether updates overwrite existing metadata, required permissions, potential side effects, or how errors are handled. The description is purely functional with no transparency beyond the action itself.

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

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

The description is a single, focused sentence that front-loads the verb and resource, then lists the relevant fields in parentheses. Every word contributes, and there is 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?

Given the tool's simplicity and the fact that the schema fully documents all parameters, this description is reasonably complete for a basic metadata update operation. It could be improved by noting that no output schema exists and adding a note about idempotency or partial updates, but the essentials are 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?

The input schema already describes all four parameters, achieving 100% coverage. The description only restates the field names without adding any additional meaning, such as format constraints or relationships between parameters, so it adds no value beyond the schema.

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

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

The description clearly states the tool updates metadata of an existing WhatsApp Flow and specifies the exact fields (name, categories, endpoint URI). This distinguishes it from sibling tools like update_flow_json, which likely handle the flow's JSON definition, making the purpose unambiguous.

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

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

The description implies usage for updating an existing flow's metadata rather than its JSON structure, but it does not explicitly state when to prefer this tool over update_flow_json or other alternatives. It also lacks mention of prerequisites like the flow existing.

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?

There are no annotations, so the description carries the full burden. It does disclose a key consequence: 'Template is resubmitted for review.' However, it doesn't explain what this means for the template's active status during review or whether the update is partial or full replacement. This leaves some behavioral ambiguity.

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

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

The description is two sentences, front-loaded with the purpose, and every word earns its place. It states the action, the constraint, and the consequence without 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 relatively simple update tool, the description covers the core action and consequence (resubmission for review). However, with no output schema, it omits any mention of return values, prerequisites (e.g., template must exist), and the exact semantics of the update (e.g., whether the components array replaces the entire set). This leaves noticeable gaps for an agent.

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

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

The schema already provides descriptions for all three parameters (100% coverage), giving a baseline of 3. The description adds value by explicitly stating that only components and category are updatable, which clarifies that template_id is immutable and that these are the only accepted changes. This is a meaningful addition beyond the schema.

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

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

The description clearly states the verb and resource: 'Update an existing WhatsApp message template.' It further distinguishes itself from sibling tools by specifying the updatable fields ('Only components and category can be updated'), making it unambiguous what this tool does versus create/list/delete.

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

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

The description implies when to use this tool by its name and the constraint on updatable fields, but it does not explicitly name alternatives or state when not to use it. For example, it doesn't say 'for other fields, delete and recreate the template.' The guidance is implicit rather than explicit.

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

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

With no annotations, the description carries the full burden. It discloses supported file types and size limits (image 5MB, video 16MB, audio 16MB, document 100MB, sticker 500KB) and the return value (media ID). However, it does not mention permissions, rate limits, or error handling, though the provided information is substantial.

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 action and return, followed by a compact list of supported types and limits. No wasted words or redundancy.

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

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

For a straightforward upload tool with 3 well-described parameters and no output schema, the description adequately explains the return value and key constraints. It lacks some details like authentication or storage behavior, but for this complexity the information is sufficient.

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 descriptive parameter definitions. The description adds meaningful context beyond the schema by specifying allowed file types and size limits, which informs the choice of mime_type and file_name. This goes beyond the baseline expected from high schema coverage.

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

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

The description clearly states the action ('Upload a media file to WhatsApp'), the resource ('a media file'), and the outcome ('Returns a media ID that can be used in messages'). This distinguishes it from sibling tools like get_media_info or delete_media, which operate on already-uploaded media.

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

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

The description implies the tool is used to obtain a media ID for later message sending, but it does not explicitly say when to use it versus alternatives (e.g., sending media directly via send_image_message). No exclusions or fallback conditions are provided.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without revealing potential side effects, whether the code is single-use, what happens on invalid code, authentication needs, or the success/failure response. This is insufficient for a mutating verification operation.

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

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

The description is a single sentence that directly states the purpose without any redundant wording. It is front-loaded and every word earns its place, making it highly concise and well-structured.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate for an agent to understand the action. However, it does not describe the outcome of verification (e.g., what indicates success or failure), which is a gap since no output schema exists to explain return values.

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

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

The input schema fully describes the 'code' parameter as a '6-digit verification code', so the description adds minimal additional semantic value. The mention of SMS/voice call provides minor context about the code's source, but it doesn't compensate for the lack of deeper parameter guidance since the schema already covers the essential information.

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

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

The description clearly states the action ('Verify') and the specific resource ('WhatsApp Business phone number') with the method ('code received via SMS or voice call'). It effectively distinguishes from sibling tools like request_verification_code which issues the code, and register_phone which registers without verification.

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

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

The description implies usage by mentioning the code received via SMS/voice, indicating this is a follow-up to a code request. However, it does not explicitly state prerequisites, when to use this instead of alternatives (e.g., register_phone), or any exclusions, leaving the usage context only implied.

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