Put a batch of supplier invoices into one spreadsheet with net, tax and gross totals.
Scored across 1 tool
With only one tool in the set there is no possibility of misselection; the agent has exactly one path and the description names the triggering intents explicitly.
The single tool uses a clear snake_case verb_noun convention (generate_invoice_ledger) that directly reflects the server's purpose, so there is nothing inconsistent to compare against.
A one-tool surface is thin and forces everything (parsing, validation, Excel/CSV export) through a single monolithic call with no composability, though the tool itself is rich and well-scoped rather than trivial.
The tool covers the full ingest-to-export lifecycle for producing an invoice ledger with validation checks and multiple output formats; gaps (no line-item reading, no OCR of scans, no currency conversion) are explicitly declared limitations rather than silent dead ends.
Use this when the user wants several invoices in one spreadsheet ("put these invoices into Excel", "invoice log from these PDFs", "purchase ledger", "VAT summary by rate", "check these invoices for duplicates"). Send the invoices as rows when their values are in the chat or a screenshot; send attached invoice PDFs (selectable text) in files; send pasted invoice text in invoice_texts (one string per invoice), and use text only as a fallback. Returns an Excel ledger (supplier, invoice number, invoice and due date, currency, net, tax per rate, tax total, gross, status) with By supplier, By tax rate and Checks sheets, and a CSV. Flags totals that do not equal net + tax, tax that does not match its rate, and duplicate invoice numbers per supplier. Reads header totals only, not line items. Does not read scanned images, convert currencies, file tax returns, or say whether tax is reclaimable.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Fallback only: several invoices pasted as one text; they are split at --- lines or where a new invoice number starts. | |
| files | No | Invoice PDFs with selectable text (not scans), up to 20, e.g. acme-inv-1001.pdf, northwind-re-77.pdf. A .txt with pasted invoice text also works. | |
| currency | No | Currency for invoices that show none, as an ISO code, e.g. USD. A code printed on the invoice wins. | |
| invoices | No | Invoices as rows, one per invoice, e.g. [{"supplier":"Acme Supplies Ltd","invoice_number":"INV-1001","invoice_date":"2026-10-01","currency":"GBP","net":1250,"tax_rate":20,"gross":1500}]. Use this when the invoice values are in the chat or a screenshot. | |
| date_order | No | Order of numeric dates such as 03/04/2026: DMY (UK, EU) or MDY (US). Detected when a day is above 12. | |
| decimal_mark | No | Decimal mark of the amounts: "." (1,234.56) or "," (1.234,56). Detected per invoice when omitted. | |
| invoice_texts | No | Pasted invoice text, one string per invoice, e.g. ["Acme Supplies Ltd\nInvoice No: INV-2044\nInvoice Date: 14/10/2026\nSubtotal £2,400.00\nVAT 20% £480.00\nTotal £2,880.00"]. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| issues | Yes | |
| preview | Yes | |
| invoices | Yes | |
| downloads | Yes | |
| currencies | Yes | |
| by_supplier | Yes | |
| by_tax_rate | Yes | |
| preview_count | No | |
| skipped_files | Yes | |
| by_supplier_count | No | |
| by_tax_rate_count | No | |
| duplicate_numbers | Yes | |
| invoices_with_issues | Yes | |
| links_expire_minutes | Yes | |
| arithmetic_mismatches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the exact output contents, the extra By supplier / By tax rate / Checks sheets plus CSV, the three validation flags raised, and the limitation that only header totals are read, not line items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Information is front-loaded in a logical order: trigger, input routing, output, checks, exclusions. It is a single dense paragraph with many parenthetical examples, which is efficient but slightly packed; a light break between usage and output would improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter extraction tool with an output schema, everything an agent needs is present: input modality rules, currency precedence, per-invoice limits implied by examples, validation behavior, and explicit out-of-scope cases. Return shape is described even though an output schema exists, which removes any ambiguity about what the user gets back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns one more by adding precedence semantics the schema cannot express — which parameter to prefer for a given input modality and that `text` is a fallback. It does not, however, explain date_order/decimal_mark auto-detection beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause names a specific verb and output ("several invoices in one spreadsheet") and immediately anchors it with real user phrasings like "put these invoices into Excel" and "purchase ledger". An agent knows exactly what artifact this produces without consulting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use the tool and then routes between the three input channels with explicit priority: rows when values are in chat or a screenshot, files for selectable-text PDFs, invoice_texts for pasted text, with text as fallback only. It also lists when-not to use it (scans, currency conversion, tax reclaimability).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_invoice_ledgerTurns invoice PDFs into one spreadsheet and checks the tax, totals and money math of each invoice.
Convert PDF bank statements into Excel and check that the balances add up. Invoices and tables too.
Invoice PDFs, scans and photos to Excel, with the math checked: fields, line items and totals.
Review invoice records, flag duplicates, validate totals, and prepare spreadsheet-safe CSV.
Add one secure layer between your agents and this server.
