On this page
- What is an MCP server?
- What does "MCP" stand for?
- How does an MCP server work?
- MCP server vs. API: what is the difference?
- Why AI agents need MCP servers
- MCP servers for business data: the use case most guides miss
- MCP vs. RAG: a quick distinction
- What to look for in a data MCP server
- How is an MCP server secured?
- Frequently asked questions
- The bottom line
Your AI assistant sounds confident. It answers in complete sentences, cites figures, and explains its reasoning. The only problem: those figures came from data you pasted into the chat ten minutes ago, or from the model's training data, which ended months before your most recent quarter.
An MCP server is what changes that. It is the connection between an AI agent and live data — the layer that lets Claude, Cursor, or any AI tool reach into your database, query your business metrics, or trigger an action in an external system, on demand, without you lifting a clipboard.
What is an MCP server?#
An MCP server is a program that exposes data, tools, and actions to AI agents through the Model Context Protocol. The AI agent connects to it, discovers what it can access, and issues requests. The server handles the rest: querying the underlying system, enforcing permissions, and returning results in a format the model can use.
In practice it works like this. An AI agent running in Claude or Cursor wants to know your pipeline coverage for Q3. Without an MCP server, it cannot look that up — it only knows what is already in its context window. With an MCP server connected to your data warehouse, it sends a request to the server, which runs the query, and returns the answer directly into the agent's working memory.
In one sentence: an MCP server is the standardized interface that lets an AI agent reach beyond its context window and interact with live data, tools, and services — on its own, without a human copy-pasting or writing custom integration code.
The protocol was designed specifically for AI agents, not for humans or traditional software. That distinction matters: an MCP server does not expose raw HTTP endpoints for a developer to call in code. It exposes things an AI model can discover and use autonomously.
What does "MCP" stand for?#
MCP stands for Model Context Protocol. It is an open specification originally developed by Anthropic, released in late 2024, and now supported across the broader AI ecosystem — including Cursor, Windsurf, Microsoft Copilot, and dozens of open-source agent frameworks.
"Model context" describes exactly what it provides: context for the model. An AI model's intelligence is bounded by what is in its context window — the text, documents, and conversation history it can see. The protocol is the mechanism for expanding that window dynamically, by fetching exactly the information the agent needs at the moment it needs it.
How does an MCP server work?#
The architecture has three components: a host, a client, and a server.
- The host is the AI application the user interacts with — Claude Desktop, Cursor, or a custom agent you built. It manages one or more client connections.
- The client runs inside the host and maintains a one-to-one connection to a specific MCP server. Each tool or data source you connect gets its own client.
- The server is the program that exposes the actual capabilities — the tools, resources, and prompts an AI agent can use.
When you start a session, the client and server negotiate capabilities (each announces what it can offer), and the agent can begin using whatever is available. The transport layer for local servers is typically standard I/O — a subprocess the host spawns. Remote servers communicate over HTTP with Server-Sent Events, which allows for streaming responses.
The three things an MCP server can expose#
Every MCP server exposes capabilities through one or more of three primitives:
Tools are actions the agent can invoke — running a query, calling an API, submitting a form. A tool has a name, a description, and a schema for its inputs and outputs. The agent reads the description and decides whether to call the tool. For example: a run_metric_query tool that accepts a metric name and a date range and returns the result.
Resources are data the agent can read — documents, files, database records, live feeds. Unlike tools, resources are meant to be retrieved and placed into context, not acted on. For example: a configuration file, a record from a CRM, or a page from a knowledge base.
Prompts are reusable templates — predefined instructions or question formats the user or agent can invoke to trigger a specific behavior. For example: a "summarize this quarter's revenue trends" prompt that the agent knows how to fill in and execute against the data.
MCP server vs. API: what is the difference?#
The comparison comes up constantly because both connect software to external systems. They are genuinely different things, and the difference is worth understanding clearly.
| REST API | MCP server | |
|---|---|---|
| Designed for | Developers calling it from code | AI agents using it autonomously |
| Discovery | API docs you read; no self-description at runtime | Agent queries the server for its capability schema at runtime |
| Interaction model | Request-response, stateless per call | Stateful session with capability negotiation |
| What it exposes | HTTP endpoints (GET /users, POST /orders) | Tools, resources, and prompts |
| Who decides what to call | The developer writing the code | The agent, based on the task |
The practical consequence: connecting an AI agent to a REST API requires a developer to write integration code — parsing the response, deciding which endpoint to call for which question, handling errors. Connecting an agent to an MCP server requires configuring the server once. After that, the agent figures out what to call on its own.
This is why "MCP server vs. API" is slightly a false framing. Many MCP servers are thin wrappers around existing REST APIs or databases — the MCP layer is what makes those systems usable by an AI agent without custom integration work per tool.
Why AI agents need MCP servers#
An AI agent without external connections is like a brilliant analyst in a locked room. They can reason, synthesize, and explain — but only from the materials already in the room. Every question that requires live data forces you to carry that data in from outside: by pasting, uploading, or writing custom code to fetch it.
MCP removes that constraint. When an agent has access to an MCP server, it can:
- Ask a question that requires live data and retrieve it on the spot
- Chain multiple tool calls across a task — look up a number, compare it to last quarter, then check which segment drove the change
- Take actions in external systems, not just read from them
- Operate over time, with memory of what it retrieved earlier in the session
The reason MCP matters more than ad-hoc custom integrations is standardization. Without a common protocol, every AI agent needs a custom integration for every tool it might use, and every tool needs to know about every agent format. With MCP, any server that speaks the protocol works with any client that speaks it. One integration per tool; one client per agent.
MCP servers for business data: the use case most guides miss#
Most writing about MCP servers focuses on developer tools: GitHub repositories, code files, terminal commands, Slack messages. That is the first wave of adoption, and it is real. But it is not where the highest-value use case lives for most B2B SaaS companies.
The highest-value use case is giving an AI agent access to business data — revenue metrics, pipeline health, customer retention signals, product usage patterns. This is the data that drives decisions, and it lives in places an AI agent currently cannot reach: your data warehouse, your CRM, your billing system.
The problem with connecting an AI agent directly to a database is not the connection — MCP makes that technically straightforward. The problem is the layer above it.
If your AI agent can query your data warehouse directly, it will write its own SQL to answer your questions. Sometimes it guesses correctly. More often, it misses a filter, joins the wrong table, or defines "churn" differently than your finance team does — and returns a confident, specific, wrong answer. You have no way to tell which kind of answer you received.
This is where the semantic layer comes in. A semantic layer defines your business metrics once — the exact SQL, the correct joins, the approved filters — and serves them to whatever is reading your data. When your MCP server sits on top of a semantic layer instead of raw database tables, the AI agent does not write SQL. It requests a certified metric by name: "net revenue retention, last quarter, EMEA segment." The semantic layer returns the one correct calculation. The agent cannot hallucinate a definition it never had to invent.
The pattern that works: raw warehouse tables feed a governed semantic model, and an MCP server exposes that model to AI agents. The agent asks for metrics by name. The semantic layer enforces the definitions. The warehouse returns the data. No custom SQL, no invented business logic, no reconciliation meeting.
What you can actually ask an AI agent with a data MCP server#
With a well-structured data MCP server connected to a semantic layer, a RevOps analyst or data engineer can ask questions that previously required an analyst queue:
- "What is pipeline coverage for Q4 by segment, compared to this time last year?"
- "Which accounts had a significant drop in product usage in the last 30 days?"
- "What drove the change in net revenue retention from last quarter to this quarter?"
- "Show me the top 20 accounts by expansion opportunity, using our current scoring model."
Each of these questions requires multiple joins, specific metric definitions, and knowledge of your data model. A data MCP server with a semantic layer underneath handles that translation — the agent selects from defined metrics, not from raw columns.
This is what a modern data strategy for the AI era looks like in practice: not a dashboard refresh cycle, but an AI agent that can answer these questions on demand, with the same definitions your best analyst would use, whenever someone needs to know.
MCP vs. RAG: a quick distinction#
These two come up in the same conversations, and they are genuinely different.
RAG (Retrieval-Augmented Generation) works by taking a question, searching a vector index of documents, pulling the most relevant text chunks, and loading them into the model's context window before it answers. It is a text-retrieval technique — best for unstructured content like documentation, support tickets, or contracts.
MCP is a protocol for tool use and live data access. The agent does not search a vector index; it calls a specific tool or reads a specific resource. For structured data, MCP with a semantic layer is more accurate than RAG because you are retrieving an exact metric definition, not approximating from text.
In practice, many production systems use both: RAG for knowledge retrieval (documentation, policies, unstructured records) and MCP for live, structured data (metrics, operational data, actions). They are complementary, not competing.
What to look for in a data MCP server#
Not all MCP servers for data are the same. When you are connecting an AI agent to business-critical metrics, a few things matter beyond "does it work."
Governed metric definitions. If the MCP server exposes raw SQL access, every agent call is a potential metric definition problem. Look for servers that sit on top of a semantic layer — so the agent picks from certified metrics, not from tables.
Row-level and column-level access control. An AI agent inherits the permissions of the person using it. If access control is not enforced at the data layer, a user can ask the agent for data they should not see. Access rules defined on the semantic model propagate to every tool that queries through it, including the agent.
Predictable, auditable behavior. When an executive asks "where did this number come from?", you need an answer. A data MCP server that routes through a governed semantic model gives you one: the metric name, the definition version, the underlying query — all traceable. Getting your data ready for AI agents starts with that kind of auditability.
Transport and authentication. For production deployments, remote MCP servers use HTTP with Server-Sent Events. Confirm the server supports proper authentication — OAuth, API keys, or session tokens — before connecting it to sensitive data.
How is an MCP server secured?#
Connecting an AI agent to your business data raises an obvious question: what can it actually see, and who said it could? The answer comes down to identity. A well-built MCP server never holds a blanket key to everything. It acts on behalf of a specific person, and it is bound by that person's existing permissions.
There are two common ways that identity gets established: a shared secret token, or an OAuth flow.
Shared secret tokens#
The simplest approach is a static credential — an API key, a personal access token, or a bearer token that you paste into your client's configuration. The agent presents that token on every request, and the server trusts it.
This is the default for local MCP servers. The Model Context Protocol authorization spec expects local (stdio) servers to read credentials from the environment rather than run a login flow, so a token in a config file or environment variable is exactly the right tool. It is fast to set up, with no redirect screens or consent prompts.
The tradeoff is bluntness. A shared secret identifies a connection, not a person. One key maps to one fixed set of permissions, it tends to be long-lived, and it sits in plaintext wherever you stored it. If it leaks, whoever holds it inherits whatever that key could do, with no per-user attribution and a manual rotation to clean up. For a single developer wiring up a local tool, that is fine. For a team querying sensitive revenue data, it is not enough.
OAuth: acting on behalf of the user#
The better pattern for remote, multi-user servers is OAuth. Instead of pasting a secret, you click "Connect," authenticate with your normal login, and approve a consent screen that spells out exactly what the agent is allowed to do. The MCP server receives a short-lived, scoped access token — no long-lived secret ever lands in your config — and that grant can be refreshed or revoked at any time.
The MCP authorization spec is built on OAuth 2.1 for HTTP-based servers. The client requests access on behalf of the user, the server validates every token and confirms it was issued specifically for that server, and the flow uses PKCE so the authorization code cannot be intercepted and replayed. The upshot for you is simple: the agent inherits your identity. Every query it runs executes as you, so it can only ever reach data you were already allowed to see.
This is why identity matters more than any network firewall here. If the agent runs as the user, your existing access controls — roles, row-level and column-level security defined on the data — do all the work automatically. The agent cannot become a backdoor to data the person behind it could never open themselves.
This is the model RevOS uses. Rather than handing every user a static key, the RevOS MCP server uses a user-friendly OAuth flow: each person connects with their own identity, and the governed semantic layer enforces exactly the permissions they already have. The agent answers questions, but it answers them as you.
Risks worth understanding#
Even with clean authentication, a handful of MCP-specific risks are worth knowing before you connect a server to sensitive data:
- Token passthrough. The spec explicitly forbids an MCP server from forwarding the caller's token to an upstream API. If the server needs to call another service, it must obtain its own token for that service. Passing tokens through blurs the trust boundary and invites the next problem.
- The confused deputy. A server that proxies requests to other systems can be tricked into using its own privileges on behalf of an attacker. Strict redirect-URI validation, per-client consent, and verifying that a token was issued for this server are the standard mitigations.
- Prompt injection and tool poisoning. Malicious instructions hidden in a tool's description or in the data it returns can hijack the model. This is an LLM-trust problem rather than an auth problem, and it is mitigated by sanitizing inputs and pinning tool definitions so they cannot silently change after you approve them.
- Over-broad scopes. Request only the permissions the task needs. The principle of least privilege keeps the blast radius small if anything does go wrong.
- Audit logging. You need to know who asked the agent for what. A production MCP server should log authentication and every tool invocation to storage you can trust.
None of this is exotic. It is the same identity-and-access discipline you already apply to dashboards and BI tools — extended to the agent that now queries on your behalf.
Frequently asked questions#
What is the difference between an API and an MCP server?#
A REST API exposes HTTP endpoints designed for a developer to call from code. An MCP server exposes tools, resources, and prompts in a structure AI agents understand natively — so the model can discover what is available, decide what to call, and handle the result autonomously. APIs are for developers. MCP servers are for AI agents.
Is an MCP server a real server?#
Yes. An MCP server is a real process running on a machine — locally or in the cloud — communicating over a transport layer (standard I/O for local processes, HTTP with Server-Sent Events for remote ones). What makes it an MCP server is the protocol it speaks: the Model Context Protocol message format, capability negotiation, and the tools, resources, and prompts it exposes.
Why would I need an MCP server?#
When you want an AI agent to access live data or perform actions autonomously. Without one, the agent only knows what is in its context window. With an MCP server connected to your data sources, it can query your database, pull your business metrics, or trigger actions on demand. For data teams, this is how you stop manually copying numbers into chat and let the agent retrieve them itself.
Does ChatGPT use MCP?#
As of mid-2026, ChatGPT uses OpenAI's own tool-calling framework rather than MCP. Claude, Cursor, Windsurf, and many open-source agent frameworks have native MCP support. The underlying idea — a standard for AI tool use — is shared, but MCP as a specific open standard is most widely adopted in the Anthropic ecosystem and in open-source agent tooling.
What is MCP in agentic AI?#
In agentic AI, MCP is the communication layer between an agent and the tools and data it operates on. Agentic systems plan and act across multiple steps; MCP standardizes how they access external capabilities at each step. The agent discovers what tools are available, calls them as needed, and acts on the results — all through one protocol, without needing a custom integration for every tool.
What is an MCP server in simple terms?#
An MCP server is a plug-in slot for AI agents. Just as a USB port lets you plug multiple devices into a computer through one standard interface, an MCP server lets an AI agent connect to multiple data sources and tools through one standardized protocol. Instead of asking you to paste in a spreadsheet, the agent queries the server directly and gets the answer itself.
Can you host your own MCP server?#
Yes. The Model Context Protocol is an open standard with official SDKs in Python, TypeScript, and Java. You can build and host an MCP server for any data source or tool you control. Local servers run as a subprocess over standard I/O. Production servers run as HTTP services with Server-Sent Events. Many teams start with an open-source MCP server for a common tool and build custom ones for proprietary data.
What is the difference between MCP and RAG?#
RAG searches a vector index of documents and pulls relevant text into the model's context window. MCP is a protocol for live tool use and data access — the agent calls a specific tool or queries a specific resource. For unstructured content like documentation, RAG works well. For structured business data like metrics and operational records, MCP with a governed semantic layer is more accurate because the agent retrieves exact definitions instead of approximating from text.
How is an MCP server secured?#
Through identity. An MCP server authenticates the caller, usually with one of two mechanisms: a shared secret token (an API key or bearer token you configure, the norm for local servers), or an OAuth flow (where you log in and approve scopes, the norm for remote, multi-user servers). With OAuth the server acts on behalf of you specifically, so the agent inherits your permissions and can only reach data you are already allowed to see. The Model Context Protocol authorization spec is built on OAuth 2.1 for HTTP-based servers.
The bottom line#
An MCP server is the layer that closes the gap between an AI agent's intelligence and the live data it needs to act on. For development teams, it unlocks code-aware agents. For data teams, it unlocks something more significant: an AI that can answer business questions from your actual data, with the same metric definitions your analysts use, without a custom integration per tool.
The protocol is open, the ecosystem is growing fast, and the infrastructure already exists to build this — or to get it bundled. RevOS ships an MCP server as the top layer of its data platform, on top of a governed semantic model, so any MCP-compatible agent can connect and query your certified metrics by name from day one.
If you are evaluating what it takes to give AI agents access to your business data, start with the semantic layer — that is the governed layer your MCP server should expose. The MCP server is the interface. The semantic layer is what makes the answers trustworthy.
Frequently asked questions
- What is the difference between an API and an MCP server?
- A REST API exposes HTTP endpoints that a developer designs and a client calls directly. An MCP server exposes tools, resources, and prompts in a structure AI models understand natively — so the model can discover what is available, decide what to call, and handle the result, all without a human writing a custom integration for each interaction. APIs are designed for developers to call programmatically. MCP servers are designed for AI agents to use autonomously.
- Is an MCP server a real server?
- Yes. An MCP server is a real process that runs on a machine — locally or in the cloud — and communicates over a defined transport layer (standard I/O for local processes, HTTP with Server-Sent Events for remote ones). What makes it an MCP server is not the hosting but the protocol it speaks: the Model Context Protocol message format, capability negotiation handshake, and the three resource types (tools, resources, prompts) it can expose.
- Why would I need an MCP server?
- You need an MCP server when you want an AI agent to access live data or perform actions autonomously. Without one, the agent only knows what is in its context window. With an MCP server, it can query your database, read your documents, or pull your business metrics on demand. For data teams specifically, an MCP server is how you stop copy-pasting dashboards into chat and let the agent retrieve the numbers itself.
- Does ChatGPT use MCP?
- As of mid-2026, ChatGPT uses OpenAI's own tool-calling framework rather than MCP. Claude, Cursor, Windsurf, and many open-source agent frameworks have native MCP support. The underlying idea — a standard for AI tool use — is shared across providers, but MCP as a specific open standard is most widely adopted in the Anthropic ecosystem and in open-source agent tooling.
- What is MCP in agentic AI?
- In agentic AI, MCP (Model Context Protocol) is the communication layer between an AI agent and the world it operates in. An agentic system that plans and acts across multiple steps needs a reliable way to access tools, read live data, and trigger actions. MCP standardizes that interface so the agent does not need a custom integration for every tool. The agent discovers what tools are available, calls them as needed, and acts on the results — all through one protocol.
- What is an MCP server in simple terms?
- An MCP server is a plug-in slot for AI agents. Just as a USB port lets you plug multiple devices into a computer through one standard interface, an MCP server lets an AI agent connect to multiple data sources and tools through one standardized protocol. Instead of asking you to paste in a spreadsheet, the agent queries the server directly and gets the answer itself.
- Can you host your own MCP server?
- Yes. The Model Context Protocol is an open standard with official SDKs in Python, TypeScript, and Java. You can build and host an MCP server for any data source or tool you control. Local servers typically run as a subprocess over standard I/O. Production servers run as HTTP services with Server-Sent Events for streaming. Many teams start with an open-source MCP server for a common tool and build custom ones for proprietary data.
- What is the difference between MCP and RAG?
- RAG (Retrieval-Augmented Generation) searches a vector index of documents and pulls relevant text into the model's context window. MCP is a protocol for live tool use and data access — the agent calls a specific tool or reads a specific resource. For unstructured content like documentation and support tickets, RAG works well. For structured business data like metrics and operational records, MCP with a governed semantic layer is more accurate because the agent retrieves exact definitions instead of approximating from text.
- How is an MCP server secured?
- Through identity. An MCP server authenticates the caller, usually with a shared secret token (an API key or bearer token you configure, the norm for local servers) or an OAuth flow (where you log in and approve scopes, the norm for remote, multi-user servers). With OAuth the server acts on behalf of you specifically, so the agent inherits your permissions and can only reach data you are already allowed to see. The Model Context Protocol authorization spec is built on OAuth 2.1 for HTTP-based servers.
Read more about revenue operations, growth strategies, and metrics in our blog and follow us on LinkedIn and Youtube.
All articles