Model Context Protocol
MCP server for your accounting
The Model Context Protocol lets an MCP-capable client treat your bookkeeping as a native tool source. Our MCP server is a thin adapter over the same REST API — same key, same scopes, same GoBD rules — exposing fourteen tools: ten to read your ledger and four to post. The hosted transport is live today, so there is nothing to install to get started.
What the MCP server is
One tool source, fourteen tools, zero magic.
When you register the server, your client discovers fourteen callable tools mapped one-to-one onto the bookkeeping endpoints. Ten read: company data, fiscal years, the chart of accounts, journal entries, the trial balance, open items, invoices and bank lines. Four write: manual bookings, Storno reversals, and issuing or booking invoices.
Because it is a thin adapter over the REST API, the MCP server can do exactly what the API can do and nothing more. The scope on your key decides whether the write tools are even usable — a read key exposes only the ten read tools in practice.
Remote transport — ready now
Hosted, nothing to install. This is the recommended path.
The remote transport is hosted for you. You add it over HTTP with a single command, passing your key as an Authorization header. There is no Node install, no local process to babysit, and updates land server-side. The exact server URL lives in the app under API access; in every sample we use the $MCP_URL placeholder.
# Remote (hosted) — ready now, nothing to install: claude mcp add --transport http buchhaltung \ "$MCP_URL" --header "Authorization: Bearer jab_live_…"
Local transport — parity, not published yet
A local Node stdio option exists for symmetry with the API docs.
There is also a local transport that runs over Node stdio via npx. We show it for parity with the API documentation, but the npm package @jahresabschluss/buchhaltung-mcp is not published yet — so treat the local command as a preview, not something that just works today. Lead with the remote URL path for anything real.
# Local (Node stdio) — package not published yet, preview only: claude mcp add buchhaltung --env JAB_API_KEY=jab_live_… \ -- npx -y @jahresabschluss/buchhaltung-mcp
Claude Desktop configuration
For the desktop client, the server is declared in the config file.
Claude Desktop reads its servers from claude_desktop_config.json. You add a buchhaltung entry under mcpServers with the npx command and your key in the environment. The same caveat applies: the local package is not published yet, so the desktop stdio path is a preview while the hosted HTTP transport is the ready-now option.
Same key, same GoBD rules
MCP changes the interface, never the safety model.
- One key equals one company; the company is derived from the key, never a tool argument.
- Scopes still apply — a read key can call read tools only.
- Write tools run through the GoBD booking core: append-only, Festschreibung, Storno instead of delete, Soll equals Haben.
- No SQL passthrough and no free query — the tool set is a fixed allowlist.
- The server reaches bookkeeping data only; the product's own AI and internal logic are not bookkeeping resources and stay unreachable.
Frequently asked questions
Which clients can use the MCP server?
Any MCP-capable client. Claude Code and Claude Desktop are the primary examples. The remote HTTP transport is the ready-now path and needs nothing installed locally.
Is the npx package available?
Not yet. The npm package for the local stdio transport is not published, so use the hosted remote transport for real work. We show the local command only for parity and preview.
How many tools does the server expose?
Fourteen — ten read tools and four write tools — each mapping directly onto a bookkeeping endpoint. Your key's scope decides whether the four write tools are usable.
Where do I find my server URL and key?
Both live in the app under Buchhaltung, API access. We never print the literal server host on a public page; samples use the $MCP_URL placeholder instead.
Does MCP relax any GoBD guarantee?
No. The MCP server is a thin adapter over the REST API, so every write still passes through the same booking core with the same append-only and Storno rules the manual UI enforces.