In March 2026, Dakota launched an MCP server for Dakota Marketplace, its institutional fundraising database. The connector is now live in both the Claude and ChatGPT directories, and it works with Cursor and any other MCP-compatible client. Users sign in once with their existing Dakota credentials and start asking questions in plain English — no API keys, no integration code.
It is one of the cleanest public examples we have seen of the Model Context Protocol done right: a governed gateway that turns a Salesforce-based data product into something any AI assistant can query safely.
This guide breaks down how it works — for two audiences. First, investment and fundraising teams who use Dakota Marketplace and want AI access to it. Second, any company with valuable data in Salesforce wondering what an MCP server could look like for them. To be clear: Vantage Point did not build Dakota's server. We are analyzing a public architecture as practitioners, because it is a model worth studying.
The Dakota Marketplace MCP server is a governed gateway that lets AI assistants like Claude and ChatGPT query Dakota's institutional fundraising database — which runs on a Salesforce org — in plain English. It matters for fundraising teams who want conversational access to allocator and fund manager data, and for any business deciding how to expose its own Salesforce data to AI agents without losing security control. Vantage Point helps firms deploy Claude safely with Salesforce and CRM data and design governed MCP integrations using the same patterns.
The Dakota Marketplace MCP server is the software layer that lets AI agents query Dakota Marketplace, an institutional fundraising database for private markets. The database covers thousands of allocators — public pensions, endowments, foundations, family offices, sovereign wealth funds, and insurers — plus GP profiles, funds, contacts, and transactions, refreshed daily. The entire product runs on a Salesforce org.
In March 2026, Dakota built the server on Anthropic's open Model Context Protocol, the standard that defines how AI clients discover and call external tools. Dakota frames the difference well in its MCP launch report: an API answers your question; an MCP server lets an AI agent ask the right questions and know what to do with the answers.
If MCP itself is new to you, start with our explainer on what the Model Context Protocol is and how it works, then come back — this post is about what a production-grade implementation looks like.
Before the MCP server, getting answers out of Dakota Marketplace meant logging into the platform or Salesforce, building filters, and exporting lists. Useful, but manual.
Now the workflow is conversational. A salesperson can ask Claude or ChatGPT: "Find private equity fund managers in New York with over $1B AUM." The agent picks the right tool, runs a live, permission-scoped query against Dakota's Salesforce org, and returns analysis — not raw rows. In the same conversation, the user can ask the agent to draft outreach emails or update their CRM.
The key word is live. The agent is not working from a stale export or a training-data snapshot. Every answer comes from a real-time query the user is entitled to run. We covered the platform itself in our Dakota Marketplace for Salesforce review; the MCP server is what makes that data conversational.
The system has four layers, each with a clear job:
| Layer | Technology | What It Does |
|---|---|---|
| AI client | Claude, ChatGPT, Cursor, any MCP client | Interprets the user's question and selects the right tool |
| MCP server | Node.js + Express | Tool routing, query building, session management |
| API layer | Salesforce REST + Composite APIs | Executes SOQL/SOSL queries under the user's own credentials |
| Data source | Dakota Marketplace Salesforce org | Allocator, fund manager, fund, and contact data, refreshed daily |
Alongside the request path, Redis handles three jobs: session storage, response caching, and rate limiting. Authentication runs through a Salesforce Connected App using OAuth 2.0 with PKCE.
What makes this architecture instructive is its restraint. There is no data warehouse copy, no nightly sync, no separate permission system to maintain. The MCP server is a thin, governed gateway in front of the Salesforce org that already holds the data and already knows who is allowed to see what.
This is the part most worth studying. The Dakota MCP server uses per-user execution with no shared service account:
cache:{user}:{tool}:{query}), preventing any cross-customer data leakage.The authentication flow works in four steps:
dakotanetworks.my.site.com.Why does this matter beyond Dakota? Because the most common enterprise AI security mistake is the opposite pattern: a shared service account with broad access, fronted by application-level filtering that has to be rebuilt and re-audited constantly. Per-user execution pushes authorization down to the platform that already enforces it. If your team is evaluating AI access to regulated or entitlement-based data, this is the pattern to insist on — and it is central to how we approach compliance and security for CRM and AI projects.
The server exposes eight tools. The AI agent reads their descriptions and decides which to call based on the user's question:
| Tool | What It Does |
|---|---|
search_fund_managers |
Find GPs by criteria such as strategy, location, or AUM |
get_fund_manager |
Pull a full profile for one fund manager |
search_allocators |
Find LPs — pensions, endowments, foundations, family offices, and more |
get_allocator |
Pull a full profile for one allocator |
search_funds |
Find funds by criteria |
get_fund |
Pull details for one fund |
get_contacts |
Retrieve contacts at a firm |
search_marketplace |
Free-text search across the database (SOSL) |
Notice the design: a small set of focused tools, in matched search/get pairs, plus one free-text fallback. Not fifty endpoints — eight tools an agent can reliably choose between. Good MCP tool design looks more like a well-organized menu than a full API surface.
Three operational guardrails stand out from Dakota's technical documentation:
That last point deserves emphasis for anyone budgeting an integration roadmap. Traditional point-to-point integrations carry a permanent maintenance tax. A well-described MCP tool layer shifts some of that burden to the agent's ability to adapt.
Setup for an existing Dakota Marketplace subscriber takes three steps:
There are no API keys to generate, no integration code to write, and no IT project to schedule. Entitlements come along automatically because the server runs every query as you.
Here is the second reason this architecture matters: Dakota Marketplace is, at its core, a Salesforce org with valuable data in it. So is your CRM.
If your company has data that customers, partners, or your own teams would pay to query conversationally — product catalogs, account intelligence, service histories, research, inventory — the Dakota pattern is a credible blueprint:
The hard parts are rarely the protocol. They are data quality, tool design, entitlement modeling, and governance — deciding what an agent should be able to see and do on behalf of each user. That work sits squarely in CRM and integration strategy, which is where our system integration and data migration services come in.
If your team is evaluating how MCP applies to Salesforce, Claude, or your broader CRM and integration strategy, Vantage Point can help assess the right next step and build a practical implementation plan.
Vantage Point is a boutique, senior-led consulting partner focused on Salesforce, HubSpot, and the AI layer now forming around them. For teams looking at the Dakota pattern and asking "what would this look like for us," we help with:
If you want a practical assessment of what an MCP integration could look like for your Salesforce or HubSpot data, contact Vantage Point to start the conversation.
It is a gateway built on Anthropic's Model Context Protocol that lets AI assistants like Claude and ChatGPT query Dakota Marketplace, an institutional fundraising database that runs on a Salesforce org. Dakota launched it in March 2026, and the connector is available in both the Claude and ChatGPT directories.
No. Existing Dakota Marketplace subscribers find the connector in the Claude or ChatGPT directory, sign in once with their existing Dakota credentials, and start asking questions in plain English. There are no API keys to manage and no integration code to write.
Every query runs under the individual user's own OAuth token — there is no shared service account. Salesforce sharing rules and field-level security are enforced natively, so each user sees exactly what their subscription entitles them to, and cached responses are keyed per user to prevent cross-customer leakage.
The connector is live in both the Claude and ChatGPT directories, and it also works with Cursor and any other MCP-compatible client. Because MCP is an open protocol, new clients that support it can connect without Dakota building separate integrations for each one.
An API returns data when a developer writes code to call it; an MCP server describes its tools so an AI agent can decide which to call, run the query, and interpret the results in conversation. As Dakota puts it, an API answers your question, while an MCP server lets an AI agent ask the right questions and know what to do with the answers.
Standard-tier users get 100 requests per hour and premium users get 500, enforced with a sliding window in Redis. When a user hits the limit, the agent receives retry guidance instead of failing silently, and short-lived caching (120 seconds for searches, 300 for profiles) reduces repeat calls.
Yes — the Dakota architecture is a practical blueprint: a thin Node.js gateway in front of Salesforce REST APIs, per-user OAuth through a Connected App, a small set of well-described tools, and Redis for sessions, caching, and rate limits. The harder work is data quality, tool design, and entitlement governance, which is where a consulting partner like Vantage Point typically adds the most value.
No. Every tool call executes as the authenticated user, so the agent can only retrieve records and fields that user's subscription and Salesforce permissions allow. The agent has no privileged backdoor — it is bound by the same entitlements as the person asking.