Ask Claude to help with your budget and it can reason about money in general, but it can't see yours. MCP — the Model Context Protocol — is what closes that gap: a standard way for an assistant to call tools against real data.
The category is young enough that searching for it is misleading. Most results for "finance MCP server" are market-data feeds: stock quotes, tickers, SEC filings, crypto prices. Useful, but they have nothing to do with your chequing account. This post is about the other kind.
We make one of the tools here. There are only a handful of honest options, so the list is short and the caveats are the useful part.
#The three approaches
| Approach | What it reads | Where your data sits | Setup |
|---|---|---|---|
| Finance app with built-in MCP | That app's transaction data | The app's storage, or your machine | Easiest |
| Generic database MCP | A ledger file or DB you maintain | Your machine | Medium — you build the ledger |
| Aggregator API wrapper | Live bank data via Plaid etc. | Aggregator + wherever the server runs | Hardest, most exposure |
#1. A finance app that ships an MCP server
The path of least resistance: use an app that already has your transactions and exposes them as tools. You get real categorisation, budgets and history rather than raw rows, because the app has already done that work.
Pare (ours) does this. It reads bank and credit-card statements you download — PDF or OFX/QFX — parses and categorises them locally, then exposes 24 MCP tools: 13 read (spending summaries, category breakdowns, cash-flow, subscriptions, income, budget status, insights) and 11 write (set budget goals, add categorisation rules, tag transactions, mark reimbursements). So "how much am I spending on subscriptions, and which ones went up?" is one question, not a dashboard crawl.
Self-hosted, the MCP server runs on your machine against a local SQLite file, and nothing leaves it — including the part where Claude reads your data, if you're running a local model or using Claude Desktop's local stdio transport. It's AGPL open source, free to self-host, $8/month hosted. Setup is in the MCP docs.
Some other budgeting apps have community-built MCP servers of varying maturity. If you're already committed to a tool, search its issue tracker or the MCP registry before switching — an unofficial server against a tool you already use may beat migrating.
#2. A generic database or filesystem MCP over your own ledger
If you keep plain-text accounting (Beancount, hledger) or your own SQLite database, you don't need a finance-specific server at all. Point a generic SQLite MCP server or a filesystem MCP at your ledger and Claude can query it directly.
This is the most flexible option and the most work. You're maintaining the ledger yourself, and you're writing the queries — or asking Claude to, which works better than you'd expect if your schema is clean. For people already doing plain-text accounting, this is often the right answer and costs nothing.
#3. An aggregator API wrapper
Some servers wrap Plaid or a similar aggregator so the model can pull live bank data. This gives you fresh balances, and it means your bank connection, the aggregator, and the MCP server are all in the path. That's a lot of surface for a convenience.
If you go this route, run it yourself rather than using a hosted one, and read the code first.
#What to check before you connect anything
The tooling is new, and the failure modes are financial. Five things worth checking:
- Where does the data physically go? A local stdio server on your machine is a different risk profile from a remote server holding an API token. Know which you have.
- Does it ask for bank credentials? Nothing legitimate needs your online-banking password to set up an MCP server. Walk away.
- What can it write? Read-only tools can leak; write tools can also change things. Pare's write tools cover budget goals, rules and tags — not payments, because it can't move money and never should be able to.
- Is the source readable? For something touching your finances, "open source" isn't a nice-to-have. You want to be able to check.
- What does the model provider see? If the server runs locally but you're using a hosted model, your transaction data still goes to the model provider in the conversation. That's often fine — it's worth knowing rather than assuming.
That last one is the honest caveat about all of this, including ours: self-hosting the MCP server keeps your data off our servers, not out of the conversation. If you're asking a hosted model about your spending, the model sees your spending.
#What it's actually good for
Having tried this for a while, the genuinely useful queries aren't the ones you'd guess. "What did I spend last month" is a chart; you didn't need an assistant. What works better:
- Comparative questions across time. "Is my grocery spending trending up over the last six months, adjusted for the months I travelled?"
- Finding things you didn't know to look for. "Which subscriptions have I been paying for more than a year without the amount changing?"
- Rules and cleanup. "Everything from this merchant is groceries — make that a rule and re-run it." That's a write tool doing a chore you'd otherwise click through.
- Sanity checks before a decision. "If I keep spending at this rate, what's my balance on the 15th?"
The pattern: questions with a shape, where building the report is more work than asking.
We wrote about how this works in practice in ask Claude about your money.
#Where this is going
The personal-finance MCP space is thin right now — a handful of tools, mostly early. That will change, and the thing worth holding onto as it does is the question in the middle of this post: not which server has the most tools, but where your financial data goes when the model reads it.
If you want to try the statements-based approach, Pare is free to self-host and the setup guide covers both Claude Desktop and Claude Code. The statement download guides cover getting the files out of your bank in the first place.