InvoiceIn

Export invoice as CSV

invoice_to_csv

Read-onlyIdempotent

Export one European e-invoice as a flat CSV table for a spreadsheet or a database import. Document columns: invoice id, type, issue and due date, currency, seller and buyer name / VAT id / country, buyer and order reference, net / tax / gross / due totals, IBAN, BIC, remittance info, KSeF number, detected format and profile; with level=lines each row adds line id, item name, seller item id, quantity, unit, unit price, net amount, VAT category and rate, note. Use invoice_to_datev for DATEV bookkeeping and read_invoice for the full JSON. Input: XML (UBL, CII, XRechnung, Peppol BIS 3, UAE PINT AE, FatturaPA, KSeF FA(2)/FA(3)) or a ZUGFeRD/Factur-X hybrid PDF up to 25 MB; plain or scanned PDFs without embedded XML are rejected (no OCR). A FatturaPA lot yields rows for every invoice in it. Returns the CSV as one text string: comma-separated, header row first, LF line endings, decimal point; an unreadable file returns a tool error with the reason. Costs one invoice credit per call; without an API key the anonymous quota is 20 invoices per day per IP. Nothing is stored.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ksef`	No	Poland only: the KSeF number the National e-Invoice System gave this invoice — 35 characters, NNNNNNNNNN-RRRRMMDD-FFFFFFFFFFFF-FF — or the collective identifier covering it (NNNNNNNNNN-IZRRRRMM-FFFFFFFFFFFF-FF). KSeF assigns it on acceptance, so it is never inside the FA(2)/FA(3) XML: it arrives beside the invoice in the KSeF API response, the UPO or the QR code on a visualisation. Pass it and it is checked against the invoice and returned on payment.ksef_number, the reference a Polish buyer must quote in the bank transfer title from 2027-01-01. Leave empty for invoices from any other country.
`path`	No	Absolute path of the invoice file on the machine running the server, used instead of file_base64. Only honoured over stdio (`python -m invoicein.mcp_server`); the hosted server at invoicein-api.peculiar.systems ignores it and answers with an error asking for file_base64.
`level`	No	'lines' (default) = one row per line item with the document columns repeated on every row; 'documents' = one row per invoice with the document columns only.	lines
`file_base64`	No	Invoice file content, base64-encoded (standard alphabet). Accepted content: XML in UBL 2.1, CII D16B, XRechnung, Peppol BIS Billing 3, FatturaPA 1.2 or KSeF FA(2)/FA(3) syntax, or a ZUGFeRD 1.0/2.x or Factur-X hybrid PDF (the embedded XML is used). Max 25 MB decoded. Required unless `path` is given.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 11, 2026

addedInput schema / properties / ksef

Added value: +{
+  "default": "",
+  "description": "Poland only: the KSeF number the National e-Invoice System gave this invoice — 35 characters, NNNNNNNNNN-RRRRMMDD-FFFFFFFFFFFF-FF — or the collective identifier covering it (NNNNNNNNNN-IZRRRRMM-FFFFFFFFFFFF-FF). KSeF assigns it on acceptance, so it is never inside the FA(2)/FA(3) XML: it arrives beside the invoice in the KSeF API response, the UPO or the QR code on a visualisation. Pass it and it is checked against the invoice and returned on payment.ksef_number, the reference a Polish buyer must quote in the bank transfer title from 2027-01-01. Leave empty for invoices from any other country.",
+  "title": "Ksef",
+  "type": "string"
+}

Changed11 schema fields changedSep 8, 2026

removedInput schema / properties / file_base64 / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / file_base64 / default
```
Previous value: -nullNew value: +""
```

changedInput schema / properties / file_base64 / description

Previous value: -"The invoice file, base64-encoded: XML (UBL, CII, XRechnung, Peppol, FatturaPA, KSeF FA(3)) or a ZUGFeRD/Factur-X hybrid PDF. Up to 25 MB decoded."New value: +"Invoice file content, base64-encoded (standard alphabet). Accepted content: XML in UBL 2.1, CII D16B, XRechnung, Peppol BIS Billing 3, FatturaPA 1.2 or KSeF FA(2)/FA(3) syntax, or a ZUGFeRD 1.0/2.x or Factur-X hybrid PDF (the embedded XML is used). Max 25 MB decoded. Required unless `path` is given."

addedInput schema / properties / file_base64 / type
```
Added value: +"string"
```

changedInput schema / properties / level / description

Previous value: -"'lines' = one row per line item (document fields repeated), 'documents' = one row per invoice"New value: +"'lines' (default) = one row per line item with the document columns repeated on every row; 'documents' = one row per invoice with the document columns only."

addedInput schema / properties / level / enum

Added value: +[
+  "lines",
+  "documents"
+]

removedInput schema / properties / level / pattern
```
Removed value: -"^(lines|documents)$"
```

removedInput schema / properties / path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / path / default
```
Previous value: -nullNew value: +""
```

changedInput schema / properties / path / description

Previous value: -"Local file path instead of file_base64; only honoured when the server runs over stdio on the same machine."New value: +"Absolute path of the invoice file on the machine running the server, used instead of file_base64. Only honoured over stdio (`python -m invoicein.mcp_server`); the hosted server at invoicein-api.peculiar.systems ignores it and answers with an error asking for file_base64."

addedInput schema / properties / path / type
```
Added value: +"string"
```

First observedSep 7, 2026

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint and idempotentHint, but the description goes further: it discloses the exact return format (CSV as a string, comma-separated, header row, LF endings), error behavior for unreadable files, credit cost, anonymous quota, and the fact that nothing is stored. It also notes the path parameter is ignored on the hosted server, a behavior not implied by the schema. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence serves a purpose. It front-loads the core purpose and output format, then progressively covers inputs, behavior, costs, and alternatives. There is no redundancy; each clause adds critical operational detail that an agent needs to use the tool correctly.

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 tool with four parameters, multiple input formats, and specific output formatting and quota rules, the description covers everything an agent must know to invoke it correctly: input paths and base64, level options, accepted XML/PDF types, size limits, return format, error handling, cost, and storage guarantees. It even accounts for the path parameter's environment-dependent behavior, leaving no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains the KSeF number format and its source, clarifies that path is only honored over stdio, details the level parameter's row structure, and specifies accepted file types and size limits for file_base64. This significantly enriches the agent's understanding of each parameter.

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 description states a specific verb and resource ('Export one European e-invoice as a flat CSV table') and immediately names its sibling tools (invoice_to_datev, read_invoice) with distinct purposes, making differentiation explicit. It also details the exact output format and accepted inputs, leaving no ambiguity about what the tool does.

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 explicitly instructs when to use alternatives: 'Use invoice_to_datev for DATEV bookkeeping and read_invoice for the full JSON.' It also defines clear exclusions (plain/scanned PDFs rejected) and the file size limit, so an agent knows exactly when this tool is appropriate versus when to route elsewhere.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All InvoiceIn tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?