Loading ToolBench
MCP server for invoicing, WooCommerce, expenses, POS, inventory, tasks, tax declarations, and business management. 69 AI tools for Claude, ChatGPT, Cursor, and Windsurf. Freelancers, e-commerce, and startups.
Server has 5 tools with explicit Zod schemas and descriptions. Naming follows verb_noun convention (create_invoice, duplicate_invoice, send_invoice, list_invoices, get_invoice). Descriptions are present but vary in quality, create_invoice has a lengthy, instruction-heavy description (400+ chars) that reads like a prompt rather than a tool docstring; others are brief (20-50 chars). All parameters have type definitions and descriptions. However, output schemas are not documented, responses are inferred from API calls. Error handling returns structured text but lacks recovery guidance. No pagination support on list_invoices despite potentially large result sets. Tool annotations (readOnlyHint, destructiveHint) are present but set to false for all tools, which is incorrect for write operations.
[FacturaHub] Create an invoice. You can specify the client by name, email, or ID — if the client does not exist yet, it will be created automatically. IMPORTANT — E-INVOICE COMPLIANCE: After creating the invoice, if the user's country requires electronic invoicing, you MUST proactively offer to run the e-invoice workflow: • Panama (PA): "¿Quieres que envíe esta factura a la DGI vía Factura Fácil?" → validate_invoice_panama → submit_to_dgi Required by law for all commercial transactions in Panama. Always offer this. • Netherlands (NL) and US: PDF-only invoices, no e-invoice submission required. Always offer the e-invoice step for PA users — don't wait for the user to remember.
[FacturaHub] Create a copy of an existing FacturaHub invoice with a new date. Useful for recurring billing.
[FacturaHub] Get full details of an invoice
[FacturaHub] List invoices. Filter by client name, status, or date range.
[FacturaHub] Mark an invoice as sent
Tool annotations incorrect: readOnlyHint and destructiveHint set to false for all tools, including write operations (create_invoice, duplicate_invoice, send_invoice). Should be true for destructive/write tools.
Output schemas not documented. Responses are inferred from API calls (e.g., invoice.invoiceNumber, invoice.total, invoice.dueDate). LLMs cannot plan downstream calls without knowing return structure.
create_invoice description is 400+ chars and reads like a prompt instruction ('IMPORTANT, E-INVOICE COMPLIANCE...') rather than a tool docstring. Should be 50-200 chars explaining what the tool does and when to use it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
list_invoices lacks pagination parameters (limit, offset, page_size). No indication of result cap or how to handle large invoice lists. Baseline: tools returning lists should support pagination.
Error handling returns plain text without recovery guidance. E.g., 'Error creating invoice: ...' does not tell the LLM what to do next or whether the error is retryable.