The Invovate MCP Server is an invoice generation tool for AI agents. It provides four main capabilities:
calculate_invoice_totals: Compute invoice math (subtotal, discounts, taxes, shipping, deposit, grand total, balance due) without generating a file. No API key required.
generate_invoice_pdf: Create a PDF invoice, returning a 7-day hosted link or saving locally via save_path. Supports 5 templates (classic, modern, bold, minimal, navy) and 11 languages. Requires a free API key.
generate_invoice_ubl: Export invoices as UBL 2.1 XML for interoperability and archival (not regulated e-invoicing — no Peppol/Factur-X/XRechnung compliance). Requires a free API key.
get_invoice_capabilities: List all supported languages, PDF templates, currencies, and features. No API key required.
Key features:
11 languages including right-to-left (Arabic) and non-Latin scripts (Japanese, Hindi, Russian/Cyrillic)
Per-line and global discounts, tax rates, shipping, deposits, and partial payments
ISO 4217 currency codes (USD, EUR, GBP, JPY, etc.)
Payment details (IBAN, SWIFT, bank info), notes, and terms
Basic calculations require no API key; PDF/UBL generation requires a free key (no credit card, starts with inv_)
Invovate MCP Server is a free, no-signup invoice MCP server for Claude, Cursor, and other MCP clients — it generates invoices as PDF, JSON, and UBL 2.1 via the Invovate invoice API.
Let AI agents generate PDF, JSON, and UBL 2.1 invoices in 11 languages (including right-to-left Arabic, Japanese, Hindi, and Cyrillic) through the Invovate invoice API. Works with Claude Desktop, Cursor, Windsurf, and any MCP-capable client.
JSON math works with no API key; PDF/UBL output uses a free key.
Tool | What it does | Key needed |
| Compute subtotal, discounts, tax, shipping, deposit, grand total, balance due — no file rendered. | No |
| Generate a PDF. Returns a 7-day hosted link (great for chat), or writes the file when | Required |
| Generate UBL 2.1 XML (interoperability/archival only — not regulated e-invoicing). | Yes |
| List supported languages, templates, currencies, and features. | No |
Related MCP server: Invoice MCP Server
Sign up at https://invovate.com/auth — your key starts with inv_. Free tier,
no credit card. (calculate_invoice_totals works without a key; PDF, UBL, QR, and hosted links require a free key.)
Add to claude_desktop_config.json
(~/Library/Application Support/Claude/claude_desktop_config.json on macOS,
%APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"invovate": {
"command": "npx",
"args": ["-y", "invovate-mcp-server"],
"env": { "INVOVATE_API_KEY": "inv_your_key_here" }
}
}
}Restart Claude Desktop. Then ask: “Create an invoice for Acme BV billing Globex for 3 consulting days at €900/day with 21% VAT, in English, and give me the PDF.”
Add the same block to the MCP config (~/.cursor/mcp.json for Cursor, or the
Windsurf MCP settings).
git clone https://github.com/LightSpeedPlusOne/invovate-mcp-server.git
cd invovate-mcp-server && npm install
INVOVATE_API_KEY=inv_your_key node src/index.js…and point your client at it:
{
"mcpServers": {
"invovate": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/src/index.js"],
"env": { "INVOVATE_API_KEY": "inv_your_key_here" }
}
}
}Env var | Default | Purpose |
| — | Free API key ( |
|
| Override the API base (rarely needed). |
npm test # lists tools + JSON math (no key)
INVOVATE_API_KEY=inv_xxx npm test # also exercises the PDF hosted-link pathNot regulated e-invoicing. UBL export is for interoperability/archival only. No Peppol / Factur-X / ZUGFeRD / XRechnung / NF-e compliance or network delivery.
Hosted links expire and the invoice is deleted after 7 days.
Docs for agents: https://invovate.com/invoice-api-for-ai-agents · OpenAPI: https://invovate.com/openapi.json
Once connected, ask your AI client in natural language:
Create an invoice for Acme Ltd for 3 hours of consulting at $120/hour. Return it as a PDF.
Generate a UBL 2.1 invoice for a SaaS subscription charged €49/month.
Make a Japanese invoice (¥) for ¥350,000 of web design with 10% consumption tax, and give me the link.Invoice API & docs: https://invovate.com/api · https://invovate.com/invoice-api-for-ai-agents
OpenAPI 3.1 spec: https://invovate.com/openapi.json (import as a ChatGPT / Claude Action)
MCP landing page: https://invovate.com/mcp-invoice-generator · All integrations: https://invovate.com/integrations
npm (this package): https://www.npmjs.com/package/invovate-mcp-server
Python SDK: https://pypi.org/project/invovate/ · JavaScript SDK: https://www.npmjs.com/package/invovate
Glama MCP directory: https://glama.ai/mcp/servers/LightSpeedPlusOne/invovate-mcp-server
Postman collection: https://www.postman.com/lightspeedplusone-9440989/workspace/invovate-invoice-api/overview
RapidAPI: https://rapidapi.com/LightSpeedPlusOne/api/invovate-invoice
WordPress plugin: https://wordpress.org/plugins/invovate-invoice-generator/
MIT © Invovate
Compute invoice totals (subtotal, per-line and global discounts, tax, shipping, deposit, grand total, balance due) without rendering a file. No API key required. Use this to validate amounts before generating a PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | The business issuing the invoice. | |
| to | Yes | The customer being billed. | |
| items | Yes | Line items (at least one). | |
| currency | No | ISO 4217 code, e.g. USD, EUR, GBP. Default USD. | |
| language | No | Invoice language. Default en. ar/ja/hi/ru render with embedded fonts. | |
| template | No | PDF template. Default classic. | |
| number | No | Invoice number; auto-generated if omitted. | |
| date | No | ISO date, e.g. 2026-06-01. | |
| due_date | No | ||
| po_number | No | ||
| notes | No | ||
| terms | No | Payment terms, e.g. "Net 30". | |
| global_tax | No | Tax % applied to all lines without their own tax_rate. | |
| global_discount | No | ||
| global_discount_type | No | ||
| shipping | No | ||
| deposit | No | ||
| amount_paid | No | Amount already paid (for partial invoices). | |
| payment | No | ||
| accent_color | No | Hex color like #2563eb. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description discloses it computes totals and does not render a file, but does not mention output format, side effects (none expected), or any rate limits. For a read-only computation, the transparency is moderate.
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?
Two concise sentences with no unnecessary words. The key information is front-loaded.
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?
The tool is complex (20 params, nested objects, no output schema). The description lists computed fields but does not explain calculation precedence, return value structure, or edge cases, leaving gaps for an agent.
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 description coverage is 60%, so the baseline is 3. The description adds no new parameter information beyond listing the computed fields (subtotal, discounts, etc.), which is helpful but not supplementary to the schema.
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 description explicitly states 'Compute invoice totals ... without rendering a file' and contrasts with generating a PDF, making the purpose clear and distinguishing it from siblings like generate_invoice_pdf.
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 advises 'Use this to validate amounts before generating a PDF' and notes 'No API key required', providing good context. However, it does not explicitly state when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a PDF invoice. By default returns a shareable 7-day hosted link that renders the PDF (best for chat — give the link to the user). If save_path is provided, the binary PDF is written to that local file instead. Set INVOVATE_API_KEY (free) for reliable PDF output.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | The business issuing the invoice. | |
| to | Yes | The customer being billed. | |
| items | Yes | Line items (at least one). | |
| currency | No | ISO 4217 code, e.g. USD, EUR, GBP. Default USD. | |
| language | No | Invoice language. Default en. ar/ja/hi/ru render with embedded fonts. | |
| template | No | PDF template. Default classic. | |
| number | No | Invoice number; auto-generated if omitted. | |
| date | No | ISO date, e.g. 2026-06-01. | |
| due_date | No | ||
| po_number | No | ||
| notes | No | ||
| terms | No | Payment terms, e.g. "Net 30". | |
| global_tax | No | Tax % applied to all lines without their own tax_rate. | |
| global_discount | No | ||
| global_discount_type | No | ||
| shipping | No | ||
| deposit | No | ||
| amount_paid | No | Amount already paid (for partial invoices). | |
| payment | No | ||
| accent_color | No | Hex color like #2563eb. | |
| save_path | No | Optional absolute path to write the .pdf file to. If omitted, a 7-day hosted link is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear full burden. It discloses that save_path triggers file output, and that a hosted link expires in 7 days. However, it doesn't specify the impact of missing API key, confirmation of non-destructiveness, or any rate limits, leaving gaps.
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?
Three sentences, each adding essential information: purpose, mode selection, and configuration. No redundant or filler content; highly efficient.
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?
Given the tool's high complexity (21 parameters, nested objects, no output schema), the description is too brief. It lacks details on API key consequences, hosted link format, failure modes, and overall behavior, leaving an agent under-informed for correct invocation.
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?
The input schema covers 62% of parameters with descriptions, but the tool description adds little beyond mentioning save_path. It does not explain the return behavior beyond the two modes, and does not clarify the meaning or interaction of many parameters (e.g., templates, color, payment info).
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 description clearly states 'Generate a PDF invoice', specifying both the verb and resource. It distinguishes from sibling tools by focusing on PDF output and mentions two modes of return (hosted link vs file), making its purpose specific and unambiguous.
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?
Explicitly describes two distinct usage paths: default for chat (hosted link) and local file via save_path. Mentions the need for an API key for reliable output. While it doesn't directly compare to siblings, the differences are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a UBL 2.1 XML invoice (for interoperability/archival — NOT a regulated e-invoice transmission; no Peppol/Factur-X/XRechnung compliance). Returns the XML as text. Requires INVOVATE_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | The business issuing the invoice. | |
| to | Yes | The customer being billed. | |
| items | Yes | Line items (at least one). | |
| currency | No | ISO 4217 code, e.g. USD, EUR, GBP. Default USD. | |
| language | No | Invoice language. Default en. ar/ja/hi/ru render with embedded fonts. | |
| template | No | PDF template. Default classic. | |
| number | No | Invoice number; auto-generated if omitted. | |
| date | No | ISO date, e.g. 2026-06-01. | |
| due_date | No | ||
| po_number | No | ||
| notes | No | ||
| terms | No | Payment terms, e.g. "Net 30". | |
| global_tax | No | Tax % applied to all lines without their own tax_rate. | |
| global_discount | No | ||
| global_discount_type | No | ||
| shipping | No | ||
| deposit | No | ||
| amount_paid | No | Amount already paid (for partial invoices). | |
| payment | No | ||
| accent_color | No | Hex color like #2563eb. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return type (XML as text) and the API key requirement. However, it does not mention any side effects, rate limits, or confirm that the tool is non-destructive. More behavioral context would be beneficial.
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?
The description is two sentences, front-loading the core purpose and exclusions, then providing return type and prerequisite. Every word adds value, and no unnecessary detail is present.
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?
Given the complexity (20 parameters, nested objects, no output schema), the description covers the essential return type and non-compliance caveat but lacks guidance on parameter usage, error handling, or the expected XML structure. It is adequate for a simple tool but incomplete for a complex one.
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?
The description does not elaborate on any parameters, leaving all semantic value to the input schema, which has 60% coverage. The schema provides some descriptions, but the description itself adds no additional meaning for the remaining 40% of parameters. This is insufficient compensation.
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 description clearly states the tool generates a UBL 2.1 XML invoice for interoperability/archival, and explicitly distinguishes from regulated e-invoice transmissions (Peppol/Factur-X/XRechnung). This uniquely identifies its purpose relative to siblings like generate_invoice_pdf and calculate_invoice_totals.
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?
The description explicitly notes when to use (for interoperability/archival) and when not (not for regulated compliance). It also mentions the prerequisite INVOVATE_API_KEY. However, it does not explicitly compare to sibling tools or provide alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what the Invovate invoice API supports: languages, PDF templates, and notable features. Use this to pick valid language/template/currency values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly describes a read-only listing operation with no destructive or authorization concerns, though it could mention that it is a safe, idempotent call.
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?
The description is two short, front-loaded sentences with no wasted words. Each sentence provides essential information about purpose and usage.
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?
Given zero parameters and no output schema, the description is complete. It explains what the tool returns and how to use it, and sibling tools provide additional context for when to invoke this one.
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?
No parameters exist, so the input schema is fully covered. The description adds value by specifying what the tool lists, which is sufficient.
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 description explicitly states the tool lists supported languages, PDF templates, and notable features for the Invovate invoice API, distinguishing it clearly from sibling tools that calculate or generate invoices.
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?
The description advises using this tool to pick valid language/template/currency values, providing clear context for its use. It does not explicitly state when not to use it or mention alternatives, but the sibling tools make the distinction clear.
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. Dates show when Glama detected each change.
v0.1.1calculate_invoice_totalsgenerate_invoice_pdfgenerate_invoice_ublget_invoice_capabilitiesEach tool has a clearly distinct purpose: calculating totals, generating PDF, generating UBL XML, and retrieving capabilities. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., generate_invoice_pdf, get_invoice_capabilities). The convention is uniform and predictable.
With 4 tools covering calculation, PDF generation, UBL generation, and capabilities, the scope is well-targeted for an invoice generation server. Each tool serves a necessary purpose without bloat.
The tool set covers the core invoice generation workflow (validation, PDF, UBL, capabilities). Missing are retrieval or management of previously generated invoices, but these are arguably outside the stated scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create PDF invoices from your AI chat: clients, numbering, VAT, overdue reports. All data is local.
Send invoices from Claude and ChatGPT. One sentence becomes a PDF with a Stripe payment link.
Invoicing you drive by talking to your AI: log time, raise invoices and track what's owed via MCP.
Create and manage invoices and customers on Jupiter Invoice (MCP, API-key auth).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LightSpeedPlusOne/invovate-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
