Server Quality Checklist

Tool Scores

• create_templateC
  2.9/5.0
  Behavior2/5

  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 but offers minimal information. It states 'Create' which implies a write operation, but doesn't cover permissions needed, rate limits, whether the template is immediately usable, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap 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.

  Conciseness5/5

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

  The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it efficient and easy to parse. Every word earns its place, with no redundancy or fluff.

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

  Completeness2/5

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

  Given the complexity of creating a WhatsApp template (with 5 parameters, 4 required, and no output schema), the description is insufficient. It lacks details on behavioral aspects (like permissions or side effects), doesn't explain the relationship with sibling tools, and provides no guidance on usage. Without annotations or an output schema, the description should do more to compensate for these gaps.

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

  Parameters3/5

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

  The description adds no parameter-specific information beyond what's in the input schema, which has 100% coverage with detailed descriptions for all parameters. Since the schema fully documents each parameter (e.g., 'template_name' as 'Name for the new template'), the description doesn't need to compensate, but it also doesn't provide additional context like examples or constraints not in the schema.

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

  Purpose4/5

  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 ('new WhatsApp message template'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'list_templates' or 'send_template_message' by focusing on creation rather than listing or sending. However, it doesn't explicitly differentiate from other creation tools (though none exist in the sibling list), keeping it from a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a business account), compare it to similar tools like 'send_template_message', or specify use cases (e.g., for marketing vs. authentication). This lack of context leaves the agent to infer usage from the tool name alone.

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

• list_templatesC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It states it 'List all templates' which implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, pagination behavior, or what format the list returns. For a tool with zero annotation coverage, this is insufficient.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

  Completeness2/5

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

  Given no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what 'list all templates' returns (structure, fields), how it handles optional parameters, or how it differs from related tools. For a listing tool in a rich WhatsApp API context, more context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters fully. The description doesn't add any meaning beyond what the schema provides about 'status_filter' or 'business_account_id'. Baseline 3 is appropriate when the schema does all the parameter documentation work.

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

  Purpose4/5

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

  The description clearly states the action ('List all templates') and the resource ('for a WhatsApp Business Account'), providing specific verb+resource pairing. However, it doesn't explicitly differentiate from sibling tools like 'check_template_status' which might also involve template retrieval, making it a 4 rather than a 5.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'check_template_status' and 'send_template_message', there's no indication whether this is for bulk listing versus status checking or sending. No prerequisites, exclusions, or comparison context is provided.

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

• send_audio_messageC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure but only states what the tool does at a high level. It doesn't mention important behavioral aspects like whether this is a synchronous or asynchronous operation, error handling, rate limits, authentication requirements, or what happens if the audio URL is inaccessible. The description is insufficient for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality, making it easy to parse quickly.

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

  Completeness2/5

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

  For a mutation tool (sending messages) with no annotations and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, success indicators, or how it fits within the broader WhatsApp Business API context. Given the complexity of messaging APIs and lack of structured metadata, more contextual information would be helpful.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any additional meaning about parameters beyond what's in the schema (e.g., it doesn't explain format requirements for audio_url or provide examples). This meets the baseline expectation when schema coverage is complete.

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

  Purpose4/5

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

  The description clearly states the action ('send') and resource ('audio/voice message via WhatsApp Business API'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like send_document_message or send_video_message, which would require mentioning it's specifically for audio files rather than other media types.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like send_text_message or send_video_message. There's no mention of prerequisites (such as needing a WhatsApp Business account), use cases for audio messages, or limitations compared to other messaging tools in the sibling list.

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

• send_document_messageC
  2.9/5.0
  Behavior2/5

  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 states the action ('Send') but doesn't mention critical aspects like authentication requirements, rate limits, error handling, or what happens on success (e.g., message ID returned). This is a significant gap for a tool that likely involves external API calls and mutations.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy.

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

  Completeness2/5

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

  Given the complexity of sending messages via an external API, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral traits, response format, or error scenarios, leaving the agent under-informed about how to use this tool effectively in practice.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting all 5 parameters. The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or constraints. Baseline score of 3 is appropriate since the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Send') and resource ('document message via WhatsApp Business API'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like send_image_message or send_video_message beyond the document type, missing a clear distinction in purpose.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like send_text_message or send_template_message. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

• send_image_messageC
  2.9/5.0
  Behavior2/5

  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 states the action ('Send') but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what happens on success/failure. This is a significant gap for a mutation tool in a messaging API context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the complexity of a messaging API tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.

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

  Parameters3/5

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

  The input schema has 100% description coverage, so parameters are well-documented in the schema itself. The description adds no additional semantic context beyond what the schema provides (e.g., format details for 'to' or 'image_url'), resulting in a baseline score of 3 as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Send') and resource ('image message via WhatsApp Business API'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (like send_audio_message, send_video_message) beyond specifying the media type, missing an opportunity to clarify unique aspects.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives (e.g., send_text_message for text, send_template_message for templates). It lacks context about scenarios where sending an image is appropriate, prerequisites, or any exclusions, leaving usage decisions ambiguous.

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

• send_list_messageC
  2.9/5.0
  Behavior2/5

  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. While 'send' implies a write operation, the description doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what happens upon successful sending. For a mutation tool with zero annotation coverage, this 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with zero wasted verbiage.

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

  Completeness2/5

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

  For a mutation tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It lacks behavioral context (e.g., side effects, error cases), usage differentiation from siblings, and any explanation of the interactive list message concept beyond the name. The schema covers parameters well, but the overall context for an agent is incomplete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaningful semantic context beyond what's in the schema—it doesn't explain the structure of sections/rows, usage patterns, or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('send') and resource ('interactive list message via WhatsApp Business API'), making the purpose evident. However, it doesn't explicitly differentiate this tool from its siblings like send_button_message or send_template_message, which also send interactive messages via the same API.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for sending different message types (e.g., send_button_message, send_template_message), there's no indication of when a list message is appropriate or what distinguishes it from other interactive message types.

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

• send_text_messageC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'send' operation (implying mutation) but doesn't mention authentication requirements, rate limits, error conditions, or what happens on success/failure. For a messaging tool with zero annotation coverage, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place in conveying the core purpose.

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

  Completeness2/5

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

  For a messaging tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after sending (success indicators, message IDs, error responses), doesn't mention authentication or rate limiting, and provides no guidance on tool selection among 10 sibling messaging tools.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (like explaining the relationship between message and template_name). Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('send') and resource ('text message or template message via WhatsApp Business API'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like send_template_message or send_button_message, which would require more specific scope definition to earn a 5.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like send_template_message or send_button_message. There's no mention of prerequisites, use cases, or exclusions, leaving the agent with minimal context for tool selection among the messaging siblings.

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

• send_video_messageC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Send') which implies a write/mutation operation, but doesn't mention authentication requirements, rate limits, error conditions, or what happens upon success. For a tool that interacts with an external API to send messages, this leaves significant behavioral aspects undocumented.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a straightforward tool and gets directly to the point with no unnecessary elaboration.

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

  Completeness2/5

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

  For a tool that sends messages via an external API with no annotations and no output schema, the description is insufficient. It doesn't cover authentication needs, error handling, rate limits, or what the tool returns. Given the complexity of API interactions and the lack of structured behavioral information, the description should provide more operational context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects that the schema does the heavy lifting for parameter documentation, and the description doesn't need to compensate.

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

  Purpose4/5

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

  The description clearly states the action ('Send') and resource ('video message via WhatsApp Business API'), making the purpose immediately understandable. It distinguishes from some siblings like 'send_text_message' by specifying the media type, but doesn't explicitly differentiate from other media-sending tools like 'send_audio_message' or 'send_image_message' beyond the obvious video vs. audio/image distinction.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for sending different message types (text, audio, image, document, template, etc.), there's no indication of when a video message is appropriate versus other media types or text messages. No prerequisites, constraints, or comparative context is mentioned.

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

• check_template_statusB
  3.1/5.0
  Behavior2/5

  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 states the action ('check') but doesn't describe what the check entails (e.g., returns approval state like 'pending', 'approved', 'rejected'), potential errors, or any side effects. This is a significant gap for a tool with no structured safety hints.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

  Completeness3/5

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

  Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It clarifies the purpose but lacks details on behavior, usage context, and return values, which are needed for full agent understanding. It meets the bare minimum but has clear gaps.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional meaning beyond the schema, such as explaining the relationship between template_name and business_account_id or providing examples. Baseline 3 is appropriate since the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with a specific verb ('check') and resource ('approval status of a WhatsApp template'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_templates' or 'create_template', which might also involve template status information, so it falls short of a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_templates' (which might show statuses) or 'send_template_message' (which might require approved templates), nor does it specify prerequisites or exclusions, leaving the agent to infer usage context.

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

• send_button_messageB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions the WhatsApp Business API context but lacks critical behavioral details: authentication requirements, rate limits, error conditions, whether messages are queued or sent immediately, or what happens if buttons exceed the max. The description doesn't compensate for the missing annotations.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('send', 'interactive button message', 'WhatsApp Business API') earns its place by defining scope and differentiation.

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

  Completeness2/5

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

  For a tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the response format, error handling, or operational constraints. Given the complexity and lack of structured data, more context about behavior and outcomes is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples, format details, or constraints explanation). Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

  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 ('interactive button message'), and the platform ('via WhatsApp Business API'). It distinguishes this tool from sibling tools like send_text_message or send_template_message by specifying the button-based interaction type.

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

  Usage Guidelines3/5

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

  The description implies usage for sending button messages on WhatsApp, but provides no explicit guidance on when to choose this over alternatives like send_list_message or send_template_message. No prerequisites, limitations, or exclusion criteria are mentioned.

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

• send_template_messageB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions sending via WhatsApp Business API but lacks critical behavioral details: whether this is a mutation (likely yes, but not stated), rate limits, authentication needs, error handling, or what happens on success/failure. This is inadequate for a tool with potential side effects.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and includes key details (dynamic parameters, WhatsApp Business API) without redundancy.

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

  Completeness2/5

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

  Given no annotations, no output schema, and a mutation-like tool (sending messages), the description is incomplete. It lacks information on behavioral traits, return values, error conditions, and usage context relative to siblings. This leaves significant gaps for an AI agent to operate effectively.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value beyond the schema by mentioning 'dynamic parameters' and 'via WhatsApp Business API', but does not elaborate on parameter usage, constraints, or examples. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('send'), resource ('template message'), and mechanism ('via WhatsApp Business API'), with dynamic parameters highlighted. It distinguishes from siblings like send_text_message or send_image_message by specifying template-based messaging.

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

  Usage Guidelines3/5

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

  The description implies usage for template-based WhatsApp messaging but does not explicitly state when to use this tool versus alternatives like send_text_message or send_button_message. No guidance on prerequisites (e.g., approved templates) or exclusions is provided.

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