When engineers first encounter Model Context Protocol and function calling in the same conversation, the instinct is to treat them as competing choices. They are not. The two operate at different layers of the AI agent stack and solve genuinely different problems. Understanding the distinction is the difference between building agents that work in a demo and agents that hold up in a production enterprise environment.
Function calling is a model-level execution primitive. You declare what actions the model can invoke, the model decides when and how to call them, and your application code handles the actual execution. MCP: the Model Context Protocol: is a standardized open protocol for discovering and consuming external context, tools, and resources across systems. Think of it as the USB-C port for AI context: one standard interface, any tool on either end.
Neither protocol, on its own, solves the problem that actually matters for enterprise AI: making sure the context an agent retrieves is accurate, trusted, governed, and business-aware. That is the layer that lives behind the MCP endpoint, and it is the layer most teams underestimate until agents start returning stale definitions, missing lineage, or ungoverned data to downstream decisions.
| Function calling | MCP | |
|---|---|---|
| What it is | Model capability to invoke declared actions | Open protocol for tool and context discovery |
| Defined by | Application developer, per model | Protocol standard (open, model-agnostic) |
| Scope | Single application | Cross-system, multi-tool |
| Discovery | No: tools are hardcoded into the prompt | Yes: clients discover available tools at runtime |
| Portability | Not portable: rebuild per AI tool | Portable: one server, many AI clients |
| Governance | None built in | Depends on the server implementation |
| Best for | Tight, application-specific actions | Cross-system context delivery and tool reuse |
Is your data estate AI-agent ready?
Run the AI Agent Context Readiness assessment to find out whether your metadata foundation can support production AI agents: before you build.
Assess Your ReadinessWhat function calling actually does
Permalink to “What function calling actually does”Function calling is the mechanism by which a language model goes beyond text generation to take actions. You provide the model with a list of function schemas: structured definitions of what each function does, what parameters it accepts, and what it returns. At inference time, the model decides whether any user intent maps to a declared function. If it does, the model outputs a structured function call (name + arguments) rather than plain text. Your application code intercepts that call, executes the actual logic, and feeds the result back to the model as context for its final response.
The model itself never runs your code. It produces a structured description of what it wants to do. The execution happens entirely in your application.
What function calling is good at
Permalink to “What function calling is good at”Function calling excels at tightly scoped, application-specific actions where you control both the model and the execution environment. If you are building a BI copilot that needs to query a single database, trigger a refresh, or format a report, function calling is a clean, low-overhead way to expose those actions. The tool definitions live close to the code. The model’s behavior is predictable because the schema constrains what it can ask for.
It is also model-specific. OpenAI’s function calling schema differs from Anthropic’s tool use schema, which differs from Google Gemini’s function declarations. Building function calling for one model provider does not give you portability to another.
What function calling does not solve
Permalink to “What function calling does not solve”Function calling does not include a discovery mechanism. Every tool available to the model must be declared explicitly in the prompt at inference time. This creates a ceiling: as the number of available tools grows, you either inject a large tool list into every prompt (increasing cost and latency) or maintain complex logic to decide which tools to surface per request.
Function calling also has no built-in interoperability layer. If you want the same tools available in Claude, in Cursor, in a Slack bot, and in a custom agent, you rebuild the integration four times. Each rebuild is a maintenance surface and a potential inconsistency.
What MCP actually does
Permalink to “What MCP actually does”MCP: the Model Context Protocol: is an open protocol that standardizes how AI clients discover and consume tools, resources, and context from external systems. It was introduced by Anthropic in late 2024 and has since been adopted across the industry, with support in Claude, Cursor, Copilot Studio, Gemini, Snowflake Cortex, and a growing number of custom agent frameworks.
The core abstraction is a client-server model. An MCP server exposes capabilities: tools (actions), resources (data that can be read), and prompts (reusable instructions). An MCP client (the AI tool) connects to the server at runtime, queries what capabilities are available, and invokes them using the protocol’s standard message format. The connection is persistent and bidirectional, which means the server can also push updates to the client.
What MCP is good at
Permalink to “What MCP is good at”MCP solves the portability and discovery problems that function calling does not. A single MCP server can serve Claude, Cursor, a custom Python agent, and Copilot Studio simultaneously: each client speaks the same protocol. When you update the server’s tool definitions, every connected client sees the change immediately without a code deployment.
MCP also enables runtime discovery. Rather than declaring tools statically in the prompt, the AI client queries the MCP server at the start of a session to learn what tools are available, what they do, and how to invoke them. This makes it practical to expose large tool surfaces (dozens or hundreds of capabilities) without bloating the context window at every request.
For teams managing multiple AI tools across an enterprise: analyst agents, code assistants, BI copilots, data quality bots: MCP is the architecture that prevents every agent from building its own bespoke integration with every data source.
What MCP does not solve on its own
Permalink to “What MCP does not solve on its own”MCP standardizes the interface. It does not govern what is behind it. An MCP server that exposes stale metadata, incorrect business definitions, or ungoverned data will deliver those problems to every connected AI tool simultaneously. The protocol is only as trustworthy as the context layer it sits in front of.
This is why choosing the right MCP server implementation matters as much as the protocol itself. “Whoever owns the MCP endpoint owns the context layer”: and in an enterprise setting, that context layer needs authentication, audit logging, rate limiting, and policy enforcement built in.
Function calling (left) is a per-application, per-model execution primitive. MCP (right) is a standardized interface that lets any AI client discover and consume tools from external systems: with one server serving all AI tools simultaneously.
When to use function calling
Permalink to “When to use function calling”Function calling is the right choice when:
You control both sides of the interaction. If you own the application, the model choice, and the execution environment, function calling gives you precise control over what the model can and cannot do. There is no external protocol overhead, and the behavior is deterministic.
The tool surface is small and stable. Four to eight well-defined functions are easy to declare in the prompt. The model has a clear schema to work from, and you do not need discovery at runtime.
You are building for a specific model and do not need portability. If your application lives entirely within one model provider’s ecosystem: say, an OpenAI Assistants API deployment: function calling is native and well-supported. Portability is not yet a requirement.
Low-latency, application-embedded actions. When the function is tightly coupled to application state (e.g., “look up this user’s cart,” “retrieve the last query from session context”), function calling with local execution is faster than a round-trip to an external MCP server.
For teams exploring AI agent tool use patterns, function calling is often the first integration pattern encountered: and for contained applications, it stays the right choice. Teams building toward broader agentic AI workflows typically find they need MCP alongside it.
When to use MCP
Permalink to “When to use MCP”MCP is the right choice when:
Multiple AI tools need access to the same context or capability. Rather than building four separate integrations for Claude, Cursor, a custom agent, and Copilot Studio, an MCP server exposes capabilities once and serves all clients through the standard protocol.
You need runtime tool discovery. When the set of available tools is large, dynamic, or depends on the user’s context (permissions, team, data domain), MCP’s discovery mechanism lets the AI client query what is available rather than injecting a full list into every prompt.
You are building toward an enterprise multi-agent architecture. As described in context architecture for AI agents, production enterprise deployments involve multiple specialized agents collaborating. A shared MCP-based context layer prevents the context fragmentation that emerges when each agent builds its own integration.
The data source needs governance, audit, and access control. An MCP server can enforce authentication, apply rate limiting, log every tool invocation, and filter results by the caller’s permissions. Function calling offers none of this natively: your application code has to implement it per function.
You want to avoid rebuilding integrations as AI tooling evolves. The AI tool landscape changes faster than enterprise data infrastructure. An MCP server decouples the two: swap the AI client, keep the server. Emerging agent-to-agent protocols like Google’s A2A protocol reinforce this direction: the infrastructure investment is in the context layer, not in maintaining bespoke integrations for every new protocol.
For teams evaluating when to use MCP vs. a traditional API, the decision comes down to how many AI consumers need access, how dynamic the tool surface is, and whether you need governance at the delivery layer. Teams running Snowflake or Databricks environments can explore purpose-built options like the MCP server for Snowflake or the MCP server for Databricks as entry points.
How function calling and MCP work together
Permalink to “How function calling and MCP work together”The most common mental model error is assuming you pick one or the other. In production AI agent architectures, function calling and MCP operate at adjacent layers and are typically used together.
Here is the flow in a standard MCP-enabled agent:
- The AI client connects to the MCP server at session start. The server returns a list of available tools with their schemas: these are the capabilities the agent can invoke.
- The AI client adds those tool schemas to the model’s context. This is function calling: the model now has a set of declared functions it can invoke.
- The user sends a query. The model reasons about whether any tool should be called.
- If the model decides to call a tool, it outputs a structured function call (name + arguments): standard function calling behavior.
- The AI client sends that function call to the MCP server. The server executes it and returns the result.
- The result feeds back into the model’s context for the next reasoning step.
In this architecture, MCP handles the plumbing between AI clients and external systems. Function calling handles the model-level decision about which action to take and with what arguments. The enterprise context layer: what lives behind the MCP server: handles the quality, freshness, and governance of the data being returned.
The layer most architectures skip
Permalink to “The layer most architectures skip”Most architectural discussions about MCP focus on the protocol layer. The harder problem is what the MCP server exposes. If the underlying data catalog has incomplete lineage, stale definitions, ungoverned PII, or missing business context, the MCP server delivers those problems directly to every AI agent that connects to it.
This is the “context island” failure mode: each team spinning up an MCP server backed by whatever metadata they happen to own, without a shared semantic layer, without cross-domain lineage, without policy enforcement. GHX’s concern is representative: “We have all these different MCP servers getting spun up: we need a mechanism similar to shadow AI scanning.”
The fix is not a better protocol. It is a governed, unified context layer that the MCP server sits in front of.
Head-to-head comparison: MCP vs. function calling
Permalink to “Head-to-head comparison: MCP vs. function calling”| Dimension | Function calling | MCP |
|---|---|---|
| Architecture | Model invokes app-defined functions | Client-server protocol; server exposes capabilities |
| Scope | Single application | Cross-system, multi-client |
| Tool discovery | Static: declared in prompt | Dynamic: queried at runtime |
| Model portability | Not portable; schema varies by model | Portable; protocol is model-agnostic |
| Governance | None built in; developer responsibility | Server-level auth, audit, rate limiting |
| Enterprise fit | Good for contained, app-specific actions | Good for shared, cross-team capabilities |
| Context quality | Depends entirely on application code | Depends on what the MCP server exposes |
| Setup complexity | Low: schema declaration + execution handler | Higher: server deployment + protocol compliance |
| Works with | Any model supporting tool use | Claude, Cursor, Copilot Studio, Gemini, Snowflake Cortex, custom agents |
| Lineage and metadata | Not applicable | Depends on server: Atlan MCP provides full lineage and metadata |
| Maintenance as AI tools evolve | Rebuild per tool | Update server once; all clients benefit |
| Best for | Tightly coupled, application-embedded actions | Shared context delivery across multiple AI tools |
Neither row in this table has a clear winner across every dimension. Function calling wins on simplicity for contained use cases. MCP wins on portability, scalability, and governance for enterprise multi-agent deployments. The question is not which is better: it is which problem you are actually solving.
What enterprises get wrong about both
Permalink to “What enterprises get wrong about both”Treating the protocol as the product
Permalink to “Treating the protocol as the product”Engineering teams often spend weeks evaluating MCP vs. function calling as if the protocol choice determines the outcome. It does not. The outcome is determined by the quality of the context the agent retrieves. A well-implemented MCP server backed by a fragmented, ungoverned data catalog will produce worse agent behavior than a simple function calling integration backed by clean, well-defined metadata.
The protocol matters. The context layer matters more.
Building per-agent context islands
Permalink to “Building per-agent context islands”The most common enterprise failure pattern: every team building AI agents also builds its own metadata integration. The analyst agent has its own Snowflake connection. The BI copilot has its own semantic layer. The data quality bot queries its own metadata store. Each one is using different definitions of the same business terms, different lineage depths, different access policies.
The enterprise context layer approach inverts this: one governed context endpoint, exposed via MCP, that every agent queries. Same definitions, same lineage, same policies: regardless of which AI tool is asking. This applies whether the agent is running on a general-purpose LLM or a platform-specific AI like Snowflake Cortex.
Underestimating compliance requirements
Permalink to “Underestimating compliance requirements”Medtronic’s experience is instructive: “Compliance and legal are evaluating MCP risks right now from the corporate side.” CME Group asked specifically about OAuth support as an enterprise rollout requirement. These are not edge cases: they are the standard enterprise procurement conversation in 2026.
MCP servers that lack authentication, audit logging, and policy enforcement will not pass enterprise security review. Teams that build function calling integrations without considering how to govern them at scale hit the same wall when their single agent deployment becomes ten. Planning for the context API for AI layer from the start avoids painful rebuilds later.
Ignoring context window economics
Permalink to “Ignoring context window economics”MCP servers that expose everything consume significant context. Plaid’s perspective captures what many enterprise teams are learning: “Eventually most of our API will be consumed not from humans or services but from agents”: and those agents need to be efficient. Poorly designed MCP servers that inject large tool lists or return verbose unstructured responses at every call quickly become expensive. Design the context delivery layer for token efficiency, not just functional completeness.
Atlan as the governed MCP endpoint
Permalink to “Atlan as the governed MCP endpoint”Atlan’s MCP server is built on the premise that the context delivery layer and the governance layer should be the same system. Instead of exposing raw metadata without controls, Atlan MCP applies authentication, audit logging, rate limiting, and policy enforcement at the point of delivery: making every tool call governed by default.
The capabilities Atlan MCP exposes include:
- Asset search: natural language and structured queries across the full data catalog
- DSL queries: precise metadata retrieval using Atlan’s query language
- Lineage exploration: upstream and downstream lineage for any asset, enabling data lineage RCA with MCP and MCP-based lineage tracing
- Metadata updates: AI agents can write back to the catalog (governed, with audit trail)
- Policy enforcement: access control applied at the MCP layer, not just the database
This is what Workday means when they say “All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan’s MCP server.” The semantic work: building agreed business definitions, tagging assets, establishing lineage: does not need to be redone for AI. It surfaces directly through the MCP interface.
DigiKey’s framing is direct: Atlan is “a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models.” The MCP-connected data catalog is not a separate AI layer built on top of governance: it is governance made queryable by AI agents.
Atlan MCP works with Claude, ChatGPT, Cursor, Gemini, Copilot Studio, Snowflake Cortex, and custom agents: any MCP client connects to the same governed endpoint. For teams building with dbt, the MCP server for dbt brings the same governed context delivery to transformation workflows. For teams using agent harnesses to orchestrate multiple agents, what an agent harness is and choosing between vector stores and graph databases for agent memory are related decisions that shape the full context architecture. Teams evaluating the broader tooling landscape can also review best LLMOps platforms to understand how MCP fits into the operational layer.
Context for AI Analysts: See Atlan's Context Studio in Action
Context is what gets AI analysts to production. See how teams are building production-ready AI analysts with Atlan's Context Studio.
Save your SpotReal stories from real customers: MCP in the enterprise
Permalink to “Real stories from real customers: MCP in the enterprise”"We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products."
— Joe DosSantos, VP Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
The protocol matters less than the context behind it
Permalink to “The protocol matters less than the context behind it”MCP and function calling are both necessary parts of a production AI agent stack. Function calling gives models the mechanism to take actions. MCP gives the agent stack a standard way to discover and consume those actions from external systems. The protocol choice, properly made, fades into the background.
What does not fade into the background is the quality of the context those protocols deliver. An agent that queries stale metadata makes wrong recommendations. An agent that retrieves ungoverned data creates compliance exposure. An agent that uses inconsistent business definitions across tools produces inconsistent results that erode trust faster than any technical failure.
The enterprise teams getting AI agents to production are not the ones who picked the right protocol. They are the ones who built the governed context layer first: the semantic foundation that makes every tool call, regardless of protocol, return something accurate and trustworthy. That is the shared brain behind every agent. “Don’t let every agent build its own context island” is not a technical preference; it is the organizational decision that separates demo-quality AI from production-quality AI.
The metadata lakehouse concept captures the architectural direction: a single, governed store of business context that any AI tool can query through a standard interface. For teams asking how to build context for LLMs in the enterprise, the answer increasingly involves a governed MCP endpoint backed by a curated metadata layer, not isolated RAG pipelines or per-agent integrations. Understanding what RAG is and its limitations at scale helps clarify why MCP-based context delivery has emerged as the preferred pattern for multi-agent deployments; advanced RAG techniques can complement MCP but do not replace the need for governed metadata delivery. MCP is how that context surfaces to agents. Function calling is how agents act on it. Atlan is what makes the context worth acting on.
FAQs
Permalink to “FAQs”- What is the difference between MCP and function calling?
Function calling is a model-level capability that lets an LLM invoke specific actions defined by the application developer: you declare the tool schema, the model decides when to call it, and your code executes the function. MCP is a standardized open protocol for discovering and consuming external context, tools, and resources across systems, regardless of which model or AI tool you use. Function calling is an execution primitive. MCP is a discovery and delivery interface. They solve different problems and are typically used together.
- Do I need MCP if I already use function calling?
It depends on your scale. If you have one AI tool, one application, and a small stable tool surface, function calling alone may be sufficient. If you have multiple AI tools that need access to the same context, a dynamic tool surface, or governance requirements at the delivery layer, MCP becomes the right architectural choice. Most enterprise deployments that start with function calling add MCP as the number of AI tools grows.
- Is MCP replacing function calling?
No. They operate at different layers and are not in competition. Function calling is part of how models work internally: the model decides which action to invoke based on its schema. MCP is a transport and discovery protocol that sits between AI tools and external systems. Many production architectures use both: MCP delivers tools and context to the agent, and function calling is the mechanism by which the model invokes those tools.
- What is an MCP server?
An MCP server is a process that exposes tools, resources, and context to any MCP-compatible AI client using the Model Context Protocol standard. When an AI tool connects to an MCP server, it can discover what capabilities the server exposes, query them, and receive structured responses: without a custom integration for each tool. Atlan’s MCP server exposes capabilities like asset search, lineage exploration, metadata updates, and DSL queries from Atlan’s data catalog to any connected AI tool.
- What does Atlan’s MCP server do?
Atlan’s MCP server is the governed enterprise context endpoint that AI agents query at runtime. It exposes capabilities including asset search, DSL queries, lineage exploration, and metadata updates: all with authentication, audit logging, rate limiting, and policy enforcement applied. This means AI agents using Claude, Cursor, Copilot Studio, Snowflake Cortex, or a custom agent framework can all access the same trusted, governed metadata layer through a single MCP connection.
- How does function calling work with MCP?
In a typical production architecture, the MCP server delivers tool definitions and resources from external systems to the AI client. The AI client uses function calling to let the model decide which tool to invoke and with what arguments. The MCP server executes the tool and returns the result. MCP handles the plumbing between AI tools and external systems; function calling handles the model-level decision about which action to take.
- What is the enterprise risk of building per-agent context integrations?
Each agent building its own context integration creates isolated context islands: different metadata freshness, inconsistent business definitions, no shared lineage, and no centralized governance or audit trail. As more AI tools are deployed, the proliferation of bespoke integrations becomes a compliance and accuracy liability. A shared, governed context endpoint like Atlan’s MCP server eliminates this by providing one trusted source of context for every agent.
Sources
Permalink to “Sources”Model Context Protocol: Introduction, Anthropic
Function Calling: OpenAI Platform Documentation, OpenAI
Tool Use: Anthropic Documentation, Anthropic
MCP Specification: Official Protocol Documentation, Model Context Protocol
What Is Model Context Protocol? Atlan
Context Architecture for AI Agents, Atlan
AI Agent Tool Use Patterns, Atlan
Atlan Agent Toolkit: GitHub Repository, AtlanHQ
MCP Server Implementation Guide, Atlan
