Loading ToolBench
Connect WhatsApp Business AI tools to Claude, ChatGPT, Cursor and more. Stdio-to-HTTP proxy that forwards JSON-RPC 2.0 messages to the WAzion MCP HTTP endpoint with optional self-onboarding tools for account creation.
WAzion MCP Server exposes only 2 onboarding tools with minimal parameter validation, no pagination, no structured output documentation, and weak error guidance. Both tools forward to an external HTTP endpoint and return unstructured text responses. Descriptions are present but lack depth (do not explain prerequisites, side effects, or when to use vs alternatives). Parameter descriptions are adequate but sparse. Input schemas are visible and properly typed, but lack validation constraints (enums, patterns, min/max). No output schema documentation. Error messages are user-facing text rather than machine-actionable recovery guidance. The codebase is a STDIO-only proxy with no upstream tool definitions, tool registration is hardcoded in onboarding mode, making this a minimal bootstrap harness rather than a full tool server. Per-tool scores average 38.
Verify your email with the 5-digit PIN code you received and get your API key. After activation, configure WAZION_API_KEY with the returned token to unlock all tools.
Create a new WAzion account or request a login PIN for an existing account. A 5-digit verification code will be sent to the provided email address.
No output schema documentation. Tools return unstructured text via mcpToolResult() with a single 'text' field. LLMs cannot parse returned API keys, token values, or structured success/failure states downstream.
Descriptions lack actionable detail. 'Create a new WAzion account or request a login PIN' does not explain: What happens if the email already exists? How long is the PIN valid? What language codes are supported besides the listed examples? When should the user call activate_account vs retrying create_account?
No input validation constraints in schema. 'language' parameter accepts any string but description says '(es, en, de, fr, pt_PT, hu, it)', this should be an enum, not a free-form string. 'pin' accepts any string but must be exactly 5 digits, this should be a pattern: '^\d{5}$' in the schema, not just validated in code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | 2025-03-26+ | v1 |
Error responses are user-facing text, not machine-actionable. Example: 'Error: ${data.error}', the LLM receives a raw error string from the external API with no guidance on retry eligibility, root cause, or next steps. Compare to pattern: 'Invalid email format. Try again with a valid email address, or call search_users() to find the correct contact.'
activate_account returns a raw API token in plain text within the response content. This is a security anti-pattern, tokens in tool responses enter the LLM context and can be logged, echoed to users, or stored in traces. Should return structured JSON with a 'token' field and explicitly document that this is a secret to be stored securely.
No pagination, no result limits. If WAzion's /api/mcp/ endpoint returns lists or large payloads, there is no evidence of limit/offset parameters or chunking.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are WRITE operations with side effects (send email, activate account), but carry no metadata. LLMs cannot reason about retry safety or side effects without explicit hints.
Parameters accept human-friendly input (email) but do not validate format or resolve names to IDs. 'email' parameter lacks a format constraint (should be format: 'email' in schema). Code checks with String(args.email).trim() but relies on the external API to reject invalid formats, no client-side validation.