Loading ToolBench
A comprehensive MCP server implementation for an autonomous AI employee system with multiple capability tiers (Silver, Gold) handling email, WhatsApp, Odoo accounting, approvals, performance monitoring, and task management
This is a multi-server suite with 17 tools spread across email, Odoo, approval workflows, WhatsApp monitoring, error handling, and performance analytics. Analysis is based on visible source code (email_mcp_server.py, odoo_mcp_server.py partially shown) and tool metadata provided. Major issues: (1) No JSON Schema input schemas visible in source code for most tools, schemas are inferred from metadata, not defined in code. (2) Descriptions are generally present but extremely brief and lack actionable LLM guidance (e.g., 'Send email via SMTP' tells what happens but not when to use it or what errors to expect). (3) Parameters lack detailed validation rules, format specifications, and dependency documentation. (4) No output schemas documented. (5) Error handling in visible code returns basic text responses without recovery guidance or error classification. (6) Multiple tools (move_approval, approve_pending_tasks, check_for_updates) have NO input parameters defined at all, their implementations are not visible. (7) Tool composition shows concerning patterns: send_email and draft_email are well-separated, but create_invoice should probably validate customer existence first, yet search_customer is a separate tool with no composition guidance. (8) No evidence of dry-run/confirmation patterns for destructive operations (send_email has a DRY_RUN env var, but no tool parameter). (9) Parameters like 'line_items' in create_invoice and 'error' in attempt_recovery are typed as 'array' and 'object' with minimal descriptions, LLMs cannot infer structure.
Collects data from all sources and calculates performance scores for CEO Briefing
Move all pending approval files to the Approved folder
Attempt to recover from error based on error classification
Scans approval folders and generates a status report
Monitor WhatsApp for business-related messages and create tasks
Check email configuration
Create a customer in Odoo
Three tools (approve_pending_tasks, move_approval, check_for_updates) have NO input schema defined, empty '{}' parameter objects. Cannot verify parameter structure or provide LLM guidance on usage.
Descriptions are uniformly very brief (12-45 characters), below the 50-char minimum for effective LLM guidance. 'Send email via SMTP' lacks context on when to use vs draft_email, error scenarios, or prerequisites. All descriptions in this suite are at or below p10.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | <=2025-11-25 | v2 |
Create an invoice in Odoo
Create email draft for approval
Get financial report data
Get all unpaid invoices
Check if Odoo connection is healthy
Move approval file from Pending_Approval to Approved folder
Record a payment for an invoice
Scan recent logs for errors
Search for a customer by email
Send email via SMTP
Complex parameters lack nested schema definitions: 'line_items' in create_invoice is typed 'array' with only description 'Invoice line items', no item schema (should specify object with fields like product_id, quantity, unit_price, description). 'error' in attempt_recovery is typed 'object' with no properties documented. LLMs cannot infer required fields.
No output schemas documented for any tool. LLMs do not know what fields to expect in responses, cannot chain tools (e.g., create_invoice returns what? invoice_id? invoice_number? Both?), and cannot plan downstream calls. Rubric baseline: 100% of A+ tools document return types.
Error handling in send_email and draft_email returns unstructured text ('✅ Email sent', '❌ Failed') without error classification, recovery guidance, or retry eligibility. Try search_users()', not just a status emoji. Visible code shows no pattern:recovery-guide implementation.
No evidence of confirmation/dry-run patterns for destructive operations. send_email has a DRY_RUN environment variable, but no tool parameter to invoke it per-call. approve_pending_tasks, move_approval, and record_payment have no confirmation step.
Tool composition broken: create_invoice requires 'customer_email' and 'customer_name', but search_customer finds by email. No composition guidance on order of operations (search first? create if not found?). Response from search_customer likely returns customer_id, does it? Not documented, so create_invoice cannot guarantee it will receive or use the right ID.
Parameters accept generic/ambiguous values: payment_method in record_payment defaults to 'manual' but no enum of valid methods provided. vault_path in check_approval_status has no validation rule (absolute vs relative? must exist?). LLMs will guess and pass invalid values; responses lack actionable error messages.
No input validation shown in source code. email_mcp_server.py checks DRY_RUN env var but does not validate email address format, SMTP connectivity, or attachment existence before sending. odoo_mcp_server.py (partial) does not show validation of line_items structure or invoice_date format. Validation failures return generic 'Failed' responses without actionable guidance (per review:actionable-errors).
No evidence of pagination support. get_financial_report, get_unpaid_invoices, and check_approval_status may return large result sets, but no limit/offset, page_size, or next_cursor parameters visible.