Loading ToolBench
MCP server for integrating with e-conomic accounting/invoicing API, providing tools to manage customers, products, and invoices
The e-conomic MCP server has 17 tools with generally well-structured definitions. Most tools have descriptions and visible schemas via Zod registration. However, there are critical gaps: (1) two tools (upsert_product, update_invoice_draft) lack visible descriptions in the provided code; (2) parameter descriptions are inconsistently detailed, many lack context about expected formats, ranges, or dependencies; (3) the hello tool is trivial and doesn't belong in a production API server; (4) response schemas are not documented, clients cannot predict the structure of returned data; (5) error handling is basic, returning raw API errors without recovery guidance. The server demonstrates competent schema definition (all visible tools use Zod), but falls short of production quality due to incomplete documentation and missing context for downstream tool composition.
Book a draft invoice into a booked invoice.
Create a draft invoice in e-conomic.
Download a booked invoice PDF as base64.
Fetch a booked invoice by number.
Fetch a single customer by customer number.
Fetch a draft invoice by number.
Return a friendly greeting.
Two tools (upsert_product, update_invoice_draft) have no visible descriptions or schemas in provided source code. Cannot verify their definitions meet quality standards.
No tool documents its response/output schema. Clients cannot predict what fields are returned, their types, or structures. This breaks tool composition, agents cannot plan which downstream tools to call because they don't know what data is available.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Fetch a page of booked invoices.
Fetch a page of customer groups.
Fetch a page of customers from the e-conomic API.
Fetch a page of draft invoices.
Fetch a page of payment terms.
Fetch a page of products.
Fetch a page of VAT zones.
Update an existing customer in e-conomic.
Parameter descriptions lack actionable context. Example: 'paymentTermsNumber' is described only as an optional number, but users don't know: (1) Where to find valid payment term numbers? (2) What are typical values? (3) What happens if an invalid number is provided? Should agents call list_payment_terms() first?
Error handling is minimal. The server catches EconomicApiError and logs it server-side, but returns only sanitized error messages (message, status, errorCode) without recovery guidance. Agents don't know: (1) Is this retryable? (2) Should I call a discovery tool? (3) Is it a permission error? Pattern: error-classification not implemented.
create_invoice_draft is a high-risk write operation but lacks a dry-run or confirmation step. Agents can accidentally create invoices with wrong amounts, customers, or dates. Pattern: confirmation-request not implemented.
The 'hello' tool is trivial and adds no business value to an ERP integration. It wastes agent reasoning cycles during tool discovery. Should be removed.
Many parameters require opaque numeric IDs (customerNumber, paymentTermsNumber, customerGroupNumber, vatZoneNumber, layoutNumber, unitNumber) but lack guidance on how to obtain them. Agents must call discovery tools (list_payment_terms, list_customer_groups, list_vat_zones) to find valid IDs, but the tool descriptions don't hint at this dependency.
Pagination is implemented (pageSize, page) but response structure is not documented. Clients don't know: (1) What's the total count? (2) How to detect the last page? (3) Is there a next_cursor for cursor-based pagination? List tools should return total_count or next_cursor in their response schema.