1msg MCP

Official

by 1msg

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.0
Disambiguation2/5
Many tools are distinct, but overlaps exist: delete_media and delete_media_legacy are the same operation, send_message may be confused with the many send_* variants, and the abundance of get/set pairs for settings creates ambiguity about which tool applies to a given task.
Naming Consistency2/5
Naming mixes verb-first and noun-first patterns, with inconsistent use of get/list/create/update/set/delete/patch and path-like suffixes (e.g., create_flows_flow_id_publish). While all snake_case, the lack of a uniform verb_noun pattern hurts predictability.
Tool Count1/5
With 60 tools, this server is far beyond typical well-scoped MCP servers. Even for a comprehensive WhatsApp Business API, the surface is extremely large and likely to overwhelm agents with too many options.
Completeness4/5
The tool set covers a wide range of capabilities: messaging, media, groups, flows, templates, settings, webhooks, encryption, and calling. Minor gaps include reporting/analytics and limited message history beyond list_messages, but core workflows are well covered.
Average 2.3/5 across 60 of 60 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description of side effects, return values, or required permissions, the agent receives zero insight into the tool's behavior. 'Create Flow' reveals nothing about what happens on invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, this is under-specification rather than conciseness. The phrase 'Create Flow' carries no informative content and does not earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count, absence of annotations, and no output schema, the description should provide substantial context, but it provides none. The tool is practically unusable by an agent without additional implicit knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. The single parameter 'wabaAccountId' is left completely unexplained, leaving the agent guessing about its format, purpose, or whether it is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create Flow' is a tautology that simply restates the tool name. It does not specify what a flow is, what creating it entails, or how it differs from sibling tools like create_flows_flow_id_publish or create_flows_flow_id_deprecate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There is no mention of prerequisites, typical use cases, or why one might choose create_flows over other flow-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Delete Flow' without indicating whether deletion is permanent, cascading, requires authentication, or affects published flows. This is a destructive, irreversible operation with zero 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.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
'Delete Flow' is severely under-specified, not concisely informative. It lacks necessary details and is essentially a fragment that repeats the name. It does not earn its place as a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, no output schema, and two undocumented parameters, the one-line description is completely inadequate. It does not cover return values, side effects, prerequisites, or parameter roles, making it impossible for an agent to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (flowId, wabaAccountId) with no descriptions, and the tool description provides no explanation of what these parameters mean or how to use them. Schema description coverage is 0%, so the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete Flow' simply restates the tool name delete_flows_flow_id without adding any specificity or distinguishing context. It confirms the verb and resource but provides no additional detail about the deletion scope or uniqueness compared to sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as delete_groups_group_id or remove_template. No scenarios, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility, but it provides zero behavioral detail. It does not mention whether the operation is read-only, what results look like, or any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, this is under-specification rather than conciseness. No structure or additional context is given, leaving the description without substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks annotations, output schema, and meaningful description. For a preview operation expected to return some representation of a flow, the description is entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation of flowId or wabaAccountId. The tool name hints at a flow but fails to clarify parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Preview Flow' is a near-tautology, restating the tool name without explaining what 'preview' entails or how it differs from get_flows_flow_id. It lacks specificity about the operation and resources involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling tools like get_flows_flow_id or list_flows. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. 'Send Carousel' only implies a send operation and discloses no side effects, requirements (e.g., chatId vs phone), expected output, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, but this is under-specification rather than conciseness. There is no front-loaded information because there is no information at all; the short length does not help the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 parameters, numerous sibling send tools, no output schema, and no annotations. The description is completely inadequate for an agent to select and invoke this tool correctly; it fails to provide even the most basic contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters (body, phone, chatId, params, quotedMsgId). The agent has no idea what the 'params' array should contain or how it relates to a carousel, so the description adds zero semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send Carousel' merely restates the tool name 'send_carousel' with no additional meaning. It does not specify what a carousel is, what action is performed, or how it differs from other send_* siblings like send_list or send_button. This is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling send_* tools. The description provides no context, prerequisites, alternatives, or exclusions, leaving the agent with no criteria for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details. It does not disclose side effects, required permissions, rate limits, return values, or whether the operation is destructive. The description fails to communicate any behavioral traits beyond the action of 'sending'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which could be considered concise, but it is under-specified and does not convey essential information. It is more of a placeholder than a useful tool description, so it cannot earn a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (arbitrary payload object, no output schema, many sibling tools), the description is completely inadequate. It provides no information about return values, error cases, or how this tool fits among the alternatives, making it impossible for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'payload' with no description, and schema description coverage is 0%. The description does not explain what the payload should contain or how it is used. Since the schema only defines an arbitrary object, the empty description leaves the parameter semantics completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a Product' provides a verb and resource, but it is extremely vague and does not distinguish this from the many sibling 'send_*' tools such as send_message, send_file, or send_order_details. It does not clarify what a 'product' refers to or what the tool actually accomplishes beyond the generic verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the numerous sibling send tools. No context, prerequisites, or alternative references are provided, leaving the agent without any direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description carries no behavioral context. It does not disclose side effects, reversibility, required permissions, or what happens to the flow after deprecation. The description is purely tautological and provides no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While only two words long, this is under-specification rather than concise effectiveness. It lacks any meaningful content that would help an agent understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, two undocumented parameters, and a tautological description, the description is far too thin to support correct invocation or outcome expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions neither flowId nor wabaAccountId. The schema itself only lists types, so there is no semantic enrichment for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deprecate Flow' simply restates the action implied by the tool name (create_flows_flow_id_deprecate) with no additional specificity about what deprecation entails or how it differs from siblings like delete_flows_flow_id or patch_flows_flow_id_metadata.
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. The description does not mention scenarios, prerequisites, or why one would deprecate a flow rather than delete or modify it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing side effects, permissions, or expected outcomes. 'Send a File' reveals nothing about whether the operation mutates data, requires authentication, or has limitations. The agent is left blind.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a two-word phrase, which is not conciseness but under-specification. It lacks any structure or highlighted critical information, failing to earn its place as a useful guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, no output schema), the description is critically insufficient. It does not explain what a file is, how it is sent, what the response contains, or how to select between the many send_* alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 9 parameters and 0% schema description coverage, the description adds no meaning to the parameter names. The ambiguity between body, mediaId, filename, and mediaType is entirely unresolved, and the agent receives no guidance on which fields are required or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a File' is a direct restatement of the tool name, providing a clear verb and resource but no differentiation from sibling tools like send_message, send_contact, or send_button. It does not specify what kind of file, the transport mechanism, or any unique scope.
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?
There is no guidance on when to use send_file instead of other send_* tools, nor any context about prerequisites or exclusions. The description is entirely silent on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description gives no behavioral details such as side effects, authentication requirements, or rate limits. For a send operation, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is extremely short but this is under-specification, not conciseness. It adds no value and fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is completely inadequate. It does not explain how to format a list message, what sections are, or any invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% description coverage, and the description itself mentions none of them (body, phone, action, sections, buttonText). There is no guidance on how to structure the message or what each parameter means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send List Message' essentially restates the tool name 'send_list'. It provides no additional context about what a list message is or how it differs from sibling send tools like send_message or send_carousel, making it a tautology.
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. The description is silent on use cases, prerequisites, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it does not mention any side effects, prerequisites, or outcomes. It is impossible to know whether this tool prompts the user, requires special permissions, or has particular message format requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (only four words) but it is under-specified rather than effective. It merely repeats the tool name and does not front-load any actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no annotations, and no output schema, this description is completely inadequate. It fails to explain the tool's purpose, behavior, or parameter roles, making it impossible to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'body' or 'phone' parameters. There is no information about what body should contain or how phone should be formatted, so the parameters remain entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send Location Request Message' is essentially a restatement of the tool name, adding only the word 'Message'. It does not clarify what distinguishes a location request from a location send, making it fall into the tautology category.
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?
There is no guidance on when to use this tool versus any of the many sibling send_* tools. No context, exclusions, or alternative recommendations are provided, leaving 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it offers none. It does not mention side effects, authentication needs, rate limits, or what the response contains, providing zero transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse but under-specifies rather than being concise. The single sentence 'Send a Message' contains no operational information and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, no annotations, and a large set of siblings, the description is almost entirely incomplete. It does not explain how to specify recipients, what the message body should be, or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters 'body', 'phone', 'chatId', or 'quotedMsgId'. It fails to explain which are required, what they represent, or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a Message' is essentially a restatement of the tool name 'send_message'. It provides no specificity about message type, recipient, or channel, and does not distinguish it from numerous sibling tools like send_file, send_contact, or send_button.
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?
There is no guidance on when to use this tool versus the many alternative send_* tools. The description does not mention use cases, prerequisites, or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. 'Send Reaction' only states the basic action without explaining what a reaction is, whether it modifies existing messages, any side effects, or required permissions. There is no mention of how the tool operates beyond the name, giving the agent essentially no insight into its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It is a single phrase that lacks necessary details to be useful, and it does not earn its place by providing substantive information. It is not a well-structured or sufficiently informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three undocumented parameters, no annotations, and no output schema, the description fails to provide any meaningful context. It does not explain what a reaction is, how it is sent, or what the parameters do. The description is completely inadequate for the tool's complexity, leaving the agent without the information needed to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter details in the description, the agent is left with no understanding of 'body', 'phone', or 'quotedMsgId'. The description 'Send Reaction' does not compensate or clarify what each parameter means or how they relate to the action. It adds no semantic value over the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send Reaction' is essentially a restatement of the tool name 'send_reaction'. It identifies the action (send) and object (reaction) but adds no specificity that distinguishes it from sibling tools like send_message or send_sticker. This qualifies as a tautology rather than a clear, informative purpose statement.
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 does not mention any context, prerequisites, or exclusions. The verb 'send' implies a generic usage, but there is no explicit or implicit direction about appropriate scenarios compared to the many other send_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 disclosing side effects, permissions, or irreversibility. The phrase 'Update' implies mutation, but there is no mention of what changes are made, whether they are reversible, or required scopes. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a three-word phrase with minimal structure. While it contains no filler, it is severely under-specified and fails to serve as a useful descriptive sentence. This is not conciseness but under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description is wholly inadequate. It does not explain the purpose of the parameters, the return value, potential errors, or the operational context. The tool name hints at flow assets but the description adds no contextual depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. The two parameters (flowId, wabaAccountId) are only indicated by name and type, with no semantic meaning added. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update Flow Structure' provides a verb and a resource, indicating it modifies flow structure. However, 'Flow Structure' is vague and does not specify what 'assets' means in the tool name, nor does it distinguish from sibling tools like patch_flows_flow_id_metadata. It is clear but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool versus alternatives such as patch_flows_flow_id_metadata or create_flows, nor does it mention any prerequisites or context. Zero guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It is a single phrase with no mention of side effects, permissions, response format, or whether this mutates state. The tool clearly sends a message, but no behavioral details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It merely restates the tool name with a synonym and provides no useful structure or additional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is entirely inadequate. It fails to explain the message format, required vs optional params, how phone/chatId are used, or the expected behavior. The single phrase provides almost no context for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameter. The schema lists body, phone, chatId, and quotedMsgId without descriptions, and the description neither explains the role of body nor how the other parameters relate to an address request. The description adds no parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send address request message' adds 'request' to clarify the tool sends a request for an address, not just an address. It distinguishes somewhat from siblings like send_location_request or send_message, but the purpose remains vague because it does not explain what an address request message is or what triggers it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description gives no indication of when to use this tool versus similar send_* siblings such as send_location_request, send_contact, or send_message. There is no context about prerequisites or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'Send sticker message' only implies a write operation but does not mention side effects, permissions, reversibility, or response expectations. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than appropriately concise. Four words do not provide sufficient information for a tool with 5 parameters, and the single sentence fails to earn its place beyond being a bare restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), this description is completely inadequate. It does not explain what a sticker message is, when to use it, or any parameter semantics, making it impossible for an agent to invoke the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention any of the 5 parameters (link, phone, chatId, mediaId, quotedMsgId). The description adds no meaning to the parameters, leaving the agent without any clues about their purpose or required formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send sticker message' simply restates the tool name 'send_sticker' without adding any new information about what a sticker message is or how it differs from other send tools. It is a tautology that fails to distinguish this tool from siblings like send_message or send_file.
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. With many sibling send tools (send_button, send_carousel, send_contact, etc.), the description offers no contextual clues or exclusions, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The single sentence only implies a mutation via 'set' but does not disclose whether settings are overwritten, partially updated, or whether there are any side effects. There is no information about permissions, validation, or default behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief at one sentence, but it is under-specified rather than concise. Every word is generic, and the lack of detail forces the agent to rely entirely on the schema. The sentence could be improved by listing the adjustable settings or typical use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with three parameters and no output schema. It does not explain what happens when settings are applied, whether all fields are required despite the schema marking none as required, or what the response will be. Given the sibling context of get_conversational_automation, the description should clarify the relationship and expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines three parameters—prompts, commands, and enable_welcome_message—with zero schema description coverage. The description does not add any meaning to these parameters, leaving the agent to infer that prompts is an array of strings, commands has nested objects, and enable_welcome_message is a boolean. It fails to explain the purpose or format of each parameter, especially the structure of command objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'set' with the resource 'conversational automation settings', indicating the action. However, it lacks specificity about which settings are configured and does not differentiate from sibling tools beyond the obvious get/set contrast. The schema shows prompts, commands, and welcome message, but the description fails to mention them.
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 is no mention of the sibling get_conversational_automation or any prerequisites, such as requiring an existing automation. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only says 'Get Groups List' and discloses no behavioral traits such as read-only nature, pagination, rate limits, or authorization requirements. The agent gets no additional insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than genuine conciseness. 'Get Groups List' is essentially a label that restates the tool name, providing no substantive information to the agent.
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?
Despite the tool's low complexity (0 params, no output schema), the description lacks essential context such as the scope of the group list and how it relates to other group-related tools. It barely covers the basic purpose and leaves the agent to infer semantics from the name.
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 tool has zero parameters, so the description doesn't need to add parameter detail. The baseline of 4 is appropriate because there are no parameters to clarify or document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Groups List' states a verb and resource, but it merely rephrases the tool name 'list_groups' without adding specificity or scope. It doesn't differentiate from sibling tools like get_groups_group_id, which retrieves a single group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention that this lists all groups while get_groups_group_id fetches a specific group, nor does it provide any context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a description that merely says 'Create Group', there is zero disclosure of behavioral traits such as side effects, authentication requirements, idempotency, or response behavior. The description carries the full burden and fails to meet it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely under-specified. Although it is short, it does not earn its place because it conveys no more than the tool name, failing to deliver any functional or contextual value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for the tool's complexity. There are no annotations, no output schema, and no parameter schema, yet the description explains nothing about what creating a group entails, expected input, permissions, or outcomes. An agent would have to guess or rely on external knowledge.
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 input schema has zero properties, so there are no parameters to document. The baseline for a 0-parameter tool is 4, and the description is not required to add parameter meaning when none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create Group' restates the tool name without adding any scope or distinguishing detail. It does not differentiate from sibling tools such as create_groups_group_id or other create_* endpoints, making it a tautology.
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 usage context is provided. The description gives no guidance on when to choose this tool over alternatives, no prerequisites, and no mention of related workflow steps, leaving the agent without any orienting information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 it only repeats the verb 'Get', implying a read operation without any specifics. It does not mention required permissions, response format, side effects, or any other behavioral traits beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but that is under-specification rather than conciseness. It says nothing beyond the tool name, so it fails to earn its place; a useful description would add context or guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 tautological description, the tool is nearly featureless to an agent. The agent has no idea what 'calling settings' encompasses, what the response looks like, or how this relates to update_calling_settings. This is inadequate for a tool that needs to be selected and invoked correctly.
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 tool has zero parameters, and the schema is trivially complete (100% coverage). As per the rubric, 0 params baseline is 4. The description adds no parameter info, but there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get calling settings' is a direct restatement of the tool name 'get_calling_settings', making it a tautology. It provides no additional details about what 'calling settings' specifically refers to, nor does it differentiate from siblings like 'update_calling_settings' beyond the verb.
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 gives no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or recommended contexts. Sibling tools exist (e.g., update_calling_settings) but no comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get Group Info', which merely restates the tool's name and implies read-only behavior. It does not describe the return format, error handling, authentication requirements, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence with no waste. However, it is under-specified and does not front-load any useful detail beyond what the tool name already conveys.
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 simple get operation with one parameter and no output schema or annotations, the description is too thin. It does not explain what 'Group Info' includes, such as members, settings, or metadata, leaving the agent to guess the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the groupId parameter at all. The parameter's meaning is inferred solely from its name, with no additional context about format, source, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Group Info' uses a clear verb and resource, but it is vague about what specific information is returned. It does not differentiate this tool from the sibling get_groups_group_id_invitelink, since both are about getting group-related data.
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. There is no mention of scenarios, exclusions, or alternative tools such as list_groups or get_groups_group_id_invitelink.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It implies a destructive/mutating action (create) but does not disclose any side effects, permissions required, rate limits, or what happens on success/failure. Beyond the verb, no behavioral context is offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence with no fluff, but it is under-specified. It lacks critical information, making it minimal to the point of inadequacy. It does not front-load any useful behavioral or usage details beyond the basic action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is severely incomplete. It does not explain return values, error handling, required permissions, or typical use cases. The agent has almost no context to understand the tool's behavior or expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the four parameters (name, category, language, components). While some parameter names are self-explanatory, the 'components' field is vague and would benefit from elaboration. The description adds no meaning beyond the raw 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 'Create message template' clearly states the action (create) and the resource (message template). It distinguishes from sibling tools like list_templates, remove_template, and send_template, which share the 'template' resource but have different actions. However, it is somewhat generic and lacks scope, so it does not 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 Guidelines1/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 is no mention of prerequisites, exclusions, or explicit comparisons to sibling tools like send_template or list_templates. The agent is given no contextual cues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Publish Flow' gives no information about side effects, permissions needed, reversibility, or what happens to the flow after publishing. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified. It reads as a fragment rather than a complete sentence and does not add value beyond the tool name. It is not concise in a meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, no output schema, no annotations, and no explanation of behavior or return values, the description is completely inadequate for an agent to understand the tool's context. It leaves the agent with no clues about execution requirements or outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention flowId or wabaAccountId at all. The agent has no semantic guidance beyond the bare parameter names, which is insufficient.
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 'Publish Flow' clearly states the action (publish) and the resource (flow), which is specific enough to distinguish from sibling tools like create_flows or deprecate_flow. However, it lacks any detail about scope or context, so it doesn't fully clarify what publishing entails.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where it should be preferred over other flow-related tools such as create_flows or patch_flows_flow_id_metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, required permissions, idempotency, or return values. For a mutation operation, this is a significant gap; the description carries the full burden but fails to address it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at three words, but this is under-specification rather than effective conciseness. It lacks structure and important content, making it minimally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only a vague one-sentence description, the tool is critically under-specified. Given it is a mutation operation, the description should cover what changes, any prerequisites, and expected effects, but none are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (groupId) with no description, and schema description coverage is 0%. The description does not mention or elaborate on parameters at all, so it adds no meaning beyond the schema's parameter name, which is insufficient.
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 'Update Group Info' clearly states a specific verb (Update) and resource (Group Info), and it distinguishes itself from sibling tools like get_groups_group_id and delete_groups_group_id. However, the tool name 'create_groups_group_id' conflicts with the described update semantics, which could confuse an agent despite the description itself being clear.
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 such as create_groups, get_groups_group_id, or delete_groups_group_id. The description merely states what it does without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but 'Upload media' provides no details about side effects, permissions, media format limitations, or response behavior. It is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, but this is under-specification rather than conciseness. It lacks sufficient content to be useful and does not structure any information beyond the basic action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested payload parameter, no output schema, no annotations, and many related sibling tools. The description is severely inadequate for an agent to understand the tool's behavior, data requirements, or when to apply it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a 'payload' object with no defined properties and zero description coverage. The description does not mention the payload at all, leaving the agent completely uninformed about what data to provide.
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 (upload) and resource (media), which is a specific verb+resource combination. However, it does not differentiate from sibling tools like send_file or retrieve_media, which also deal with media.
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 such as send_file or retrieve_media. The description lacks any context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but 'Send a Contact' simply restates the tool name. It discloses nothing about side effects, required authentication, message delivery behavior, or response expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single phrase that only echoes the tool name does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema, lack of output schema, and the large set of sibling tools, the description is severely incomplete. An agent would have no way to correctly invoke this tool or understand expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds zero meaning to the parameters. The schema is rich (phone, contacts with nested fields), but schema_description_coverage is 0%, and the description does not clarify the role of the parameters or their relationships.
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 the resource 'Contact', which distinguishes it from sibling tools like send_file or send_message. However, it lacks any detail about the type of contact or context, making it only somewhat informative.
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?
There is no guidance on when to use this tool versus the many send_* alternatives. No exclusions, alternatives, or contextual hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 merely states 'Send' without indicating side effects, permissions, delivery guarantees, or error behavior. No behavioral traits are exposed beyond the obvious mutation implied by 'send'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise in length but under-specified. It fails to include any explanatory detail beyond the tool name, making it more of a minimal label than a well-structured description. It does not earn its place because it omits critical context needed for correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, no output schema, no annotations), the description is grossly incomplete. It does not explain what makes the message 'interactive', how to specify the recipient (phone vs chatId), or the function of header/footer/displayText. The description is far below the minimum viable documentation for such a parameter-rich tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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, but it does not. The 8 parameters (url, body, displayText, phone, chatId, footer, header, quotedMsgId) are completely unexplained. The phrase 'CTA URL' hints at the url parameter, but it does nothing to clarify required fields, formats, or relationships between parameters.
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 'Send CTA URL interactive message' clearly identifies the action (send) and the resource (a call-to-action URL interactive message). It distinguishes from sibling tools like send_button or send_message by specifying the CTA URL focus. However, it does not explicitly mention the recipient or the interactive nature beyond the name, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, such as requiring an active chat, or when to choose this over send_button or send_template. The absence of any usage context makes it hard for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it only states the action and resource, with no mention of side effects, authentication requirements, message delivery behavior, response format, or failure modes. This is a significant gap for a tool that sends interactive flow messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is compact, but it is under-specified rather than appropriately concise. It provides no useful structure or detail, similar to the 'Process' example in the calibration, where brevity without substance warrants a low score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 params, nested objects, no output schema, no annotations), the one-sentence description is severely incomplete. It fails to explain what a Flow Message is, how the parameters interact, when this tool is appropriate, or what the expected outcome is, making it nearly useless for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 15 parameters with zero description coverage, and the tool description adds no parameter meaning whatsoever. The description does not explain any parameter's purpose or relationship, so the agent must rely solely on parameter names and enums, which are insufficient for complex settings like flowActionData and flowActionPayload.
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 'Send WhatsApp Flow Message' uses a specific verb ('Send') and a distinct resource type ('WhatsApp Flow Message'), which differentiates it from sibling tools like send_message, send_button, and send_list. It is clear but terse, lacking any elaboration on what constitutes a Flow Message.
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 does not mention use cases, prerequisites, exclusions, or sibling tool comparisons, leaving the agent without context for choosing send_flow over other send_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides none. It does not mention any side effects, required permissions, rate limits, or whether an active chat is needed. 'Send a Location' is entirely opaque about runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words, which is concise but under-specified. It lacks necessary context, so the brevity does not aid understanding; it is an under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with seven parameters, two required, no annotations, and no output schema, a three-word description is severely inadequate. It does not explain the tool's purpose in context, how to invoke it, or what the return behavior is, making it essentially unusable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention or explain any of the seven parameters. The parameter names like 'lat', 'lng', 'chatId' exist in the schema, but the description adds no meaning beyond them, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a Location' uses a specific verb and resource, clearly indicating a message-sending action. However, it does not distinguish itself from the sibling tool 'send_location_request', which could cause confusion about whether it sends or requests a location.
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?
There is no guidance on when to use this tool versus alternatives. It does not state prerequisites, target platform, or exclusions, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it does not. It implies a write operation ('send') but offers no details about side effects, requirements, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It conveys minimal information without earning its conciseness, as critical details are missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested objects, no output schema, no annotations), this description is severely inadequate. It lacks any behavioral, parameter, or usage context needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the five parameters (phone, region, body, action, interactive). The agent gets no help beyond the schema's field names and 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 verb 'send' and resource 'payment request', which identifies the tool's function. It is distinguishable from sibling tools by name and purpose, though 'regional' is vague about scope.
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_button. The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Update' implies mutation, but there is no disclosure of side effects, destructive potential, permission requirements, or any other behavioral context. The description is entirely opaque about what happens when calling it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. 'Update calling settings' repeats essentially the tool name and offers no additional context, making it analogous to a tautology in substance. It does not earn its place with useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with a nested free-form payload and no annotations or output schema. The description provides none of the necessary context about what settings, constraints, or resulting behavior to expect. It is completely inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'payload', a free-form object with propertyNames and additionalProperties but no semantic description. Schema coverage is 0%, and the description adds no meaning to the payload structure. With a low-coverage schema, the description should compensate but does not.
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 'Update calling settings' clearly states the verb (update) and resource (calling settings), which distinguishes it from the sibling tool get_calling_settings. However, it lacks any scope detail about which calling settings can be updated, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 is no mention of prerequisites, when not to use it, or any comparison to get_calling_settings. This is a clear case of no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Delete Group' reveals no details about the deletion process, permanence, or consequences, leaving the agent with no information beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this reflects under-specification rather than effective conciseness. It conveys the core action but omits essential context, comparable to the 'Process' example in the calibration.
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 destructive delete operation with no annotations or output schema, the description is insufficiently complete. It does not explain return values, error conditions, or what happens to the group's contents, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (groupId) with zero description coverage, and the tool description does not mention or explain the parameter at all. Even the tool name hints at 'group_id', but the description itself adds no semantic value.
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 'Delete Group' clearly states the action (delete) and resource (group), matching the tool's function. However, it does not differentiate from sibling tools like create_groups_group_id or get_groups_group_id, though the tool name itself disambiguates.
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, nor any prerequisites or side effects. It only states the basic action without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is responsible for disclosing behavioral traits. It merely says 'List Flows' and does not mention pagination, required permissions, filtering, or any side effects. The agent is left uninformed about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and contains no filler words, which is a positive. However, it is so brief that it borders on under-specification, providing only a minimal label rather than a helpful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, no annotations, and a large set of sibling tools, the description is wildly incomplete. It fails to explain return values, scope, or any contextual details needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes a single optional parameter 'wabaAccountId' with no description, and the tool description does not mention it. With schema description coverage at 0%, the parameter's purpose and format are entirely unexplained, and the description does nothing 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 'List Flows' clearly states the action (list) and the resource (flows), which is specific enough to understand the tool's basic purpose. However, it does not explicitly differentiate from sibling tools like get_flows_flow_id, though the distinction is implied by the naming convention.
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, nor does it mention prerequisites or appropriate contexts. It is a single phrase with no additional usage information, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Update Flow Metadata' gives no indication of permissions required, partial vs full update behavior, reversibility, or response format. It's essentially a tautology of the tool name, providing zero additional 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an extremely short single sentence, which is concise and front-loaded. However, it lacks substance and structure; it is barely more than the tool name. While there is no waste, it is under-specified, making it only minimally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and minimal schema information, the description offers almost no context. It doesn't explain the effect of the update, supported fields, or how it relates to sibling tools like patch_flows_flow_id_assets. The agent has insufficient information to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines flowId (required) and wabaAccountId (optional), but the description ignores parameters entirely. Schema description coverage is 0%, and the description does not compensate by explaining what wabaAccountId represents or how it affects the update, leaving the agent to guess.
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 'Update Flow Metadata' clearly identifies the action (update) and the target (flow metadata), distinguishing it from sibling tools like get_flows_flow_id, create_flows, and delete_flows_flow_id. However, it doesn't elaborate on what specific metadata can be updated, so it's clear but slightly under-specified.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like patch_flows_flow_id_assets, nor does it state prerequisites or conditions. This leaves the agent without direction on when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action without any details on side effects, permissions, idempotency, URL validation, or what happens to the existing webhook. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than appropriately concise. It omits essential context that would justify its brevity, making it feel incomplete rather than well-structured.
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 simple schema and no annotations, the description should still clarify the webhook URL's purpose, required setup, and potential implications. It does none of this, leaving the agent without enough context to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'webhookUrl' with zero description coverage. The description merely echoes the parameter name, adding no semantic value about expected format, constraints, or examples. The description does not compensate for the schema's lack of detail.
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 'Set webhook URL' clearly states the action (set) and the resource (webhook URL), distinguishing it from the sibling 'get_webhook'. It is specific enough to understand the tool's core function, though it lacks additional context about the webhook's role.
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, such as 'get_webhook' for retrieving the current webhook or other configuration tools. There are no prerequisites, examples, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Set' indicates mutation but does not disclose side effects, whether settings are overwritten, permission requirements, or any behavior beyond the action itself. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), which is under-specification rather than concise. It front-loads the main verb and resource but fails to provide any substantive content, so it does not earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is severely incomplete. It does not explain what commerce settings are affected, what values are expected, or what the outcome of the operation is. The tool has nested object parameters, yet nothing is elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description provides no parameter information. The only parameters (is_cart_enabled, is_catalog_visible) are left entirely to the schema's type definitions, with no explanation of their meaning or effect. The description adds zero value beyond 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 'Set Commerce Settings' clearly states the tool's action (set) and resource (Commerce Settings), distinguishing it from the sibling read tool get_commerce. However, it does not mention any specific settings fields, which slightly reduces clarity.
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. There is no mention of prerequisites, typical use cases, or conditions under which commerce settings should be modified. The verb 'Set' implies usage but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Send Reply Buttons Message' without disclosing side effects, permissions, or response behavior. It doesn't even clarify whether this is a write operation or what happens after sending.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is efficient, but it sacrifices necessary information. It is closer to under-specification than appropriate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an uninformative description, the tool context is severely incomplete. Four parameters are left unexplained, and the tool's behavior and edge cases are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation of body, phone, footer, or sections. The schema property names hint at meaning, but the description adds no value, forcing agents to guess.
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 states a specific action ('Send') and resource ('Reply Buttons Message'), which distinguishes it from sibling tools like send_message or send_list. However, it lacks scope or elaboration, making it clear but not outstanding.
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_list or send_carousel. The description only names the action; there are no context cues, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, and the description only says the tool sends order details. It does not disclose side effects such as delivering a message to an end user, requiring approved templates, cost implications, or error/response behavior, so the agent has minimal behavioral context beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is under-specified rather than appropriately concise. With 10 parameters and nested objects, more detail is necessary to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count, nested objects, no output schema, and no annotations, the description is severely incomplete. It fails to explain return values, required vs optional parameters, or how it integrates with other send_* tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 10 parameters with 0% description coverage, and the description mentions none of them. The agent must guess the meaning of required fields like template, namespace, language, and order, as well as optional fields such as paymentSettings and referenceId.
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 sends order details, naming a specific action and resource, with a parenthetical 'India payments template' that adds context. However, it does not explicitly distinguish this from sibling send tools like send_template or send_message, so it is clear but not fully distinctive.
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. The parenthetical hints at an India-specific payments template, but there is no explicit mention of prerequisites, exclusions, or preferred scenarios, leaving the agent to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Send Template Message,' which implies a side effect but does not disclose permissions, idempotency, rate limits, or error behavior. This is insufficient for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), but this is under-specification rather than concise efficiency. It omits all substantive content and does not earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, a nested language object, no annotations, and no output schema, a one-line description is grossly inadequate. The agent cannot infer how to correctly invoke the tool, making the description contextually incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters (phone, template, namespace, params, language, etc.) with 0% description coverage. The tool description provides no information about what these parameters mean, how they interrelate, or required formats, leaving the agent fully in the dark.
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 'Send Template Message' states the primary action (send) and object (template message) clearly. However, it does not explain what distinguishes a template message from other message types (e.g., send_message, send_button), so it lacks sibling differentiation.
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 the many other send_* siblings, nor any prerequisites (e.g., approved template, user opt-in). There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states the action without mentioning side effects, required permissions, rate limits, or the role of the 'typingIndicator' parameter. The behavior is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient but lacks necessary detail for a 3-parameter tool. It is not verbose, but it is under-specified for effective use.
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?
With no annotations or output schema, the description provides minimal context. It does not explain return values, edge cases, or how this tool fits into a messaging workflow. An agent would struggle to invoke it correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (msgId, messageId, typingIndicator). The duplication of msgId and messageId is confusing, and there is no clarity on their meaning or the expected value of typingIndicator.
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 'Mark message as read' clearly states the action with a specific verb and resource. It is distinct from sibling tools like send_message or list_messages, though it does not explicitly mention which message or provide scope, 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, prerequisites, or alternatives. It does not clarify whether this is for a received message, a sent message, or how it relates to other messaging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only mentions 'update profile info' but doesn't clarify whether it's a partial update, whether fields are validated, if authentication is required, or any side effects. The agent is left uninformed about how the tool behaves beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and arguably concise, but it is under-specified rather than efficiently complete. It lacks structure, such as bullet points or examples, and provides little beyond what the tool name already implies. It is not verbose, but it also doesn't earn its place by adding meaningful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no schema descriptions, no annotations, and no output schema, the description is severely inadequate. It doesn't explain return values, handling of omitted fields, or any constraints. The tool appears complex, but the description provides almost no contextual information, making it impractical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description adds no meaning to the 7 parameters. Fields like 'vertical' and 'websites' are ambiguous, and the description does nothing to clarify their purpose or format. This is a critical gap for an agent to correctly populate parameters.
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 'Update profile info' uses a clear verb and resource, indicating it modifies user profile data. It is distinct from sibling tools like get_me (retrieval) and update_calling_settings (specific settings). However, it doesn't specify which profile fields or distinguish from potential other update tools, so slightly more specificity would improve it.
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, no prerequisites, and no exclusions. It simply states the action without context, leaving the agent without direction on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states 'Get Flow Details,' which merely confirms a read operation without revealing response format, authentication requirements, or potential failure modes. No additional behavioral context is offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is under-specified rather than efficiently concise. 'Get Flow Details' adds little value beyond the tool name and does not earn the small space it occupies with meaningful content.
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 tool's moderate complexity (two parameters, no output schema, no annotations), a complete description should explain what 'details' are included and any constraints. This description provides none, making it inadequate for an agent to fully understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter. Although the parameter names 'flowId' and 'wabaAccountId' are self-explanatory, the description fails to clarify their purpose or how they relate, leaving the agent to infer semantics from the schema alone.
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 'Get Flow Details' clearly identifies the action (get) and the resource (flow details). It distinguishes from sibling tools like list_flows (listing) and delete_flows_flow_id (deleting). However, it lacks specificity about which details are returned, so it does not fully stand out from get_flows_flow_id_preview.
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 gives no guidance on when to use this tool versus alternatives such as list_flows or get_flows_flow_id_preview. There is no mention of prerequisites, typical use cases, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it only states 'Get Invite Link' without describing any behavioral traits, such as whether it is a read-only operation, what the response format is, or any rate limits. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but the terseness results in under-specification. It lacks essential details about the operation, making it less useful than a slightly longer description would be.
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 simple tool with one parameter, the description is incomplete: it does not describe the return value, any side effects, or when to use it relative to sibling tools. The absence of an output schema increases the need for description detail, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, groupId, with zero description coverage. The tool description does not explain the meaning or format of groupId, leaving the agent to infer from the parameter name and tool name.
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 uses a clear verb ('Get') and resource ('Invite Link'), indicating the tool retrieves an invite link. Although it doesn't explicitly mention the group context, the tool name and parameter (groupId) clarify the target. It is distinguished from the sibling create_groups_group_id_invitelink by the verb 'get' vs 'create'.
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 such as create_groups_group_id_invitelink or get_groups_group_id. There is no mention of prerequisites or whether the invite link already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Delete media' which implies destruction, but does not mention whether deletion is permanent, requires special permissions, or has other 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 a single concise sentence with no fluff. It is front-loaded with the action, but it provides no additional structural information such as parameter details or examples.
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?
The tool is a deletion operation with no annotations and no output schema, yet the description only covers the basic action. It lacks important context such as permanence, return value, and any side effects, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'mediaId' parameter at all. The agent is left to infer the parameter's meaning solely from its name, which is insufficient.
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 a specific verb and resource: 'Delete media from WABA storage'. It is unambiguous in its action, but it does not explicitly differentiate from the sibling tool 'delete_media_legacy'.
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 'delete_media_legacy' or 'retrieve_media'. The description does not mention any conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 ('Initiate WhatsApp call') but does not disclose behavioral traits such as required permissions, call state handling, failure modes, or side effects. This is slightly more informative than a tautology but still lacks meaningful transparency.
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 highly concise, consisting of a single front-loaded sentence that immediately states the purpose. It is efficient and easy to parse. However, it may be too brief, omitting necessary context, but for what it includes, it is well-structured and free of waste.
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?
The tool has one nested parameter with no schema descriptions, no output schema, and no annotations. The description is only a fragment that fails to explain the payload's required structure, call destination format, or potential outcomes. This is clearly inadequate for safe and correct invocation, given the complexity of placing a call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'payload' parameter (0% schema description coverage), and the tool description does not mention the parameter at all. The meaning of the parameter must be inferred entirely from the JSON schema, which only indicates it is an object with additional properties allowed, leaving the required structure and semantics completely undocumented.
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 uses the specific verb 'Initiate' and the resource 'WhatsApp call', clearly identifying the tool's function. This distinguishes it from sibling tools like get_calling_settings and update_calling_settings, which are about settings rather than initiating a call. However, it does not explicitly mention alternatives, 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 compared to alternatives, no prerequisites, and no context for invoking a call. It is a single sentence with no usage direction, leaving the agent to infer when this tool should be selected over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description is the only source of behavioral context. It merely says 'Get messages list' without disclosing whether this is a read-only operation, whether pagination or filtering exists, or what the returned data structure looks like. No annotations contradict it, but the lack of detail earns a low score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It says only 'Get messages list' and omits crucial context, making it nearly as unhelpful as a tautological tool description. A concise description should still deliver essential information in a front-loaded manner.
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 an empty input schema, the description must carry the full context. It fails to explain what messages are being listed, whether there are filters, or what the response will contain. The sibling tools (e.g., list_groups, list_templates) suggest a set of list operations, but this tool lacks the specificity needed for an agent to reliably select and invoke it.
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 input schema is empty, so there are no parameters to describe. With 0 parameters, the baseline is 4, and the description does not mislead or add unnecessary parameter details. However, it also fails to clarify what messages are being listed, but that is more a purpose issue than a parameter issue.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('messages'), but 'messages list' is vague and could refer to message templates, conversation messages, or something else. It does not provide enough detail to fully distinguish it from other list-type tools like list_templates or list_groups, though it is the only message-list tool among siblings.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context in which this list operation would be appropriate. An agent is left to infer based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Remove message template,' which implies deletion but does not mention permanence, permissions, side effects, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is under-specified rather than effectively concise. It lacks structural elements such as output expectations or input requirements, making it more of a title than a useful description.
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 lack of annotations, output schema, and parameter documentation, the description is far from complete. It does not clarify how to identify a template or what happens after removal, leaving critical information missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'payload' property with no description or structure, and the tool description does not explain what the payload should contain (e.g., a template ID). This is a critical gap for correct invocation.
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 'Remove message template' clearly identifies the action (remove) and the resource (message template). It distinguishes from sibling tools like add_template, list_templates, and send_template, which perform different operations.
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?
There is no guidance on when to use this tool, what prerequisites exist (e.g., template must exist), or how it differs from other template-related operations. The description simply restates the tool's name without any direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the obvious 'set' operation. It lacks context about side effects, authentication requirements, key format implications, or whether this is a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It is concise, though it may be too terse for full clarity; still, it does not waste words.
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 absence of annotations, no output schema, and zero parameter descriptions, the description is not sufficiently complete. For a one-parameter setter, it provides no explanation of the key's role or expected input, leaving critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'business_public_key' with zero description coverage. The description does not explain the expected format, length, or any validation of the key, leaving the parameter semantics entirely to the schema which also lacks detail.
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 uses a specific verb 'Set' and a clear resource 'business encryption public key', which directly states the tool's action. It distinguishes from the sibling tool 'get_whatsapp_business_encryption' by implying it is the write counterpart.
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, nor any context for prerequisites or scenarios. It does not mention the get counterpart or any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Reset Invite Link' implies a mutating action but does not disclose consequences such as invalidation of the previous link, permission requirements, or whether the operation is reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase that is easy to parse. It does not waste words, though it borders on under-specification. The structure is acceptable, but it could be slightly more informative without losing conciseness.
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?
The tool is relatively simple with one parameter and no output schema, but the description is minimal. It omits critical context such as what the reset does to existing invite links, whether a new link is returned, and any side effects. This is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameter descriptions is 0%, and the description does not mention groupId at all. The parameter name 'groupId' is self-explanatory to some extent, but the description adds no context about what values are valid or how the parameter relates to the reset operation.
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 'Reset Invite Link' clearly states a specific action (reset) and target resource (invite link), which distinguishes it from the sibling tool 'get_groups_group_id_invitelink'. It is concise and unambiguous, though it does not explicitly mention that the link is for the group specified by groupId.
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 get_groups_group_id_invitelink or other group-related tools. It does not state prerequisites, conditions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'unblock' without explaining side effects, permissions, idempotency, or what happens if the user is already unblocked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (single sentence), but it is under-specified. While there is no waste, the extreme brevity leaves out critical usage details, making it only minimally acceptable.
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 one parameter, no annotations, and no output schema, the description is incomplete. It lacks information on phone number format, prerequisites, and expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'phone' as a required number with 0% description coverage, and the tool description does not clarify the expected format (e.g., country code, leading plus) or what the value represents beyond the parameter name.
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 (unblock) and the resource (WhatsApp user), immediately distinguishing it from sibling tools like block_user and list_blocked_users.
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, nor are any prerequisites or conditions mentioned. The description is purely a directive without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It omits consequences (e.g., blocked user can't message), reversibility, idempotency, or permission requirements, making it insufficient for a mutating operation.
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, front-loaded sentence with no filler words. It communicates the core action efficiently, fitting the tool's simplicity without unnecessary verbosity.
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 simple nature (1 param, no annotations, no output schema), the description is minimally viable but lacks crucial context. It doesn't differentiate from sibling tools, explain when to use it, or disclose behavioral implications, leaving the agent under-informed for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds no information about the 'phone' parameter beyond implying it identifies the WhatsApp user, leaving format and validation details entirely to the schema's type definition.
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 'Block WhatsApp user' clearly states the action (block) and the resource (WhatsApp user). It distinguishes well from siblings like unblock_user and list_blocked_users, though it could be more explicit about using phone numbers.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives such as unblock_user or list_blocked_users, nor any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the action; it does not disclose authentication requirements, error behavior, or what 'metadata' includes. The verb 'retrieve' implies read-only, but no other behavioral traits are shared.
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, front-loaded sentence without any filler or redundancy. It efficiently conveys the core purpose, making it appropriately sized for a simple retrieval tool.
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?
With no annotations and no output schema, the description should explain at least the return value's nature or the scope of 'metadata,' but it does not. The tool is simple, but the description lacks sufficient detail to fully prepare an agent for invocation or result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% and the description does not mention the mediaId parameter at all. While the parameter name is somewhat self-explanatory, the description fails to add meaning beyond the schema's type definition, leaving the agent without guidance on how to obtain or format the ID.
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 uses a specific verb ('Retrieve') and resource ('uploaded media metadata'), clearly indicating a read operation. It is distinct from sibling tools like delete_media and send_file, which have different purposes.
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 given on when to use this tool versus alternatives, such as send_file for sending media or create_upload_media for uploading. The description simply states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only says 'delete', which is inherently destructive, but does not mention irreversibility, permission requirements, effects on associated data, or any caveats beyond the deprecation note. The deprecation is a lifecycle detail, not an operational behavior.
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 concise sentence that immediately conveys the action and the deprecated status. There is no filler or redundant information, making it appropriately sized and front-loaded.
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 delete operation with no annotations or output schema, this description is too sparse. It lacks usage guidance, parameter semantics, and any operational caveats. The deprecation note hints at an alternative but does not provide one, leaving the agent without enough context to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 for the single parameter 'mediaId'. However, the description does not mention 'mediaId', its format, how to obtain it, or any constraints. The schema only provides a type and required flag, leaving the parameter completely unexplained.
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 verb 'Delete' and the resource 'media from WABA storage', making the tool's purpose unambiguous. It also notes 'deprecated alias', which distinguishes it from a likely non-deprecated counterpart.
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 word 'deprecated' implies this tool should not be used in favor of a newer alternative, but it does not explicitly name the alternative or provide clear when-to-use vs. when-not-to-use guidance. Sibling tools like 'delete_media' exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get Commerce Settings' and adds no information about authentication, return format, or side effects. While it implies a read operation, it fails to explicitly state safety or any constraints.
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 a single, concise sentence. However, it essentially restates the tool name and adds no additional value, so it is slightly under-specified rather than maximally 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?
The tool is simple (no parameters, no output schema, no annotations), but the description provides minimal context. It does not describe what the returned 'Commerce Settings' include or any behavioral nuances. Enough for a basic getter, but the lack of output schema makes some return-value explanation 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?
The tool has zero parameters, and the schema coverage is trivially 100%. Per the baseline, a tool with no parameters receives a 4. The description correctly implies there is nothing to configure.
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 ('Get') and resource ('Commerce Settings'), making the tool's purpose evident. It distinguishes from sibling 'create_commerce' by specifying retrieval, but it does not elaborate on what the settings contain or how they differ from other getters like get_calling_settings.
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. It does not mention any context, prerequisites, or exclusions, leaving the agent to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It only states a simple action without mentioning authentication requirements, data scope, whether it's read-only, or any side effects. While 'get' implies a read, the description adds no further transparency about return format or limitations.
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 extremely concise—three words—with no redundant information. It front-loads the essential purpose. While it's compact, it's appropriately sized for a simple, parameterless tool, though it could have been slightly more descriptive without harming 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 the tool's low complexity (0 params, no output schema, no annotations), the minimal description is arguably sufficient to understand its basic function. However, because there's no output schema, the description alone doesn't clarify what 'profile info' includes or whether it's limited to the current user. This gap leaves some ambiguity about the expected response.
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?
This tool has zero parameters, so the input schema is empty. The description has nothing to explain regarding parameter syntax or semantics. Per the rubric, 0 parameters warrant a baseline score of 4, as the description doesn't need to compensate for missing parameter information.
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 'Get Profile Info' clearly identifies the operation (get) and the resource (profile info). The tool name 'get_me' reinforces that it retrieves the current user's profile, distinguishing it from sibling getters like get_status or get_webhook. However, it doesn't specify fields or scope beyond 'profile info', so it's clear but not highly detailed.
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, intended use cases, or when not to use it. For a tool with many sibling getters, this lack of context leaves the agent to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but it does not explain what the status contains, response format, or any side effects. This is a minimal disclosure that falls short.
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 extremely concise at only two words, with no wasted content. It is front-loaded and easy to parse, earning a perfect score for conciseness.
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?
Despite having no parameters or output schema, the description does not explain what 'channel status' entails or how the result should be interpreted. This leaves the agent without sufficient context, especially given the large number of sibling tools.
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 tool has zero parameters, so the schema provides full coverage. The description has no parameter details to add, and a baseline of 4 is appropriate for this case.
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 (get) and resource (channel status), making the core purpose understandable. However, it does not differentiate from sibling tools like get_mm_lite_status or get_me, so it lacks the specificity needed for 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?
No guidance is provided on when to use this tool versus alternatives. The description is simply a phrase with no context about use cases, prerequisites, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states only that it retrieves a key, but omits any details about authentication requirements, rate limits, or the nature/format of the returned key. This is minimal disclosure even for a read operation.
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, focused sentence with no redundant information. It is appropriately sized for a zero-parameter getter and front-loads the essential action.
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 very simple tool with no parameters and no output schema, the description is minimally adequate but lacks context. It does not mention how the public key is used, its relationship to the sibling setter, or any expected response format, leaving some ambiguity for an agent.
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 tool has zero parameters, so the baseline is 4. The description need not explain parameter behavior, and no additional information is required in this dimension.
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 'Get' and the resource 'business encryption public key', which is specific and unambiguous. While it doesn't explicitly differentiate from the sibling tool 'set_whatsapp_business_encryption', the name and description make the getter nature obvious.
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. There is no mention of prerequisites, scenarios, or why one would retrieve the public key. The existence of a sibling setter tool is not referenced, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, pagination, or authentication requirements. It only restates the action without elaboration.
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 concise phrase, 'Get templates list', with every word contributing to the meaning. It is appropriately sized for a zero-parameter tool.
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?
The tool is simple with no parameters and no output schema, but the description remains minimal. It does not clarify what 'templates' refers to or what the returned list contains, leaving the agent with limited context. It is adequate but not thorough.
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 input schema has zero parameters, so the description is not required to explain any. The baseline for zero-param tools is 4, and the description does not 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 uses the verb 'Get' with the object 'templates list', clearly indicating a list retrieval operation. It distinguishes from sibling tools by resource (templates vs flows/groups/messages), but lacks additional scope detail that would elevate it to 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 over alternatives like add_template or send_template. It simply states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies a read-only operation, but it does not explicitly state side-effect safety, response format, or potential errors (e.g., what happens if MM Lite is unavailable). This is acceptable for a simple getter but leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It directly states the action and target, making it highly concise and easy to scan.
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 simplicity (0 parameters) and no output schema, the description gives the core purpose but lacks detail about the return value shape or possible status values. It also does not clarify what MM Lite is, which may be confusing without prior 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?
The input schema is empty (0 parameters), and schema coverage is 100% trivially. The baseline for 0 parameters is 4, and the description need not add parameter details since none exist.
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 uses a specific verb-plus-resource structure ('Get MM Lite availability and status'), clearly indicating a read operation for a specific feature. It distinguishes itself from sibling tools like 'get_status' by narrowing scope to MM Lite, though it does not explain what MM Lite is.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any preconditions, use cases, or exclusions, leaving the agent to infer appropriate contexts 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action but does not disclose return format, pagination, authentication requirements, or whether it lists all blocked users globally or just for the current account.
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 concise sentence with no redundant words. It front-loads the action and resource efficiently, making it extremely easy to parse.
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?
The description is too minimal for a tool with no output schema and no annotations. It fails to explain what the response contains or how it integrates with related tools like block_user and unblock_user. Given the simple nature, some additional context is still expected.
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 tool has zero parameters, so the schema is trivially 100% covered. The description does not need to explain parameters, but it does clarify the resource being listed, which exceeds the schema's empty properties.
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 uses a specific verb 'List' and a clear resource 'blocked WhatsApp users'. It distinguishes from siblings like block_user and unblock_user by indicating a read operation, and the resource is specific enough to avoid confusion with other list tools.
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 does not provide any guidance on when to use this tool or how it relates to block_user/unblock_user. No mention of alternatives or prerequisites exists; usage is only implied by the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits, but it merely restates 'get webhook URL' without mentioning read-only nature, response format, authentication, or side effects. There is no contradiction, but the transparency is 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 a single short sentence, carefully front-loaded with the verb and resource. Every word earns its place, and there is zero 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?
The tool is extremely simple, but the description does not clarify the response structure (e.g., raw URL vs. JSON envelope) or the scope (e.g., which account/workspace). This leaves minor ambiguity, but for a trivial getter it is mostly adequate.
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 tool has zero parameters, which the schema confirms with an empty properties object. Since there are no parameters to document, the description does not need to compensate for missing schema details. The baseline for zero-parameter tools is 4.
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 ('Get') and the resource ('webhook URL'), making the tool's purpose immediately obvious. It also implicitly distinguishes from the sibling 'set_webhook' by indicating a read operation.
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, nor are any exclusions, prerequisites, or context supplied. The description simply names the action and resource without placement in a broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only restates the tool's purpose and does not mention read-only nature, response format, side effects, or required permissions. The 'Get' verb implies a read operation, but this is not explicitly disclosed.
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, concise sentence that immediately states the action and target. There is no redundancy or filler, and the key information is front-loaded.
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 has zero parameters and no output schema, the description is mostly adequate: it tells the user the tool retrieves settings. However, in the absence of an output schema, a bit more detail about what the settings contain or the return format 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?
The input schema has zero parameters, so the baseline of 4 applies. The description appropriately omits parameter details since there are none to describe.
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 uses the specific verb 'Get' with a concrete resource 'conversational automation settings', clearly distinguishing it from the sibling set_conversational_automation. It unambiguously identifies what the tool does.
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 the tool is used to retrieve current settings, but it does not explicitly state when to use it versus the setter sibling or other getter tools. No exclusions or alternative guidance are provided, leaving usage context merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![1msg-mcp MCP server](https://glama.ai/mcp/servers/1msg/1msg-mcp/badges/card.svg)](https://glama.ai/mcp/servers/1msg/1msg-mcp)

Score Badge

Copy to your README.md:

[![1msg-mcp MCP server](https://glama.ai/mcp/servers/1msg/1msg-mcp/badges/score.svg)](https://glama.ai/mcp/servers/1msg/1msg-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/1msg/1msg-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server