What an MCP server actually changes about portfolio data
Connecting a portfolio to Claude and ChatGPT is not a chat feature. It is an access-control problem, and that is the part worth getting right.
Every finance tool is adding a chat box. Most of them are doing the same thing underneath: a text field that hits an LLM with some retrieved context stapled to the prompt. It demos well. It also means your data has to be copied somewhere it did not previously live, and the assistant can only answer the questions the tool anticipated.
We took a different route with Wealth Management by Zahlenwerk. Instead of building a better chat box, we exposed the portfolio as an MCP server, so Claude and ChatGPT can read it directly, in whatever assistant the firm already uses.
The interesting part is not the protocol
MCP itself is a thin thing: a way to describe tools and resources so an assistant can call them. Writing one that returns a fund's NAV takes an afternoon.
The hard part is that you are now handing an autonomous agent a door into financial records. That reframes the problem from "what can we let it read" to "who is asking, on whose behalf, and what happens when it is wrong".
Three decisions did most of the work for us.
Real OAuth, not an API key
The obvious shortcut is a long-lived token pasted into a config file. It is also the wrong answer: tokens get shared, they do not expire, and they carry the permissions of whoever generated them forever.
We implemented a full OAuth 2.1 authorization server with PKCE and dynamic client registration. Claude and ChatGPT connect the same way any other OAuth client would. Access is scoped to the person who authorized it, it inherits their role in the workspace, and it can be revoked without rotating anything else.
This was substantially more work than a token. It is the difference between a demo and something a family office will actually connect to their books.
Reads are cheap, writes are not
Reading a position is safe: worst case the assistant summarizes something incorrectly and a human notices. Recording a capital call is not. It changes the cost basis, which changes IRR, which changes what a fund reports to its LPs.
So writes are gated. When the assistant wants to record a cashflow or add a valuation, it does not just do it. It produces a proposed action, the interface shows exactly what will change, and a person confirms. The agent drafts, the human signs.
That single boundary removes most of the anxiety about giving an assistant write access, and it costs one extra click on the operations that deserve one.
Tools should mirror the domain, not the database
Our first pass exposed tools that looked like the schema: list_positions, get_valuations, list_position_events. Technically complete, and the assistant used them badly, issuing four calls to answer a question a person would state in one sentence.
Naming tools after the question rather than the table fixed more behaviour than any amount of prompt tuning. An assistant given get_portfolio_summary answers "how did we do this quarter" in one call. An assistant given a table browser reinvents a query engine, poorly, every time.
What it looks like in practice
The useful outcome is unglamorous. Someone asks their assistant what their unfunded commitment is across six funds, and it answers, because it read the actual positions rather than a stale export. Someone asks it to draft the quarterly LP update, and the numbers in the draft are the numbers in the system.
No new dashboard, no new login, no copy-paste between a portfolio tool and an assistant. The data stays where it is governed and the assistant comes to it.
That is the whole pitch, and it is why we think MCP is the more interesting end of AI in finance software than another chat panel.