MCP servers for accounting software: who has one

Look at what people type into Google next to the name of their accounting tool: sevDesk MCP. DATEV MCP. Lexoffice MCP. WISO Steuer MCP. ELSTER MCP. We see this cluster in our own Search Console every month, and it has the shape of a question users have already decided the answer to. They are not asking whether AI agents are coming for bookkeeping. They are checking whether their vendor is ready.

Mostly, the vendor is not. The short version of 2026: a handful of finance tools publish their own Model Context Protocol server, a much longer list has a community project wrapping its public API, and most German accounting and banking products have nothing at all.

Why this became a real question in 2026

MCP stopped being one vendor's idea. It moved to the Linux Foundation in December 2025 with OpenAI, Google and Microsoft as co-sponsors, and by March 2026 it was doing on the order of a hundred million SDK downloads a month. That is infrastructure adoption, not hype-cycle adoption.

The demand side moved with it. Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5% in 2025. Forrester expects roughly 30% of enterprise app vendors to ship an MCP server in the same window. Xero published an official server and announced a multi-year partnership with Anthropic in March 2026. Spendesk went live with an MCP integration at Money20/20 Europe in June.

The practical consequence for anyone building finance software: the assistant is becoming the first screen. People ask their agent what they spent last month before they open the app that knows the answer. If your product cannot answer through that channel, someone's wrapper will answer on your behalf, with your data, under your brand, and you will not see the request.

Which accounting and tax tools have an MCP server?

Here is the German stack, the one those queries are actually about, as of August 2026, from public directories and vendor documentation. "Community" means a third-party project built on the vendor's public API, not something the vendor ships or supports.

Two things stand out. First, the German mid-market accounting stack is served almost entirely by volunteers: only two rows above are maintained by the vendor whose data they expose. Second, the queries with the highest intent, the ones about filing and about banks, point at systems where an MCP server cannot simply be bolted on: submitting a German tax return means going through certified filing software, not an HTTP endpoint someone wrapped last weekend.

The banking row is worth a second look, because the first bank-side server to appear is not a data API at all. Vivid's opens a business account from inside the chat, with balances and transactions listed as coming later. Read that as a signal about what this channel is for right now: the earliest movers are using it to acquire customers, not to serve them.

Being findable counts as much as existing. Ours is listed in Anthropic's connector directory and in ChatGPT's plugin directory, which is what decides whether a user reaches it by asking their assistant or by pasting a URL they first have to know about.

First-party or community server: does it actually matter?

For read-only exploration, a community wrapper is often fine and I would rather it exist than not. The difference shows up the moment an agent writes.

• Auth scope. A wrapper usually asks you for a long-lived API key with whatever permissions that key already has. A first-party server can issue a token scoped to one company and one session, resolved per request, so a tool call cannot reach data outside the caller's own books.
• Which tools exist at all. The vendor decides what is callable. We deliberately expose no tool that can hard-delete a filed document, because there is no prompt phrasing that should be able to do that. A wrapper over a permissive API inherits every dangerous endpoint whether it wants to or not.
• Irreversible actions. Anything that leaves the building, sending an invoice, submitting a return, paying a bill, needs an explicit human gate. That gate has to live in the product, not in the model's good intentions.
• Survival. A community server tracks an API it does not control. When the vendor changes a field, the wrapper breaks silently, mid-conversation, and the agent reports something plausible instead.

None of that is an argument that vendors are more virtuous. It is an argument about who can enforce an invariant.

What changes when an agent can write to your books

We have run a first-party MCP server in production for a while now, north of a hundred tools across bookkeeping, invoicing, documents and tax reports. Three things surprised me.

Agents ask for things the UI never surfaced. Our dashboards were built around the questions we assumed people had. Through an agent, users ask combinations nobody would click their way to: this vendor's total across two years, by quarter, excluding refunds. Tool design turned out to be product research.

Tool descriptions are user interface. The model reads the description and decides. A vague one gets called for the wrong job, and the failure is not a stack trace, it is a confidently wrong answer with a receipt attached to the wrong month. We now review tool text the way we review UI copy.

Read-only is a feature, not a limitation. Our newest surface deliberately connects other systems as read-only, owner-only sources. The instinct to make everything writable is worth resisting: the majority of what people ask an agent to do with their finances is a question, not a command.

If you want the longer version of how we approached this, we wrote up the accounting MCP server itself and what it means for a GmbH's tax work. The same reasoning drove our VAT filing agent, where the irreversible step sits behind a hash-bound human approval.

Do you still need an MCP server if you already have an API?

Yes, and the reason is boring: an API tells a developer what is possible, while an MCP server tells a model what to do next. Endpoint names, pagination and error codes are a specification. Tool names, descriptions and argument shapes are instructions. The same REST surface can be excellent for integrators and unusable for an agent, because nothing in it says which of the four ways to fetch a transaction is the right one.

There is also a distribution argument. A REST API is something a customer's engineer integrates over a sprint. An MCP server is something a customer connects in a minute, inside the assistant they already have open. Those are different funnels.

How to evaluate a vendor's MCP server

If you are choosing accounting software in 2026 and you care about this, the vendor call is short:

1. Do you publish and support the server yourself, or is the one I found on GitHub someone else's?
2. What is the auth model? Per-session scoped tokens, or do I paste a permanent key with full rights?
3. Which tools can write, and which actions require an explicit human confirmation?
4. Is it listed in the public MCP directories, so my assistant can find it without me pasting a URL?
5. What is logged? Can I see, afterwards, exactly which tool ran with which arguments?

Question 5 is the one people forget and the one an auditor will ask.

Questions people ask

Does sevDesk have an MCP server?

Not an official one as of August 2026. There are community MCP servers for sevDesk built on its public API, which can let an agent read receipts, prepare invoices and trigger exports. Because they are third-party projects, capabilities and write permissions vary by build, and they can break when the underlying API changes. Check who maintains the one you connect.

Is there a DATEV MCP server?

DATEV does not publish one. Community projects exist that wrap DATEV-facing APIs and export flows. For most German businesses the practical path is the other direction: use an accounting tool that both talks to DATEV and exposes its own supported MCP server, so the agent works against a maintained surface rather than a wrapper.

Can an AI agent file my VAT return with ELSTER?

Not by calling ELSTER directly. German electronic filing runs through certified software, so an agent can prepare and validate a return, but the submission goes through the certified path. In our own product the agent assembles the return and a person approves the exact figures before anything is transmitted. Treat any tool claiming fully autonomous filing with suspicion.

Does my bank have an MCP server?

If it is an incumbent, almost certainly not, which is why "N26 MCP" and "Sparkasse MCP" are searched and unanswered. Some challengers have shipped: Vivid publishes an open-source MCP server for opening a business account from a chat. For everyone else, bank data reaches an agent indirectly, through a bookkeeping tool that syncs the account via a licensed aggregation provider and exposes the transactions through its own server.

Is MCP safe for accounting data?

The protocol is a transport; the safety is in the implementation. Ask three questions: is the token scoped to one company and one session, are irreversible actions gated by a human, and is every tool call logged with its arguments. A server that answers yes to those is more trustworthy than a wrapper holding a permanent full-access key, regardless of which model is on the other end.

Where this goes

My expectation is that by mid-2027 "does it have an MCP server" will be a line item in accounting software comparisons, next to DATEV export and e-invoicing support. The vendors who wait will not lose because agents are magic. They will lose because their customers will have gotten used to asking, and something else will have been answering.

If you want to see what this looks like from the inside, our AI bookkeeping write-up covers the categorization side, and the CLI is the same surface for people who live in a terminal.