Loading ToolBench
MCP server that provides tools for managing invoices through the InvoiceApp API. Supports listing, finding, creating, and marking invoices as paid.
This server has critical definition quality gaps. Tool naming is inconsistent (ListInvoices vs list_invoices), parameter descriptions are sparse or missing, and output schemas are not documented. Of 12 tools, 5 lack parameter descriptions entirely (get_weather, get_clothing_from_wardrobe, email_friend, FindInvoiceByName is borderline). The server exposes tools across three separate registries (McpServer, InvoiceAgentApi, ConsoleAgent) with duplicate and contradictory definitions, e.g., ListInvoices/list_invoices do the same thing but with different naming conventions. Parameter types are visible in JSON Schema but LLM-facing descriptions are often absent or trivial. Output schemas are completely undocumented, callers don't know what fields to expect. Error handling is absent from all tool definitions.
Creates an invoice and returns the new invoice object
Finds the invoice with this name
Retrieves a list of all invoices in InvoiceApp
Marks an invoice as paid
Creates an invoice and returns the new invoice object
Sends an email to my friend with this name
Finds the invoice with this name
Duplicate tool definitions across three separate registries with inconsistent naming (PascalCase vs snake_case). ListInvoices, list_invoices, FindInvoiceByName, find_invoice_by_name, CreateInvoice, create_invoice, MarkAsPaid, mark_as_paid appear to be the same tools with conflicting names. LLMs will be confused about which to call.
Output schemas are completely undocumented. No tool documents what fields it returns, what types those fields have, or how downstream tools should consume the output. CreateInvoice returns an Invoice object but callers don't know its structure. ListInvoices returns a List<Invoice> but the schema is invisible to the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Lists all the clothing I have in my wardrobe
Get the current weather descriptions in a specified city
Retrieves a list of all invoices in the system
Marks an invoice as paid
Retrieves the contents of this page in the documentation
Parameter descriptions are missing or minimal. 'invoiceName' in FindInvoiceByName has a description, but 'city' in get_weather is undescribed (source: ConsoleAgent/FunctionRegistry.cs shows method reflection but no param docs extracted). 'friendName' and 'message' in email_friend lack descriptions.
No error handling guidance. None of the tool definitions explain what happens on failure, whether errors are retryable, or what the LLM should do next.
No tool composition or chaining support documented. E.g., CreateInvoice returns an Invoice object but does not specify whether it includes an invoice_id, invoice_name, or other fields needed by MarkAsPaid.
Semantic scope creep: email_friend, get_weather, get_clothing_from_wardrobe are unrelated to invoice management. The server mixes invoice domain (CreateInvoice, MarkAsPaid) with personal assistant tools (weather, clothing, email), violating single responsibility. This forces LLMs to reason about context switches and makes the tool set incoherent.
Parameter naming is inconsistent across duplicates. 'invoiceName' (FindInvoiceByName) vs 'invoiceName' (find_invoice_by_name), OK here. But 'createRequest' (CreateInvoice) vs 'createInvoiceRequest' (create_invoice) differ, forcing the LLM to track which signature applies to which tool.