Skip to main content
Glama

Zovo Invoice Ledger

Generate invoice ledger

generate_invoice_ledger
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
textNoFallback only: several invoices pasted as one text; they are split at --- lines or where a new invoice number starts.
filesNoInvoice 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.
currencyNoCurrency for invoices that show none, as an ISO code, e.g. USD. A code printed on the invoice wins.
invoicesNoInvoices 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_orderNoOrder of numeric dates such as 03/04/2026: DMY (UK, EU) or MDY (US). Detected when a day is above 12.
decimal_markNoDecimal mark of the amounts: "." (1,234.56) or "," (1.234,56). Detected per invoice when omitted.
invoice_textsNoPasted 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"].

Output Schema

NameRequiredDescriptionDefault
notesYes
issuesYes
previewYes
invoicesYes
downloadsYes
currenciesYes
by_supplierYes
by_tax_rateYes
preview_countNo
skipped_filesYes
by_supplier_countNo
by_tax_rate_countNo
duplicate_numbersYes
invoices_with_issuesYes
links_expire_minutesYes
arithmetic_mismatchesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources