WAzion MCP Server

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

No annotations are provided, so the description carries full behavioral disclosure burden. It excellently explains the mutation nature ('[mutation]', 'requiere confirmación'), the two-step flow with intermediate state (requires_confirmation=true with success=false is normal), and critical UI automation details (system shows Confirm/Cancel buttons automatically, do not call again).

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?

Despite being information-dense and in Spanish, every sentence earns its place: purpose declaration, 3-step workflow, confirmation constraints, sibling differentiation, and mutation tagging. The numbered list format efficiently structures the complex flow, though the density slightly impacts readability.

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?

For a complex mutation tool with confirmation logic and no output schema, the description is remarkably complete. It explains the return value behavior (requires_confirmation=true), the user interaction pattern, edge cases (ambiguous user responses), and the full lifecycle without requiring an output schema.

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?

Schema coverage is 100%, establishing a baseline of 3. The description adds crucial workflow context beyond the schema: it explains that 'confirm=true' is required to execute the dangerous action, and clarifies that 'prompt' should be the complete prompt (not modifications) in the context of the two-step flow.

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 the tool 'Guarda un nuevo prompt para la IA' (saves a new AI prompt) using a specific verb-resource combination. It explicitly distinguishes from sibling 'apply_prompt_instruction' by stating when to use that alternative instead (for modifying existing prompts vs. saving new ones).

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?

Provides an explicit 'FLUJO OBLIGATORIO' with numbered steps detailing the exact sequence (call → receive requires_confirmation → describe changes to user). It specifies when NOT to use the tool ('Si el usuario quiere MODIFICAR... usa apply_prompt_instruction primero') and strictly defines what constitutes valid confirmation (system buttons only, not 'ok' or '1').

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