Automating Client Invoices With the MCP Server

If you draft the same kind of invoice over and over, say a monthly retainer with three fixed line items, you can hand that work to an assistant and stop opening the form. The MCP server lets a tool like Claude or Cursor create and manage your invoices by talking to JupiterInvoice directly. You describe the invoice in plain language, it builds the draft, and you review the link before it goes out.

Here is how to set it up and what the assistant can and cannot touch.

What the MCP server actually does

MCP stands for Model Context Protocol. It is a standard way to give an AI assistant a set of tools it can call. The JupiterInvoice MCP server exposes your invoicing account as those tools, so the assistant can create a draft, add line items, set payment terms, generate the private link, and check an invoice's status.

It runs on the same foundation as the automated invoicing API. The REST API is the lower-level route if you are writing code. The MCP server is the route when you want an assistant to do the clicking for you, in a chat window, with no script to maintain. Both create the same invoices, with the same fields and the same rules.

One thing to be clear about: JupiterInvoice does not hold or move money. The MCP server creates the invoice and the link. Your client pays by card if you have connected Stripe, or pays your bank details directly. The server tracks the invoice through to paid. It is not a payment processor.

Connecting the server to your assistant

You sign in to JupiterInvoice with a magic link or Google, the same way you would to build an invoice by hand at the create screen. From there you generate the credentials the MCP server needs and add the server to your assistant's config. The exact config block depends on which client you use, and the setup details live on the API and MCP page.

Once it is connected, test it with something small. Ask the assistant to list your recent invoices, or to create a draft for a made-up client. If it can read your invoices back and produce a draft link, the connection works. Do that before you point it at a real client.

A first real request

Start with a draft, not a send. Something like: "Create a draft invoice for Harbor Design for 2,400 dollars, one line item, October retainer, Net 30." The assistant calls the create tool, fills the fields, and hands you back a draft you can open.

Check it. The due date should match your terms (if you are not sure what Net 30 lands on, the due date calculator settles it). Confirm the line item wording, the currency, and that your bank details are correct. When it looks right, you can tell the assistant to send it, or open the link and send it yourself. Either way the recipient gets a private link, no account, no PDF to download unless they want one.

What the assistant can change, and what it can't

The MCP server plays by the same field rules as the rest of JupiterInvoice. Knowing them keeps you from asking it to do something that quietly fails or rewrites history.

Some fields are locked once an invoice is issued: the invoice number, the issue date, your own details, and your bank details. No tool call changes those. That is deliberate, so your numbering stays clean and an issued invoice does not shift under an auditor's feet. If you want the mechanics, see how invoice numbers survive an audit.

Content fields, the ones that change what the client owes, are editable while the invoice is open: line items, pricing, discounts, currency, payment terms, due date. When the assistant changes any of these, JupiterInvoice creates a new version (V1, V2, and so on), so you can always see what the old one said and roll back.

PO number, billing entity, billing address, and AP contact are tracked as amendments to the current version rather than new versions. Your client can also edit these four themselves from their link, and you get notified and can revert. If you want the fuller split of what is locked, editable, and requestable, that breakdown is here.

Managing invoices after they are sent

The server is not just for creating. You can ask the assistant where an invoice stands: Draft, Sent, Viewed, or Paid. That is useful when you are triaging a stack. "Which of my October invoices are Sent but not Viewed?" tells you exactly who to nudge, and who opened the link and went quiet.

Note what the status does not include: there is no approve step the recipient clicks. They cannot mark an invoice approved for payment; the lifecycle runs straight to Paid when payment lands or you record it. If a client asks for a change to a locked or sender-only field, they do it in the comment thread, and you decide. The assistant can read those comments back to you, but it cannot invent an approval that does not exist.

When to reach for code instead

The MCP server is the right tool when you want a human in the loop, reviewing each draft before it goes. If you want invoices generated with no human at all, on a schedule or triggered by another system, write against the REST API directly. The walkthrough for that is in automating invoicing end to end.

For most people running lean, the assistant route is enough. You keep the judgment call, you skip the typing. Set it up once, send your first draft through it this week, and see how much of the form you never open again.