WAzion MCP Server

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

No annotations are provided, so the description carries the full burden. While it mentions ordering by last activity, it omits critical behavioral details: pagination behavior (despite having offset/limit params), whether results are cached, rate limits, or how the tool handles the zero required parameters. The trailing '[query]' fragment suggests incomplete or corrupted descriptive text.

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 brief and front-loaded, but the trailing '[query]' token appears to be an artifact or placeholder rather than intentional content, creating confusion. The Spanish language is consistent with the schema descriptions, but the bracketed text reduces clarity without adding value.

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 13 parameters with complex filtering options (time windows, specific IDs, pagination, text search) and no output schema, the description is insufficient. It fails to explain return format, how time-based parameters interact (hours vs. date range), or what fields are returned. For a tool with this parameter richness, more behavioral context 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?

With 100% schema description coverage, the schema adequately documents all 13 parameters in Spanish. The description adds no specific parameter guidance (e.g., explaining that 'hours' and 'period' are mutually exclusive, or that 'conversation_id' makes other filters redundant), but baseline 3 is appropriate when schema coverage is comprehensive.

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 retrieves recent conversations ('Ver conversaciones recientes') and specifies they are ordered by last activity ('ordenadas por ultima actividad'). However, it does not explicitly differentiate from sibling tools like 'search_conversations' or 'get_conversations_summary', which also access conversation data.

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?

No guidance is provided on when to use this tool versus alternatives like 'search_conversations' or 'get_conversation_detail'. With 13 available parameters including overlapping time filters (hours, date_from/date_to, period), the description fails to explain optimal usage patterns or parameter combinations.

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