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. It successfully adds the '[mutation]' tag indicating a write operation, mentions template variable support, and explains the draft/scheduled behavior. However, for a mass messaging tool, it fails to disclose critical behavioral aspects like rate limiting, immediate vs. deferred sending behavior when not scheduled, or side effects (e.g., credit consumption).

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 four concise segments: title/purpose ('Crear campana de marketing'), core function ('Crea una nueva...'), operational modes ('Puede crearse como...'), and capabilities ('Soporta variables...'). The '[mutation]' tag is appropriately placed. No redundant or wasted sentences.

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 the tool's complexity (15 parameters including advanced features like recurrence, segmentation, media attachments, and translation), the description is minimal. It mentions template variables and scheduling but doesn't address complex parameter interactions (e.g., recurring_cron requiring is_recurring), return values (campaign ID?), or the campaign lifecycle. For a tool with nested objects and no output schema, more contextual guidance is needed.

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, establishing a baseline of 3. The description mentions template variables ({nombre}, {telefono}, {tienda}) and draft/scheduled modes, but these are already well-documented in the schema (message_text description lists variables, scheduled_at describes scheduling). The description adds minimal semantic value beyond what the schema already provides.

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 'Crea una nueva campana de marketing masivo' (creates a new mass marketing campaign). The term 'nueva' distinguishes it from update_campaign, and 'masivo' distinguishes it from individual messaging tools like send_whatsapp_message. However, it doesn't explicitly clarify when to use this versus create_scheduled_message or other campaign creation variants.

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 partial usage guidance by explaining the two creation modes: draft ('borrador') or scheduled ('programarse para una fecha futura'). However, it lacks explicit guidance on when to use this tool versus alternatives like update_campaign or start_campaign, and doesn't clarify prerequisites (e.g., needing a contact list first).

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