Connect Claude, ChatGPT or a Local Model to Your Invoicing — A Self-Hosted MCP Server You Already Own

There is a gap between "my assistant can talk about my invoices" and "my assistant can read my invoices". The first is a conversation. The second needs a door into the actual system, and for most small businesses that door does not exist — the invoicing lives in a hosted product whose vendor decides what an outside agent may see.

If the invoicing runs on your own server, you get to decide instead.

What is actually on offer

Every app in this catalogue speaks the Model Context Protocol at POST /mcp. It shipped with the 3.0 release and it is not an add-on, a paid tier or a beta: it is a route in the same application, behind the same API key, obeying the same roles as the browser.

The transport is streamable HTTP, stateless — one JSON-RPC request in, one JSON response out. No daemon, no socket, no separate service to keep alive. If the app is up, the endpoint is up.

The whole recipe

Mint a key inside the app first — Settings → API keys. It is shown exactly once and you can revoke it from the same page at any time.

Then there are only three facts, and every client takes the same ones:

• the address — https://invoices.example.com/mcp
• the key — the header Authorization: Bearer apk_xxxx
• the transport — MCP over streamable HTTP

Where they go depends on what you use.

Claude. One command in Claude Code, or the same URL and header added as a custom connector in the desktop and web apps:

claude mcp add --transport http invora https://invoices.example.com/mcp \
  --header "Authorization: Bearer apk_xxxx"

ChatGPT and the OpenAI API. One entry in the Responses API's tools array — in ChatGPT itself, the same URL and key go in as a connector:

{
  "type": "mcp",
  "server_label": "invora",
  "server_url": "https://invoices.example.com/mcp",
  "authorization": "apk_xxxx",
  "require_approval": "never"
}

A client that keeps its servers in a config file — Own Your AI, editors like VS Code and Cursor, and most desktop clients:

{
  "mcpServers": [
    { "id": "invora", "name": "Invora", "url": "https://invoices.example.com/mcp",
      "token": "apk_xxxx", "enabled": true }
  ]
}

A local model, n8n, or your own code. n8n's MCP Client node takes the URL and the same Authorization: Bearer header. A model running on your own machine reaches it through any MCP client, which means nothing leaves your network at all. And writing it yourself is one POST:

curl -X POST https://invoices.example.com/mcp \
  -H "Authorization: Bearer apk_xxxx" -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Any client that speaks the streamable-HTTP transport works, including ones that do not exist yet. The endpoint implements a protocol, not an integration with a particular vendor — which is the difference between a door and a partnership.

That is the entire integration. Three facts: an id, a URL, a token.

Make the key read-only

This is the part worth slowing down for.

When you mint the key you choose what it may do. Pick Read only and the endpoint stops advertising the tools that change anything. An assistant connected with that key sees five tools on Invora instead of nine — the lists, the single-document lookup, the overdue report, the client list — and if it tries to call create_invoice anyway, it is refused by name, in a sentence written for a model to read and stop.

Most of what people actually want from an assistant is read-shaped:

Which invoices are overdue, and by how much in total?
What did we bill this client in the last quarter?
Are there estimates sitting unaccepted for more than three weeks?

None of that needs write access. Give it read-only and the worst outcome of a confused model is a wrong answer you can check, rather than a document you have to unpick.

Hand over a read-and-write key when you actually want the drafting: a recurring invoice built from last month's, a payment recorded from a bank line you pasted in. Everything it does then lands in the audit log with the key's user beside it, and the app's own rules still apply — an agent cannot do anything that user could not do by hand.

What it will not do, on any key

Two things are missing from the tool list on purpose, and they will stay missing.

Nothing emails your customers. There is no send tool. An assistant can draft an invoice and tell you it is ready; pressing send remains a human click, because a model that misunderstands a prompt should not be able to put your name in a stranger's inbox.

Nothing deletes. There is no delete tool anywhere in this catalogue. Destroying records is a decision, not an operation.

There is a third rule specific to money: the model never computes a total. It sends line descriptions, quantities and unit prices as strings; Invora's integer-cent engine does the arithmetic, the tax and the rounding. This is not politeness — floating-point arithmetic produced by a language model is exactly the kind of nearly-right that survives review.

The constraint nobody mentions in the marketing

Your server has to be reachable by whatever is doing the asking.

An assistant running on your own machine — Claude Code in your terminal, Own Your AI on your laptop — can reach a private address on your network, so https://invoices.internal/mcp works fine and nothing about your invoicing is ever exposed to the internet.

A hosted assistant cannot. If the client is a service running in somebody else's data centre, it can only reach a publicly resolvable URL — which means putting the app behind a real hostname and TLS, and accepting that the endpoint is now on the internet with a bearer token as its only lock. That is a normal, defensible setup; it is also a decision, and it is the one place in this recipe where "self-hosted" stops being automatically private.

If that trade does not appeal, the answer is to run the assistant locally too. That is the entire premise of the local-first side of this catalogue.

Try it before you trust it

Every app here has an ungated demo. Point a client at a demo instance with a read-only key and ask it three real questions about data you can verify with your own eyes. You will learn more in ten minutes than from any vendor's capability list — including ours.

---

Next steps

• Connect your AI — the same recipe, plus every product that answers it
• Invora — the invoicing app used in the examples above; its full tool list is in the API.md inside the download
• Let an agent run your rota — the write-shaped companion to this read-shaped one

This guide sells nothing you do not already own if you bought any app in this catalogue. The endpoint has been there since 3.0; the only new thing is a key that can be told to read and not write.