Loading ToolBench
Invoice Ninja v5 MCP server for Claude, Cursor, and AI agents: all 379 API endpoints behind 3 catalog-backed tools, mutations authorized per call and backed up.
Three well-designed catalog-backed tools with clear naming (list_, describe_, call_), comprehensive parameter descriptions, and proper input schemas. Tool composition is excellent, the three-tool pattern avoids the 379-endpoint explosion and forces discovery before mutation. Descriptions are detailed and actionable (150 - 250 chars each). Parameters are well-typed with enums and constraints. However, output schemas are not explicitly documented in the source, and error handling guidance is minimal. Authorization pattern for mutations is sound but lacks recovery hints.
Call an Invoice Ninja API endpoint and return its response. Validates the endpoint name and required path parameters against the catalog before calling. Mutating endpoints (POST/PUT/DELETE) require authorization_confirmed=true and an authorization_note and are backed up before execution. Use describe_endpoint first to learn the exact parameters.
Get the full specification for a single Invoice Ninja endpoint: HTTP method, path, path/query parameters, request-body fields (types, required, enums, descriptions), and whether it mutates data. Call this before call_endpoint to know exactly what to pass.
List Invoice Ninja API endpoints (slug, method, path, category, mutating, summary). Filter by category, read-vs-mutating, or a search term. Use this to discover which endpoint to call, then describe_endpoint for its parameters and call_endpoint to execute it.
Output schemas not documented. Tool descriptions explain what is returned (response object, backup path) but do not specify the structure of the response object or fields within it. LLMs cannot plan downstream operations without knowing what fields to extract.
Error handling lacks recovery guidance. call_endpoint description mentions validation and backup but does not explain what errors are possible (invalid endpoint, missing required params, API failure) or how the LLM should respond (retry, ask user, abort). Agents need actionable error categories.
call_endpoint authorization pattern is sound but lacks confirmation UX guidance. The tool requires authorization_confirmed=true and authorization_note, but the description does not explain how the LLM should obtain explicit user approval before setting these flags. Should the LLM ask the user first, or is the note sufficient?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
list_endpoints and describe_endpoint descriptions do not explain the discovery workflow. Users may not understand that list_endpoints should be called first to find endpoint slugs, then describe_endpoint to learn parameters, then call_endpoint to execute. Add explicit sequencing hints.
call_endpoint file upload parameter (files array) lacks format specification. Description says 'local file path(s)' but does not clarify: are these absolute paths, relative to cwd, or URIs? What file types are accepted? What is the size limit? LLMs will guess and fail.