This post compares Dakota's MCP Server and API, two ways to access data from Dakota Marketplace, the global private markets intelligence platform used by thousands of investment professionals to research LPs, GPs, and private companies. Built by fundraisers for fundraisers, Dakota Marketplace delivers complete, accurate, and daily-updated intelligence across every allocator channel, from family offices and RIAs to sovereign wealth funds and public pensions. Learn More | Book a Demo
The short answer is no, APIs aren't going anywhere.
In fact, every Model Context Protocol (MCP) query is, behind the scenes, an API call. MCP is a new layer on top of APIs, not a replacement for them.
This post covers why APIs remain the foundation of nearly every modern data integration, what APIs do that MCPs can't, and how investment teams should think about both as part of the same tech stack.
Why This Question Comes Up
Anthropic introduced the Model Context Protocol (MCP) in late 2024, and it has gotten a lot of attention since. The shift it introduces is real: anyone on a team can connect Claude, ChatGPT, Gemini, or any compatible AI assistant to an MCP server and start asking questions in plain English. No code required.
That's a meaningful change in how non-technical users access live data. It's reasonable to wonder whether the older, code-based approach to integration, the API, is now legacy.
It isn't. Understanding why requires understanding what an MCP server actually does under the hood.
APIs Are the Foundation, Not the Old Way
An MCP server does not connect to data directly. It connects to data through an API. When a fundraiser opens Claude and asks "show me all endowments in the Northeast that invest in private equity," the AI assistant interprets the natural-language question, formulates a structured query, and sends that query through an MCP server that calls the underlying API. The API queries the database, returns the data, and the AI assistant formats the answer back to the user.
The MCP layer adds the natural-language interpretation. The API does the actual work of moving data between systems.
This isn't a temporary architecture; it's the design. Every MCP server, regardless of which data source it sits on top of, requires an API underneath. There is no MCP without an API. The two technologies aren't competitive, they're layered.
To see how an API or MCP would work with your team's stack, book a demo of Dakota Marketplace.
What APIs Do That MCPs Don't
APIs cover an entire category of use cases that MCPs aren't designed for.
- Real-time CRM integrations. When Dakota Marketplace data flows into Salesforce, HubSpot, Backstop, DealCloud, Microsoft Dynamics, Dynamo, or Snowflake in real time, an API is what's doing it. These integrations push data on a schedule, on a trigger, or continuously, not on a per-query basis. An MCP server, which waits for a natural-language question, doesn't fit that pattern.
- Live dashboards. A sales operations team building a custom dashboard that shows Marketplace updates as they happen needs an API. The dashboard polls the data, refreshes on a cadence, and displays results to many users at once. No natural-language interface required.
- Custom alerts. When a specific record, firm, or data point changes, an alert needs to fire automatically. That's a programmatic workflow running continuously in the background. APIs handle it. MCPs don't.
- Bulk and scheduled workflows. Pulling 50,000 records overnight, transforming them, and loading them into a data warehouse is an API job. The volume, the schedule, and the transformation logic all belong on the API side.
- Custom internal tools. Every proprietary platform built in-house at an investment firm, from pricing systems to CRM extensions to portfolio analytics, connects to outside data through APIs. That's where engineering teams have full control over how data is shaped, when it's pulled, and where it lands.
For any of these use cases, the API is the right tool. It isn't just still useful; it's the only practical option.
What MCPs Add
MCPs make one specific thing easier: natural-language queries from inside an AI assistant. A fundraiser who doesn't write code can now ask Claude or ChatGPT a question about allocator data and get an answer in seconds. That's a real shift for non-technical users.
But it's a single use case, important but specific. It doesn't displace the programmatic, scheduled, real-time work that APIs handle every day. That's why the question "are APIs going away" gets the answer it gets.
Layered, Not Replacing
The right mental model is layers. The API is the plumbing. The MCP is the interface for one type of user. The two don't compete; they coexist, and most investment firms will use both.
Technical teams will keep using APIs to build the integrations, dashboards, and workflows that move data programmatically. Fundraisers and sales teams will use MCP-connected AI assistants for ad-hoc research and natural-language queries. Both groups pull from the same data, governed by the same permissions, with no conflict between the two paths.
The question isn't API or MCP. It's how to use each one where it does its best work.
What This Means for Your Tech Stack
If your team already has a Dakota API integration in place, feeding data into Salesforce, into a custom dashboard, or into internal pricing and research tools, that integration is not legacy. It's still doing the most important work. Adding MCP doesn't change what the API is doing; it just gives a different group of users a different way to access the same data.
If your team is just starting to think about how to bring Dakota data into its workflow, the answer isn't to skip APIs and go straight to MCP. The answer is to decide which problem you're solving. For programmatic, scheduled, integrated workflows, the API is right. For ad-hoc, natural-language queries inside an AI tool, the MCP is right. For most teams running both kinds of workflows, APIs remain a core part of any modern investment firm's tech stack.
To see how both paths work with your team's stack, book a demo of Dakota Marketplace.
