Project
A tooling suite
for an investment team
The problem was not a lack of data, but how scattered it was. One question meant three systems, two exports and an intermediate spreadsheet.
python api sql mcp server web interface
The starting point
Positions lived in one system, net asset values in another, benchmarks at a vendor, extra-financial data somewhere else again, and news nowhere in particular. Any question cutting across those paid for itself in manual work, with the error risk that implies and, worse, an answer nobody could reproduce exactly.
An access layer per domain
Rather than a monolithic warehouse, the architecture is an access layer split by business domain: portfolios, performance, market data, extra-financial, news. Each domain exposes a small number of functions in the language of the job, and takes care of knowing where the data actually sits.
The benefit is organisational more than technical: when a domain's source changes, one place moves, and nothing above it needs rewriting.
Two ways to use it
On top of that layer, a web interface provides the usual views: portfolios, performance, comparisons. But the part that changed habits most sits elsewhere: the same functions are exposed to LLM agents through an MCP server.
In practice, a question asked in plain language triggers calls to those functions and comes back with a sourced number, along with the path that produced it. The model picks the tools and writes, it never produces the numbers itself.
That principle is what makes the whole thing usable in a professional setting: every number shown is traceable to its source, and reproducible exactly.
What it changes
Questions that used to need half a day of preparation are now asked out loud. More importantly, the questions nobody asked, because the cost of the answer outweighed the value of knowing, are back within reach.