How we built a Model Context Protocol server for investment research

The Problem

Sabina Smith, an investor at Scale, had a question she needed answered before a partner meeting: which firms had co-invested in a company's recent round, and had any of them led deals we'd passed on?

It's the kind of question that sounds simple, but isn't. The answer requires pulling data from Pitchbook, cross-referencing against our Salesforce deal history, and reading through whatever notes the relevant partners left on those passed deals. It’s maybe 30 minutes of work if you know exactly where to look.

Multiply that across the number of times a day our investors need to pull, cross-reference, and synthesize from different internal data sources, and you have a meaningful chunk of our capacity going to retrieval rather than analysis.

This led us to build a Model Context Protocol (MCP) server, based on the open standard released by Anthropic that gives our AI agents structured, authenticated access to the data sources that matter for investment research. That includes company scores, funding history, founder backgrounds, consolidated and cleaned vendor data, Salesforce deal notes, and our own internal signal layers.

Our server sits between the AI agents and our data layer. The agent asks a question. If answering it requires data, the server retrieves it—from Snowflake, from Salesforce, from Pitchbook, from our internal scoring APIs—and returns it as clean, structured JSON. The agent then synthesizes an answer from the retrieved data.

Sabina's question now takes under a minute. She types it, the assistant pulls the investor list, cross-references it against deal history, reads the relevant notes, and returns a direct answer with the specifics, including which firms, which deals, what the notes said about why we passed.

The ROI

The most immediate impact has been on the research questions that used to require time to set up. Questions like "what's the scoring trajectory for companies in this market over the past 18 months" or "which of our portfolio companies have co-investors that overlap with this new deal" used to mean someone building a query, pulling data, and formatting it. Now they're conversational.

The deeper value is what it changes about how investors can spend their time. When retrieval and CRM maintenance are fast and low-friction, the questions you ask get more ambitious and the data you log back into the system gets more complete. You ask follow-ups. You test a thesis by pulling the data rather than making an assumption. The bottleneck shifts from "can I get to this data" to "what's the right question to ask," which is where investor judgment actually lives.

We've also started catching things we would have missed. Because the agents can systematically cross-reference data sources that wouldn't have been manually combined, it surfaces connections that don't show up in any single source.

How We Built It

Building an MCP server is not technically hard. Building one you'd trust with sensitive firm data required more thought.

The deeper problem is that the data driving our decisions isn't the data a general-purpose AI can see. Ask a language model about a portfolio company and it tells you what's publicly known—the funding rounds that made the news, the LinkedIn summaries, whatever ended up in training data. That's a starting point.

The data that actually matters—our scoring models, our CRM notes, years of deal flow, vendor data we've licensed, internal signal layers we've built—lives in our own systems. Connecting it to an agent used to mean either copying it into a chat window every time (tedious, unsustainable) or building a custom application tightly coupled to our data layer (expensive, inflexible, requires engineering work every time requirements change).

Authentication was the first constraint. Every request to our server requires OAuth via Google, with OIDC token validation on every request, not just at session start. The data the server can access includes non-public information about companies and founders, and it needed to be scoped to credentialed team members, not anyone who could reach the endpoint.

Rate limiting and logging came next. When you give an AI model tool access to your data layer, you lose some predictability about query patterns. A model reasoning through a complex research question might hit several endpoints in rapid succession. We added middleware that rate-limits by user and logs every tool call – what was called, when, by whom—so we can audit usage and catch anything unexpected. This has been tremendously valuable in allowing agents to inspect the logs and find opportunities to improve the tool designs.

The server returns structured responses, not raw database outputs. When the assistant asks for a company's scoring history, it gets back a clean JSON object with defined fields. Language models reason better over structured data, and tighter schemas reduce the surface area for misinterpretation.

We don’t want the agent to have to figure out which data source is the best for a given question, the MCP acts as a consolidation layer across our various systems and vendors to give the agents our best data for any given query without having to repeat a bunch of work every time. If we simply connected 12 vendor MCPs to Claude Cowork, every time a user asked a question, the model would burn tokens trying to figure out which to use, who’s data to trust, and how to go forward. That wastes users’ time and money.

The longer-term argument for building on a standard protocol rather than bespoke integrations is maintenance. Every custom integration is a liability. MCP servers are easier to version, test, and update. When we add a new data source, we write one integration and every AI application in our stack can use it immediately. Engineering debt compounds fast when you have a dozen AI workflows all accessing the same underlying data.

Lessons Learned

The hardest part wasn't the technical build, but rather deciding what the server should and shouldn't do. The temptation is to expose everything, but more tools creates more surface area for the model to make wrong choices. We've found it's better to have a smaller set of well-defined, well-tested tools than a comprehensive set of poorly-specified ones.

MCP tool calls differ from API calls in that they’re expensive, when a model is doing the call it takes time to produce the tokens for each call, to read the descriptions of each tool, etc. The user experience has been much better with fewer, larger tools than with lots of little API style tools.

Structured outputs matter more than we expected. Early versions of the server returned richer, more descriptive text from some endpoints. The model reasoned about it less reliably than it does over clean JSON with defined fields. Tightening the schemas took time but paid off immediately in answer quality.

Logging every tool call has been useful beyond security auditing. Reviewing what the model actually queries when answering different types of questions tells you a lot about where the prompting is unclear or where the data model could be better structured. We were able to quickly identify patterns where users were doing repeated calls over a tool, for example, and so could quickly add a batch mode that cut sessions down from an hour to minutes.

Where We Go From Here

The current server handles read and write on our core investment systems and as a gateway to our custom research agents. It’s used quite heavily by the whole investment team. The next frontiers for us here are better tooling around skill sharing and user-personalization (Skills-over-MCP is an exciting development here).