WAzion MCP Server

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 qualifies the sessions as 'connected' (implying active status) and specifies they are for 'scheduled messages' (not general messaging), which adds useful context. However, it omits failure modes, rate limits, pagination behavior, or what happens when no sessions exist.

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

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

The description is efficiently structured with a header phrase and a single explanatory sentence. It is appropriately front-loaded with the key action and resource. One point is deducted for the extraneous '[query]' text, which appears to be a template artifact that serves no informational purpose.

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

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

No output schema exists to document return values, placing greater responsibility on the description. While it states that connected WhatsApp sessions are returned, it fails to describe the data structure, fields (e.g., session ID, phone number, status), or cardinality of the response. For a zero-parameter read operation, the description is minimally adequate but leaves significant gaps regarding the response format.

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

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

The input schema contains zero parameters, which establishes a baseline score of 4. The description includes a confusing '[query]' artifact at the end, but this does not constitute parameter documentation. Since there are no parameters requiring semantic clarification, the baseline applies.

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

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

The description clearly identifies the action (list/return) and the specific resource: connected WhatsApp sessions available for sending scheduled messages. It distinguishes from sibling tools like `list_scheduled_messages` by focusing on 'sessions' (connection instances) rather than the messages themselves. However, it doesn't fully clarify what constitutes a 'session' versus other WhatsApp connection concepts.

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

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

The description provides no guidance on when to use this tool versus alternatives such as `get_whatsapp_connection_status` or `connect_whatsapp`. There are no explicit prerequisites, no mention of when sessions might be unavailable, and no pointer to related workflow tools like `create_scheduled_message`.

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