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 successfully explains the business logic of 'opt-out' (automatic message blocking), but fails to disclose pagination behavior (despite having a 'page' parameter), result limits, or whether the operation is read-only. It mentions filtering but doesn't clarify if the search supports partial matches or exact phone numbers.

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

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

The description is a single, efficient sentence using an em-dash structure that front-loads the action. It is appropriately sized for the tool's complexity. One point is deducted for the unexplained '[query]' fragment at the end, which appears to be a template placeholder or error that should be removed.

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

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

Given this is a straightforward listing tool with two optional parameters and no output schema, the description provides the minimum necessary domain context (explaining what 'opt-out' means in this system). However, it omits expected return value structure (e.g., whether it returns phone numbers, dates, or customer IDs) and pagination details that would help the agent handle results correctly.

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

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

The input schema has 100% description coverage ('Pagina de resultados' and 'Filtrar por numero de telefono'), establishing a baseline of 3. The description adds no additional parameter semantics beyond what the schema provides. The stray '[query]' at the end of the description might reference the search functionality but is too ambiguous to provide value.

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

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

The description clearly states it lists WhatsApp opt-out contacts and explains the domain concept (contacts who requested not to receive automatic messages). It implicitly distinguishes from siblings like 'add_whatsapp_optout' and 'check_whatsapp_optout' by specifying the 'list' operation, though it doesn't explicitly contrast with them. The trailing '[query]' appears to be a placeholder or artifact that slightly detracts from polish.

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. It does not mention that users should use 'check_whatsapp_optout' for verifying a single contact's status, or when bulk operations might be preferred. No prerequisites or exclusion criteria are provided.

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