MCP servers and the buy-side: what it changes, what it doesn't.

We launched INDATA Nexus in May 2026, and one of the pieces underneath it is a Model Context Protocol server — a read-only endpoint that lets external AI clients (Claude.ai, Claude Desktop, Cursor, Cowork, MCP Inspector, anything that speaks MCP) query INDATA portfolio data directly. I built and maintain it, and as far as I can tell, we are one of the very few buy-side technology vendors to have shipped one in production as of mid-2026.

I'd like to write down what publishing one actually changed, what it didn't, and the things I'd tell another vendor in an adjacent industry to think about before they ship one.

For readers who haven't looked at MCP yet

Skip this section if you have. MCP — the Model Context Protocol — is an open standard introduced by Anthropic in late 2024 that lets AI applications talk to data sources and tools through a uniform interface. It is roughly to AI clients what ODBC was to relational databases in the 1990s: an abstraction layer that lets the consumer and the producer change independently. A client can speak to a hundred different servers; a server can be consumed by a hundred different clients; neither needs to know the other's implementation.

You can build MCP servers that publish tools (capabilities the client can invoke — “send this email,” “create this issue”), resources (data the client can read), or prompts (workflow templates the client can offer to the user). Our server is in the tools-and-resources category: read-only access to holdings, transactions, performance and composite- membership data for INDATA Architect client portfolios.

What changed for clients

The most concrete change: a portfolio manager at one of our clients can now point Claude Desktop at our MCP server, authenticate with a pre-shared token, and ask questions of their own portfolio data inside a conversation alongside their other tools and documents. They didn't need to wait for INDATA to build a Slack integration or a Teams bot or a custom GPT or any of the dozen point-products that used to be necessary for “getting portfolio data into AI.” The client picked their AI tool; our server speaks the open protocol; the two find each other.

The second change is less visible but, I suspect, more consequential. We've always been able to serve our own AI features through our own UI. But the questions a portfolio manager asks inside their own AI workfloware different from the questions they ask inside a vendor product. They're more conversational, more cross-domain, more “please combine this portfolio data with my research notes and this earnings transcript and tell me what you think.” The MCP server lets that workflow exist without our needing to build it. We are a contributor to the client's AI surface, not the proprietor of it.

What didn't change

The underlying data-governance work is exactly the same. Our clients are regulated buy-side firms. The fact that a portfolio manager is now consuming the data through Claude Desktop instead of through our web UI does not change what data they're allowed to see, who's accountable for showing it, or how the audit trail needs to read at the end of the quarter. We still own authentication and authorization at the server. We still log every tool invocation. We still rate-limit, validate inputs, and enforce permissions row-by-row when the data is fetched. The protocol is a transport; the responsibility is unchanged.

The compliance conversations also did not get easier or harder. They got more concrete. “Is it safe to expose our data to AI?” is the wrong question. The right questions — what data, to which authenticated user, audited how, retained where — are the same questions that have existed for any client-data system since the 1990s. MCP just makes them more obviously answerable in a structured way.

Things I'd tell another vendor before shipping one

Be selective about what you expose.The protocol makes it easy to publish every tool you have. Don't. Each surface you expose is a contract you now own across all clients that consume it. Start with read-only data tools that have stable semantics; add action tools cautiously.

Treat the server like a public API.Even if it's gated behind authentication, multiple AI clients will consume it, often without your knowing in advance which. Version your tool schemas. Document units, time zones, NULL semantics, and edge cases inside the schema descriptions themselves — the LLM calling the tool is reading them. Our server returns period-return columns as percent units (0.02 means 0.02 percent, not 2 percent), and that nuance is in the docstring because we cannot trust every consuming client to know it from outside context.

Pay attention to response size.Tools that return a megabyte of JSON are useless to an LLM with a finite context window. Build response filtering at the server level — temporal filters, sort + limit, projection of fields the caller asked for. We have static filters (top-N most recent) and dynamic filters (the LLM extracts a date range from the user's question and we apply it). Both are essential; the static ones save you when the LLM forgets to be selective.

Make authentication boring.A pre-shared Bearer token that mirrors your existing API auth is good enough for the first six months. OAuth and dynamic client registration are real improvements, but they're also where MCP server projects bog down indefinitely. Ship the boring version; iterate from production usage.

Eat your own dogfood early. The first MCP client of your MCP server should be the AI agent you ship to your own users. If you build the server and your own agent against it at the same time, you find every awkward schema decision before any external client hits it. We did this from week one and it saved us multiple breaking-change reissues.

The wider point

Publishing an MCP server is not, in the end, a technical decision. It's a posture. It says: our customers will consume their own data through whatever AI surface they prefer, and our job is to make that connection work safely rather than to fight it. For a vendor whose competitive moat used to be “we have the interface customers see every day,” that's a real shift. The vendors who get there earliest set the schema conventions everyone else has to follow.

For the buy-side specifically, I think this is happening sooner than most of the industry has noticed. Asset managers, hedge funds and wealth-management platforms have been waiting for “the AI feature” from their software vendors for three years. The thing they want is not a feature. It's the ability to bring their own AI and have it work with their own data. MCP is how you give them that.