Loading ToolBench
Multi-tenant omnichannel messaging hub supporting WhatsApp, Discord, and other channels with per-instance configuration
Automagik Omni presents a mixed profile with some foundational issues limiting adoption. Tool definitions show moderate effort in naming and descriptions, but critical gaps in schema completeness, parameter validation, and error handling prevent production-grade quality. Of 8 tools, 5 have reasonable descriptions (10-200 chars); however, 3 tools (start_api, health_check, init_project, show_status) lack input schema documentation visible in source. Parameter descriptions vary widely, some are precise (decrypt_media), others generic (get_contacts, get_chats). Output schemas are not documented for any tool, forcing LLMs to infer result structure. No tool exhibits error recovery guidance or actionable error messaging patterns. Naming is consistent (verb_noun), but some names conflate concerns: 'get_contacts' and 'get_chats' both apply client-side filtering AFTER pagination, a significant usability bug that is documented but unresolved. Security considerations are absent, no visible input validation, rate limiting, or permission gating. The server targets WhatsApp/Discord integration and system administration; definition quality is adequate for a proof-of-concept but falls short of production readiness.
Decrypt WhatsApp media and save to a temporary file
Decrypt WhatsApp encrypted media files using the provided media key following WhatsApp's end-to-end encryption protocol
Get chats/conversations from WhatsApp in unified format with pagination. Note: When using chat_type_filter or archived filter, client-side filtering is applied AFTER pagination, which may result in fewer items per page than requested.
Get contacts from WhatsApp in unified format with pagination. Note: When using search_query or status_filter, client-side filtering is applied AFTER pagination, which may result in fewer items per page than requested.
Check the health of the Automagik Omni system including database, configuration, and telemetry status
Initialize a new Automagik Omni project by creating database tables and checking for existing instances
Output schemas undocumented for all 8 tools. LLMs cannot reliably extract or plan downstream tool calls without knowing the structure of responses.
Input schemas missing or not visible for health_check, init_project, and show_status. These tools are documented as accepting no parameters, but schema validation is absent from source code inspection.
get_contacts and get_chats explicitly document client-side filtering applied AFTER pagination, resulting in fewer items per page than requested. This is a composition anti-pattern (pattern:paginated-result), pagination and filtering should be server-side or clearly separated. Clients cannot rely on page_size.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Show overall system status including configuration, instances, and telemetry
Start the Automagik Omni API server with configurable host and port
No error handling guidance or recovery patterns visible in any tool. Descriptions lack recovery hints (e.g., 'If decryption fails, check media_key_b64 format'). No categorization of errors as retryable, user-fixable, or fatal.
No visible input validation, sanitization, or security checks. decrypt_media accepts a media_key_b64 parameter without format validation. start_api accepts host/port without validation. No protection against injection attacks or parameter tampering.
Parameter descriptions for media_type in decrypt_media and decrypt_and_save_temp are terse. No guidance on how to obtain media_type or what happens if an incorrect value is passed. Enum constraint not formally declared (should be: 1|2|3|4).
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint per MCP spec 2026-07-28). This omission prevents clients from inferring safety properties and planning retry logic.
start_api tool description lacks idempotency and side-effect clarity. Calling it twice could start multiple server instances or fail if one is already running. No guidance on recovery or confirmation pattern.
Descriptions for health_check, init_project, and show_status are generic and under 60 characters. 'Check the health...' and 'Initialize a new...' lack context for when to call them, what they return, or what failures mean.