Server Quality Checklist

Tool Scores

• mark_message_as_readC
  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. It states the action ('Mark a message as read') but doesn't explain what this entails (e.g., whether it updates message status in a database, triggers notifications, or requires specific authentication). It also omits details like error conditions, rate limits, or side effects, 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.

  Conciseness4/5

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

  The description is well-structured and front-loaded with the core purpose, followed by parameter and return value sections. It avoids unnecessary fluff, but the parameter descriptions could be more informative (e.g., explaining 'sender' usage) without adding bulk, keeping it efficient overall.

  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, mutation action) and lack of annotations, the description is minimally adequate. It covers the basic action and parameters but misses behavioral context (e.g., permissions, effects). The presence of an output schema helps by documenting the return value, but overall completeness is limited for safe tool invocation.

  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 0%, so the description must compensate. It documents both parameters ('message_id' and 'sender') and provides basic semantics (e.g., 'message_id' identifies the message, 'sender' is optional). However, it lacks details like format requirements (e.g., WhatsApp message ID structure) or when 'sender' is needed, leaving gaps that the schema doesn't fill.

  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 ('Mark') and resource ('a message as read'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from potential sibling tools like 'send_reaction' or 'remove_reaction' that might also interact with message status, though the purpose is distinct enough to avoid confusion.

  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., message must exist, user must have permissions) or compare it to related tools like 'send_reaction' for other message interactions. The lack of context leaves the agent to infer usage scenarios independently.

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

• request_locationC
  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 request operation but doesn't describe what happens after the request (does it trigger a special location-sharing interface?), whether there are rate limits, permission requirements, or what the user experience is. The description only covers the basic action without 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.

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, Args, Returns) and appropriately sized. The purpose statement is front-loaded. However, the Args explanations could be more concise, and the Returns section repeats information that could be inferred from the output schema.

  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 3 parameters with 0% schema coverage and no annotations, but with an output schema present, the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines. The output schema means return values don't need explanation, but the description should do more to compensate for the lack of annotations and low schema coverage.

  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 0%, so the description must compensate. It provides a brief explanation of each parameter in the Args section, adding meaning beyond the bare schema. However, the explanations are minimal ('Phone number or WhatsApp ID', 'Message text asking for location') and don't provide format requirements, constraints, or examples. For 3 parameters with 0% schema coverage, this is adequate but basic.

  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 'Request user's location' - a specific verb ('Request') and resource ('user's location'). It distinguishes from siblings like 'send_location' (which sends location from the user) and 'send_message' (general messaging). However, it doesn't explicitly contrast with these alternatives in the purpose statement itself.

  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. There are multiple messaging-related siblings (send_message, send_message_with_buttons, etc.), but no indication of when location requests are appropriate versus other communication methods or how this differs from simply sending a message asking for location.

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

• send_documentC
  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 the tool sends a document message but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the document URL is invalid. The return value is mentioned but without details on failure cases or 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.

  Conciseness4/5

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

  The description is appropriately sized and front-loaded: the first sentence states the purpose clearly. The parameter and return sections are organized but could be more concise; some explanations are brief but effective. Overall, it avoids unnecessary verbosity while maintaining clarity.

  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 6 parameters with 0% schema coverage and no annotations, the description provides basic parameter semantics and mentions returns, but lacks behavioral context. An output schema exists, so return values don't need explanation, but for a messaging tool with siblings, more guidance on usage and errors would improve completeness.

  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 0%, so the description must compensate. It lists all 6 parameters with brief explanations (e.g., 'Phone number or WhatsApp ID' for 'to'), which adds meaning beyond the bare schema. However, it doesn't provide format details, constraints, or examples, leaving gaps in understanding parameter usage.

  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: 'Send a document message.' It specifies the action (send) and resource (document message), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like send_image or send_video, which would require 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 send_message, send_image, send_video, and send_audio, there's no indication of when a document message is appropriate versus other message types. The description only lists parameters without contextual usage advice.

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

• send_contactB
  3.1/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 a contact card' implies a write/mutation operation, the description doesn't disclose important behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the contact already exists. The Returns section mentions success status and message ID but doesn't explain failure scenarios or 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.

  Conciseness4/5

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

  The description is well-structured with clear sections (Args, Returns) and front-loads the core purpose. Each sentence serves a purpose: the first states the action, followed by parameter explanations and return value information. It could be slightly more concise by integrating the Args explanations into a single paragraph, but overall it's efficient.

  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 that this is a mutation tool with no annotations, 4 parameters, and an output schema exists, the description is moderately complete. The output schema handles return values, so the description doesn't need to explain those. However, for a tool that sends data (implying side effects), the description should ideally mention authentication needs, error handling, or platform-specific constraints, which are missing.

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

  Parameters4/5

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

  With 0% schema description coverage, the description must compensate, and it does so effectively. The Args section clearly explains each parameter's purpose: 'to' as the recipient, 'contact_name' and 'contact_phone' for the contact details, and 'reply_to_message_id' for threading. This adds meaningful context beyond the bare schema, though it doesn't specify format requirements (e.g., phone number format).

  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 a contact card') and specifies the resource (contact card), which is a specific verb+resource combination. It distinguishes this from sibling tools like send_message or send_image by focusing on contact cards specifically. However, it doesn't explicitly differentiate from all similar messaging tools beyond the contact card focus.

  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. While sibling tools include various send_* methods (send_message, send_image, etc.), there's no indication of when a contact card is appropriate versus other message types. The description lacks any context about use cases, prerequisites, or exclusions.

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

• send_locationB
  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 full burden for behavioral disclosure. While 'Send' implies a write operation, it doesn't specify whether this requires specific permissions, whether it's rate-limited, what happens on failure, or if the location is shared immediately or queued. The return value mention is helpful but minimal.

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

  Conciseness4/5

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

  The description is efficiently structured with a clear purpose statement followed by organized parameter and return sections. Every sentence serves a purpose with no redundant information. The formatting with 'Args:' and 'Returns:' headers makes it scannable, though it could be more front-loaded with critical context.

  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?

  For a messaging tool with 6 parameters, no annotations, and an output schema, the description covers the basics but has significant gaps. It documents parameters adequately but lacks behavioral context about permissions, limitations, or error handling. The presence of an output schema reduces the need to describe return values, but more operational guidance would be beneficial.

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

  Parameters4/5

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

  With 0% schema description coverage, the description compensates well by listing all 6 parameters with brief explanations. It clarifies that 'to' accepts 'Phone number or WhatsApp ID', distinguishes between required coordinates and optional metadata, and explains reply_to_message_id purpose. However, it doesn't provide format details or constraints beyond basic types.

  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 as 'Send a location message' which is a specific verb+resource combination. It distinguishes itself from siblings like send_message or send_contact by specifying it sends location data rather than text or contact information. However, it doesn't explicitly contrast with request_location which might be a complementary tool.

  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 when to choose send_location over send_message with location text, or how it relates to request_location. There's no context about appropriate use cases or prerequisites beyond what's implied by the parameters.

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

• send_reactionB
  3.1/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. It mentions that it 'Sends a reaction' and returns a 'Dictionary with success status', but fails to disclose critical behavioral traits like authentication requirements, rate limits, error handling, or whether it's a read-only or destructive operation. This leaves significant gaps for an agent to understand how to use it safely and effectively.

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

  Conciseness4/5

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

  The description is well-structured with a clear purpose statement followed by parameter and return value sections. It's front-loaded and efficient, with no wasted sentences, though it could be slightly more concise by integrating the 'Args' and 'Returns' into the main flow without separate headings.

  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 complexity of a messaging reaction tool with no annotations and 0% schema coverage, the description is moderately complete. It covers the basic purpose and parameters, and an output schema exists, so return values don't need explanation. However, it lacks behavioral details and usage guidelines, making it inadequate for full contextual understanding.

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

  Parameters4/5

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

  The description includes an 'Args' section that explains each parameter's purpose (e.g., 'to: Phone number or WhatsApp ID', 'emoji: Reaction emoji'), adding meaningful context beyond the input schema, which has 0% description coverage. This compensates well for the schema's lack of descriptions, though it doesn't detail format constraints or examples for parameters like 'emoji'.

  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 a reaction') and target ('to a message'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'remove_reaction' or other messaging tools, though the purpose is distinct enough to be understood in context.

  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_message' or 'remove_reaction'. It lacks context about prerequisites, such as needing an existing message to react to, or exclusions, making it minimally helpful for decision-making.

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

• send_videoB
  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 mentions 'send' implies a write operation but doesn't cover critical aspects like authentication needs, rate limits, error handling, or whether the video is uploaded or referenced by URL/ID. The return format is mentioned but lacks detail on 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.

  Conciseness4/5

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

  The description is well-structured with a brief purpose statement followed by Args and Returns sections. It's front-loaded and efficient, though the Args section could be slightly more concise (e.g., combining optional notes). Every sentence adds value without redundancy.

  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 5 parameters with 0% schema coverage and no annotations, the description does a decent job explaining parameters and return values. However, as a mutation tool (sending messages), it lacks details on behavioral traits like auth, errors, or side effects. The output schema exists, so return values are covered, but overall completeness is moderate due to missing operational context.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It effectively explains all 5 parameters: 'to' as phone number/WhatsApp ID, 'video' as URL or media ID, and optional fields like caption, footer, and reply_to_message_id. This adds clear meaning beyond the bare schema, though it doesn't specify format details (e.g., URL requirements).

  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 verb 'send' and resource 'video message', making the purpose immediately understandable. It distinguishes from siblings like send_audio or send_image by specifying video content, though it doesn't explicitly contrast with send_message (which might handle text).

  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?

  No guidance is provided on when to use this tool versus alternatives like send_message or send_audio. The description lacks context about prerequisites (e.g., WhatsApp setup), exclusions, or comparisons to sibling tools, leaving the agent to infer usage scenarios.

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

• send_audioB
  3.2/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. It states the action ('send an audio message') and return format, but lacks critical details: it doesn't mention authentication requirements, rate limits, error conditions, whether the audio is uploaded or referenced by URL/ID, or what happens if the send fails. 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 well-structured and front-loaded with the core purpose, followed by clear sections for arguments and returns. Every sentence earns its place: the first states the action, and the subsequent lines efficiently document parameters and output without redundancy or fluff.

  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 (3 parameters, mutation operation) and the presence of an output schema (which covers return values), the description is partially complete. It explains parameters well but lacks behavioral context like auth needs or error handling. With no annotations, it should do more to compensate, making it adequate but with clear gaps.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaningful context for all three parameters: 'to' is clarified as 'Phone number or WhatsApp ID', 'audio' as 'Audio URL or media ID', and 'reply_to_message_id' as 'Message ID to reply to'. This goes beyond the schema's bare titles, though it could provide more detail on formats or constraints (e.g., URL requirements).

  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 ('send') and resource ('audio message'), making it immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like send_message, send_video, or send_document, which all share the 'send' pattern but with different 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. With multiple sibling tools for sending different media types (e.g., send_message, send_image, send_video), there's no indication of when an audio message is preferred or what contexts it's suited for, leaving the agent to guess based on parameter names alone.

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

• send_imageB
  3.2/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 the action ('send') but doesn't disclose behavioral traits like whether this requires authentication, has rate limits, what happens on failure, or if it's idempotent. The description is minimal and lacks crucial operational context for a messaging tool.

  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 efficiently structured: a clear purpose statement followed by organized Args and Returns sections. Every sentence earns its place—no fluff or repetition. It's front-loaded with the core function and uses bullet-like clarity for parameters.

  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 no annotations and an output schema (implied by Returns), the description is partially complete. It covers parameters well and specifies the return format, but lacks behavioral context (e.g., error handling, side effects). For a messaging tool with potential delivery issues, more operational guidance would improve completeness.

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

  Parameters4/5

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

  With 0% schema description coverage, the description compensates well by explaining all 5 parameters in the Args section. It clarifies semantics: 'to' as phone number or WhatsApp ID, 'image' as URL or media ID, and optional fields like caption and footer. This adds significant value beyond the bare schema, though it could detail format constraints (e.g., URL requirements).

  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: 'Send an image message.' It specifies the verb ('send') and resource ('image message'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like send_video or send_document, which would require mentioning it's specifically for images.

  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 siblings like send_message, send_video, and send_document, there's no indication of when an image message is preferred over other message types or what contexts warrant its use. The agent must infer usage from the name alone.

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

• send_stickerB
  3.2/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 for behavioral disclosure. While 'send' implies a write operation, the description doesn't cover important behavioral aspects: whether this requires specific permissions, rate limits, authentication needs, what happens if the sticker URL is invalid, whether the message is ephemeral or persistent, or error conditions. The return value mention is helpful but minimal.

  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 perfectly structured and concise: a clear purpose statement followed by organized parameter explanations and return value information. Every sentence earns its place, with no redundant information. The Args/Returns formatting makes it easy to scan while maintaining complete information.

  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 3 parameters with 0% schema coverage and no annotations, the description does a reasonable job but has gaps. The output schema exists (mentioned in Returns), so describing return values isn't needed. However, for a messaging tool with behavioral implications and multiple similar siblings, more context about when/why to use stickers would improve completeness. The parameter explanations are good but could benefit from more behavioral context.

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

  Parameters4/5

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

  With 0% schema description coverage, the description adds significant value by explaining all three parameters: 'to' as phone number or WhatsApp ID, 'sticker' as URL or media ID with format constraint (webp), and 'reply_to_message_id' as optional reply target. This compensates well for the schema's lack of descriptions, though it doesn't cover all edge cases or provide examples.

  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 verb 'send' and the resource 'sticker message', making the purpose immediately understandable. It distinguishes this tool from other messaging tools like send_message or send_image by specifying it's for stickers specifically. However, it doesn't explicitly differentiate from all siblings like send_template or send_video beyond the sticker focus.

  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 messaging siblings (send_message, send_image, send_video, send_audio, send_document, send_template), there's no indication of when a sticker is appropriate versus other message types. No prerequisites, exclusions, or context for choosing stickers over other content types are mentioned.

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

• get_templatesB
  3.3/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. It states the tool returns a list, but doesn't mention whether it's paginated, if there are rate limits, authentication requirements, or error conditions. For a read operation 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 efficiently structured with a clear purpose statement followed by separate 'Args' and 'Returns' sections. Every sentence adds value without redundancy, making it easy to parse and understand quickly.

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

  Completeness4/5

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

  Given the tool's low complexity (2 optional parameters) and the presence of an output schema (implied by 'Returns' statement), the description is reasonably complete. It covers the purpose and parameters adequately, though it could benefit from more behavioral context given the lack of annotations.

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

  Parameters4/5

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

  With 0% schema description coverage, the description compensates well by explaining both parameters: 'limit' as 'Maximum number of templates to return (default: 100)' and 'name' as 'Optional template name filter.' This adds meaningful context beyond the bare schema, though it doesn't specify format details for the name filter.

  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: 'Get list of available WhatsApp templates.' It specifies the verb ('Get') and resource ('WhatsApp templates'), making it immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'send_template' or 'upload_media', which prevents 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. With sibling tools like 'send_template' that likely use templates, there's no indication of whether this tool should be used for discovery before sending or for other purposes. The absence of any usage context leaves the agent without direction.

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

• remove_reactionB
  3.4/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 is 'Remove' (implying mutation) and mentions a return dictionary with success status, but lacks critical details: permission requirements, whether the operation is reversible, error conditions, or rate limits. For a mutation 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.

  Conciseness4/5

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

  The description is efficiently structured with a clear purpose statement followed by parameter explanations and return value note. Every sentence adds value, though the formatting with 'Args:' and 'Returns:' sections could be more integrated. It's appropriately sized for a tool with three parameters.

  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 a mutation tool with no annotations, 3 parameters (0% schema coverage), and an output schema present, the description is minimally adequate. It explains parameters semantically and mentions the return structure, but lacks behavioral context about permissions, side effects, or error handling. The output schema existence reduces the need to detail return values, but more operational guidance would improve completeness.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It provides clear semantic explanations for all three parameters: 'to' as 'Phone number or WhatsApp ID', 'message_id' as 'ID of message to remove reaction from', and 'sender' as 'Optional sender phone ID'. This adds meaningful context beyond the bare schema, though it doesn't specify format requirements or constraints.

  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 ('Remove a reaction') and target resource ('from a message'), distinguishing it from sibling tools like 'send_reaction' which adds reactions. It uses precise language that immediately communicates the tool's function without ambiguity.

  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?

  No guidance is provided about when to use this tool versus alternatives. While the purpose distinguishes it from 'send_reaction', there's no explicit mention of prerequisites, constraints, or typical use cases. The description assumes context but doesn't provide usage instructions.

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

• upload_mediaA
  3.5/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 but only mentions the upload action and return format. It lacks critical behavioral details such as authentication requirements, file size limits, rate limits, or whether this is a destructive/write operation. 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 efficiently structured with a clear purpose statement followed by parameter and return documentation. Every sentence earns its place with no wasted words, and the information is front-loaded appropriately.

  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 a mutation tool with no annotations, 2 parameters, and an output schema (which covers return values), the description is moderately complete. It explains the purpose and parameters but lacks behavioral context like permissions or limits. The output schema reduces the need to document returns, but more operational guidance would be helpful.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It explicitly documents both parameters: 'media_path' as 'Path to media file' and 'mime_type' as 'Optional MIME type', adding essential meaning beyond the bare schema. However, it doesn't provide format examples or constraints for the path parameter.

  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 ('Upload media file') and target ('to WhatsApp servers'), distinguishing it from sibling tools like send_audio or send_image which send media rather than upload it. The verb+resource combination is precise and unambiguous.

  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?

  No guidance is provided on when to use this tool versus alternatives like send_audio or send_image, nor any prerequisites or context for usage. The description only states what it does, not when it should be used in relation to other tools.

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

• send_templateA
  3.6/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 the action ('Send') but doesn't disclose behavioral traits like required permissions, rate limits, error conditions, or what happens if the template doesn't exist. The return format is mentioned but lacks detail on failure cases.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded with the core purpose. The parameter explanations are organized but slightly verbose; every sentence earns its place by clarifying parameters that lack schema descriptions.

  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 5 parameters with 0% schema coverage and no annotations, the description does well on parameters but lacks behavioral context for a mutation tool. The output schema exists, so return values don't need explanation, but completeness is moderate due to missing operational details.

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

  Parameters4/5

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

  With 0% schema description coverage, the description compensates by explaining all 5 parameters: 'to' (phone/ID), 'name' (template name/ID), 'language' (code with default), 'params' (optional components), and 'reply_to_message_id' (message ID). This adds significant meaning beyond the bare schema, though some details like param structure could be clearer.

  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 a WhatsApp template message') with the resource identified. It distinguishes this tool from siblings like 'send_message' or 'send_message_with_buttons' by specifying it's for template-based messages, not free-form or button-based ones.

  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 WhatsApp template messages, but doesn't explicitly state when to use this versus alternatives like 'send_message' or 'send_message_with_buttons'. No guidance on prerequisites 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.

• send_message_with_listA
  4/5.0
  Behavior4/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 effectively describes key behavioral traits: it's a sending operation (implies mutation/creation), includes detailed constraints (e.g., max sections, character limits), provides a comprehensive example showing the structure, and specifies the return format. However, it doesn't mention potential side effects like rate limits or authentication needs.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (CONSTRAINTS, EXAMPLE, Args, Returns) and front-loaded purpose. However, it's somewhat lengthy due to the detailed example and constraints list. Every sentence adds value, but it could be more concise by integrating constraints into the Args section more tightly.

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

  Completeness4/5

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

  Given the tool's complexity (7 parameters, nested structures in sections), no annotations, and an output schema (Returns section), the description is largely complete. It covers purpose, constraints, example usage, parameter details, and return values. The main gap is the lack of usage guidelines compared to sibling tools, but it compensates well with detailed behavioral and parameter information.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must fully compensate. It provides extensive parameter semantics: detailed constraints for each field (e.g., 'Button text: max 20 characters'), clear explanations in the example and Args section (e.g., 'to: Phone number (with country code) or WhatsApp ID'), and distinguishes required vs. optional parameters. This goes well beyond what the bare schema provides.

  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 tool's purpose: 'Send a message with a selection list.' It specifies the exact action (send) and resource (message with selection list), distinguishing it from sibling tools like send_message or send_message_with_buttons. The title is null, so the description fully carries this burden.

  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_message or send_message_with_buttons. It lists constraints and an example but doesn't explain the appropriate context or prerequisites for sending a selection list versus other message types.

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

• send_messageA
  4.3/5.0
  Behavior3/5

  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 action is a 'send' operation (implying mutation/write) and describes the return format, which is good. However, it lacks details about authentication requirements, rate limits, error conditions, or whether the message is queued vs. sent immediately—important behavioral context for a messaging tool.

  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 efficiently structured: a clear purpose statement upfront, followed by well-organized parameter explanations in bullet-like format, and ending with return value information. Every sentence adds value with no redundancy or fluff.

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

  Completeness4/5

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

  Given the tool's complexity (6 parameters, mutation operation) and no annotations, the description does well by explaining all parameters and the return format. However, it lacks some behavioral context (like error handling or delivery guarantees) that would be helpful. The presence of an output schema reduces the need to fully document returns, but more operational context would improve completeness.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate fully. It provides clear semantic explanations for all 6 parameters beyond just their names: specifying format requirements ('Phone number with country code'), purpose ('for interactive messages'), defaults ('default False'), and relationships ('Message ID to reply to'). This adds significant value over the bare schema.

  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 a text message') and target resource ('to a WhatsApp user'), distinguishing it from sibling tools like send_audio, send_image, or send_template which handle different message types. It's precise and unambiguous about its function.

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

  Usage Guidelines4/5

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

  The description implies usage context for sending basic text messages, and the parameter explanations (e.g., 'for interactive messages') provide some situational guidance. However, it doesn't explicitly state when to use this versus alternatives like send_message_with_buttons or send_template, which would be helpful for sibling differentiation.

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

• send_message_with_buttonsA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well. It discloses key behavioral traits: maximum button count (3), character limits for various fields, optional parameters, and the return format. It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial operational context beyond basic functionality.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, constraints, example, args, returns). Every sentence adds value, though it could be slightly more front-loaded. The example is helpful but adds length. Overall efficient with minimal waste.

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

  Completeness5/5

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

  Given the tool's complexity (6 parameters, interactive messaging), no annotations, and the presence of an output schema, the description is complete. It covers purpose, constraints, parameter semantics, example usage, and return format. The output schema handles return values, so the description appropriately focuses on usage context.

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

  Parameters5/5

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

  With 0% schema description coverage, the description fully compensates by providing detailed parameter information. The 'Args' section explains each parameter's purpose, format, and constraints. The example illustrates proper usage, and constraints clarify limits. This adds significant value beyond the bare schema.

  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 tool's purpose: 'Send a message with reply buttons (up to 3).' It specifies the exact action (send), resource (message), and distinctive feature (reply buttons) that differentiates it from sibling tools like 'send_message' or 'send_message_with_list'. The verb+resource combination is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context about when to use this tool: when sending messages with interactive buttons. It doesn't explicitly state when NOT to use it or name specific alternatives among siblings, but the functional scope is well-defined. The constraints section implicitly guides usage by setting boundaries.

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

• indicate_typingA
  4.6/5.0
  Behavior4/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 effectively describes key behavioral traits: the typing indicator duration (max 25 seconds), dismissal conditions (when sending next message), and the read-marking side effect. However, it doesn't mention potential errors, rate limits, or authentication requirements.

  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 well-structured with clear sections (purpose, notes, example, args, returns). Every sentence adds value: the opening states the core function, the notes provide critical behavioral context, the example illustrates usage, and the parameter/return explanations are necessary given the 0% schema coverage.

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

  Completeness4/5

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

  For a tool with no annotations, 0% schema coverage, but with an output schema, the description does well by covering purpose, usage, behavior, and parameters. The output schema handles return values, so the description appropriately focuses on input semantics and behavioral context. Minor gaps include lack of error handling details.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It provides an example showing 'message_id' usage and explains that 'sender' is optional with a default. While it clarifies the purpose of 'message_id' (to respond to incoming message), it doesn't fully detail 'sender' semantics beyond the default.

  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 tool's purpose with specific verbs ('show typing indicator', 'marks a message as read') and resources ('WhatsApp user'). It distinguishes from siblings like 'mark_message_as_read' by emphasizing the typing indicator display and user experience improvement for delayed responses.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use ('Best practice when it will take a few seconds to respond'), when not to use ('Only use if you are actually going to respond'), and alternatives (implied by sibling tools like 'send_message' for immediate responses). The 'IMPORTANT NOTES' section reinforces usage context.

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