An MCP server that lets any AI assistant (Claude, and other MCP clients) create invoices with Blank Invoice Maker — the free, no-signup, no-watermark invoice generator.
Ask your assistant to make an invoice, and it returns a link that opens blankinvoicemaker.com with the invoice fully pre-filled, ready to review and download as a PDF.
Privacy by design. The invoice data travels inside the link's URL fragment (
#invoice=…) and is decoded entirely in your browser. Nothing is uploaded — consistent with Blank Invoice Maker's no-account, no-server-storage model.
Tool | What it does |
| Lists the industry invoice templates available at blankinvoicemaker.com/templates (slug, name, description, URL). |
| Builds an invoice from your details and returns a pre-filled blankinvoicemaker.com link to review and download. |
create_invoice example"Invoice Globex LLC for 10 hours of design at $90/hr and one $120 hosting setup, net 14, in GBP."
The assistant calls create_invoice with:
{
"business": { "name": "Acme Studio", "email": "hi@acme.studio" },
"client": { "name": "Globex LLC", "email": "ap@globex.com" },
"items": [
{ "description": "Design work", "quantity": 10, "unitPrice": 90, "unit": "hours" },
{ "description": "Hosting setup", "quantity": 1, "unitPrice": 120 }
],
"currency": "GBP",
"paymentTerms": "Net 14"
}…and returns a https://blankinvoicemaker.com/#invoice=… link that opens the editor pre-filled.
Related MCP server: Invoice MCP Server
Requires Node.js 18+.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"blank-invoice-maker": {
"command": "npx",
"args": ["-y", "blank-invoice-maker-mcp"]
}
}
}Run the server over stdio:
npx -y blank-invoice-maker-mcpcreate_invoice maps your input into the invoice structure used by blankinvoicemaker.com, compresses it with lz-string, and appends it to the site URL as a #invoice= fragment. Opening the link hydrates the editor in your browser — no signup, no watermark, no data leaving your machine.
npm install
npm run build # compile TypeScript to dist/
npm test # build + run the unit tests
npm start # run the server over stdiosrc/templates-data.ts is generated from the Blank Invoice Maker template registry:
BIM_APP_DIR=/path/to/blank-invoice-maker npm run generate:templatesTemplates: https://blankinvoicemaker.com/templates
Model Context Protocol: https://modelcontextprotocol.io
Create a professional invoice and return a link that opens it — fully pre-filled — in the free Blank Invoice Maker editor (https://blankinvoicemaker.com). No signup, no watermark. The user opens the link to review and download the PDF; all invoice data stays in their browser (it travels in the link's URL fragment and is never sent to a server).
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes | Your business — the sender / payee | |
| client | Yes | The client being billed | |
| items | Yes | Line items (at least one) | |
| currency | No | ISO currency code, e.g. "USD", "EUR", "GBP". Default "USD" | |
| invoiceNumber | No | Default "INV-001" | |
| invoiceDate | No | YYYY-MM-DD. Default: today | |
| paymentTerms | No | e.g. "Net 30", "Due on receipt". Default "Net 30" | |
| dueDate | No | YYYY-MM-DD. Default: derived from payment terms | |
| taxes | No | Tax lines. Omit for a tax-free invoice | |
| discountRate | No | Invoice-wide discount in percent | |
| notes | No | Footer notes / payment instructions | |
| documentTitle | No | Document title, e.g. "Invoice", "Proforma Invoice" | |
| color | No | Accent colour as a hex code. Default #3b82f6 | |
| bank | No | Bank / payment details |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It reveals that the tool returns a link, that invoice data travels in the URL fragment and never reaches a server, and that no signup or watermark is involved. This is highly transparent about privacy and output, though it omits error handling or rate limits.
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 three sentences, each adding distinct value: purpose, benefits, and data privacy. It is front-loaded with the core action and remains concise without unnecessary words.
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 (14 parameters, nested objects, no output schema), the description covers the essential behavioral aspects and privacy model. However, it lacks specification of the return format (e.g., whether the response is a JSON object with a 'url' field), which would aid agent processing.
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 has 100% description coverage, so the baseline is 3. The tool description does not add additional meaning beyond what the schema already describes for each parameter, so no extra credit is warranted.
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 action ('Create a professional invoice'), the resource ('invoice'), and the output ('return a link that opens it'). It also distinguishes from the sibling 'list_templates' by specifying the purpose is to generate a new invoice, not list existing templates.
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 provides clear context for when to use the tool (e.g., when the user wants to create an invoice and get a link). It mentions benefits like no signup and no watermark. However, it does not explicitly state when to avoid this tool or provide alternatives beyond the implied 'list_templates' sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the industry-specific invoice templates available on Blank Invoice Maker (https://blankinvoicemaker.com). Returns each template's slug, name, description, and page URL. Use this to discover templates; build a custom invoice with create_invoice.
| 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 fully carries the burden. It discloses that the tool lists templates (read-only) and returns specific fields, but does not mention any additional behavioral aspects like rate limits or data freshness. Still sufficient for a simple list operation.
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 concise sentences, front-loading the purpose and linking to the sibling tool. No extraneous information.
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 simplicity (zero parameters, no output schema), the description fully covers what it does, what it returns, and how it relates to the sibling tool. No gaps.
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 tool has no parameters, and the schema covers 100% of the input. The description does not need to add parameter info; it correctly omits any.
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 lists invoice templates, specifies the returned fields (slug, name, description, page URL), and distinguishes it from the sibling tool create_invoice by indicating its discovery purpose.
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 explicitly says to use this tool for discovering templates and to use create_invoice for building a custom invoice, providing clear context and an alternative.
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.
v1.0.2create_invoicelist_templatesThe two tools have entirely distinct purposes: one lists templates, the other creates invoices from them. There is no overlap or ambiguity.
Both tools follow the consistent verb_noun pattern with snake_case (create_invoice, list_templates).
Only 2 tools, which is the minimal end of reasonable for a focused domain. While the server accomplishes its core purpose, the small count feels thin.
The tool set covers the full intended workflow: discovering templates and then creating an invoice from one. There are no obvious gaps for the stated scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let your AI send invoices and take payment — card or ACH. Free.
Send invoices from Claude and ChatGPT. One sentence becomes a PDF with a Stripe payment link.
Create PDF invoices from your AI chat: clients, numbering, VAT, overdue reports. All data is local.
AI invoice follow-up emails for freelancers. Draft-only, never sends for you.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/InnarM/blank-invoice-maker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
