Loading ToolBench
MCP server for Blank Invoice Maker — create free, no-signup invoices from your AI assistant. Exposes list_templates and create_invoice tools that return a deep link opening blankinvoicemaker.com pre-filled.
Two well-defined tools with clear naming, comprehensive schemas, and good descriptions. Naming follows verb_noun convention (list_templates, create_invoice). Both tools have detailed parameter descriptions and type definitions. However, output schemas are documented only informally in descriptions rather than formally in JSON Schema. Error handling is present but basic. Security model is sound (no secrets in parameters). Composition is clean, each tool does one thing and chains naturally (list_templates discovers options, create_invoice builds on that discovery).
Create a professional invoice and return a link that opens it — fully pre-filled — in the free Blank Invoice Maker editor (https://blankinvoicemaker.com). No signup, no watermark. The user opens the link to review and download the PDF; all invoice data stays in their browser (it travels in the link's URL fragment and is never sent to a server).
List the industry-specific invoice templates available on Blank Invoice Maker (https://blankinvoicemaker.com). Returns each template's slug, name, description, and page URL. Use this to discover templates; build a custom invoice with create_invoice.
Output schemas not formally documented in JSON Schema format. Both tools describe their return values only in prose descriptions, not in structured outputSchema declarations. LLMs cannot parse prose output schemas reliably, they need typed, structured field documentation.
list_templates has minimal input schema (empty object {}). While correct for a no-parameter tool, the empty schema misses an opportunity to document the output structure formally. The description states 'Returns each template's slug, name, description, and page URL' but this is not machine-parseable.
create_invoice's 'items' parameter allows quantity and unitPrice as 'number|string'. This type union is ambiguous, LLMs may pass '1' as a string when a number is required, or vice versa. Numeric parameters should have explicit min/max bounds and clear type declarations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
Error handling is present (isError flag, over-sized link detection) but not classified. LLMs cannot infer whether to retry, ask the user, or abort. Errors lack recovery guidance, e.g. 'Try reducing line items or shortening text' is present, but not wrapped in a structured error classification.