--- title: "MCP vs OpenAI Function Calling Design Philosophy" url: "https://atlan.com/know/ai-agent/mcp-vs-openai-function-calling-design-philosophy/" description: "Compare MCP and OpenAI function calling through interface control, foundation stewardship, portability, and the context enterprises need behind both." author: "Karthik Pasupathy" author_role: "Contributing Writer — AI Context & Agents" published: "2026-09-21" updated: "2026-09-21T00:00:00.000Z" --- --- Atlan sits beneath both interfaces as the Context Layer for AI, making definitions, lineage, ownership, and policy context available through MCP, A2A, SQL, and APIs. That governed context is what lets a team change interfaces, from function calling to MCP to whatever comes next, without losing the business meaning agents depend on. Below, we compare the two design bets: their architectures, foundation stewardship, openness tradeoffs, and the enterprise control decisions that follow from each. ### Which Agent Protocol Do You Need Give it what you're building, agent count, ownership, and handoff pattern. It returns which layer, function calling, MCP, or A2A, fits now. [Read the skill](/skills/agent-protocol-fit.md). *Paste into a new chat* ``` Use the skill at https://atlan.com/skills/agent-protocol-fit.md to check which agent protocol actually fits. Ask me for whatever it needs. ``` *Run once in a terminal* ``` curl -fsSL --create-dirs \ -o ~/.agents/skills/agent-protocol-fit/SKILL.md \ https://atlan.com/skills/agent-protocol-fit.md ``` *For an agent* ``` curl -fsSL https://atlan.com/skills/agent-protocol-fit.md ``` Human Agent ClaudeChatGPTGeminiCursorOther Copy .skp{margin:1.75rem 0;padding:1rem 1.125rem 1.125rem} .skp h3{margin:0 0 .375rem!important;font-size:20px!important;line-height:24px!important; font-family:var(--font-funnel-display)!important;font-weight:600!important;color:#2B2B39!important} .skp > p{margin:0 0 .875rem!important;font-size:14px!important;line-height:22px!important;color:#555572!important} .skp > p a{color:#2026D2;text-decoration:underline} .skp-box{margin-bottom:.75rem} .skp-p em{display:block;font-size:10px;font-weight:700;letter-spacing:.06em;text-transform:uppercase; color:#F34D77;font-style:normal;margin-bottom:.25rem} .skp-p > p{margin:0!important} #seo-layout article .skp .skp-p pre{margin:0!important;overflow-x:auto} #seo-layout article .skp .skp-p pre code{color:#2B2B39!important;font-size:12px!important;line-height:19px; white-space:pre-wrap;overflow-wrap:anywhere;background:none;padding:0; font-family:ui-monospace,SFMono-Regular,Menlo,monospace} .skp-p + .skp-p{margin-top:.625rem} .skp-cs{display:flex;flex-wrap:wrap;align-items:center;gap:.375rem} .skp-seg{display:inline-flex;flex:0 0 auto;border:1px solid #DDDDE3;border-radius:999px;overflow:hidden;background:#fff} .skp-m{min-height:32px;padding:.25rem .75rem;border:0;background:transparent;font-family:inherit;color:#77778E;cursor:pointer} .skp-m:hover{color:#2026D2} .skp-m.on{background:#2026D2;color:#fff} .skp-sep{flex:0 0 auto;width:1px;height:20px;background:#DDDDE3;margin:0 .25rem} .skp-tools{display:inline-flex;flex-wrap:wrap;gap:.375rem;min-width:0} .skp-cp{margin-left:auto;min-height:32px;padding:.25rem .75rem;border-radius:999px;background:#fff; font-family:inherit;color:#555572;cursor:pointer} .skp-cp:hover{border-color:#2026D2!important;color:#2026D2} .skp-cs .skp-c{display:inline-flex!important;width:auto;flex:0 0 auto;align-items:center;gap:.375rem; min-height:32px;padding:.25rem .625rem;border-radius:999px;background:#fff;font-family:inherit; color:#555572;cursor:pointer} .skp-cs .skp-c img{display:block!important;width:14px!important;height:14px!important; max-width:14px!important;flex:0 0 auto;opacity:.55;margin:0} .skp-c:hover img,.skp-c.on img{opacity:1} .skp-cs .skp-c:hover{border-color:#797DE4!important;color:#2026D2} .skp-cs .skp-c.on{border-color:#2026D2!important;background:#F4F4FD;color:#2026D2} .skp-agent .skp-tools,.skp-agent .skp-sep{display:none} (function(){ var p=document.querySelector('.skp[data-skill="agent-protocol-fit"]');if(!p)return; var panes=p.querySelectorAll('.skp-p'); function show(id){panes.forEach(function(x){x.hidden=x.dataset.skp!==id;});} function cur(){var a=p.querySelector('.skp-p:not([hidden]) pre code');return a?a.textContent:'';} show('prompt'); p.querySelectorAll('.skp-p em').forEach(function(e){ var par=e.parentElement; ((par.tagName==='P'&&par.textContent.trim()===e.textContent.trim())?par:e).hidden=true; }); p.querySelectorAll('.skp-c').forEach(function(b){ b.addEventListener('click',function(){ p.querySelectorAll('.skp-c').forEach(function(x){var on=x===b;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);}); show(b.dataset.skp); }); }); p.querySelectorAll('.skp-m').forEach(function(m){ m.addEventListener('click',function(){ var agent=m.dataset.skpMode==='agent'; p.classList.toggle('skp-agent',agent); p.querySelectorAll('.skp-m').forEach(function(x){var on=x===m;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);}); if(agent){show('agent');}else{var s=p.querySelector('.skp-c.on');show(s?s.dataset.skp:'prompt');} }); }); var c=p.querySelector('[data-skp-copy]'); c.addEventListener('click',function(){ navigator.clipboard.writeText(cur()).then(function(){ c.textContent='Copied';setTimeout(function(){c.textContent='Copy';},1600); }); }); })(); | Dimension | Function calling | MCP | | :---- | :---- | :---- | | Tool interaction | The model returns a function name and arguments; application code decides whether to execute them | Standardizes how clients discover and invoke tools exposed by servers | | Architecture | Operates within the model-application exchange | Adds a client-server interface; servers can run locally or remotely | | Reusability | OpenAI defines its own model-facing API format | Lets compatible applications reuse a shared server interface, cutting repeated integration work | | Interface control | OpenAI controls changes to its API | Evolves through an open contribution process; maintainers hold final authority | | Execution and security | Execution stays outside the model, under application control | Does not automatically make tools safe; still needs authorization and approval controls | --- ## What do the two companies’ interface bets reveal? MCP and function calling both help models use tools, but they standardize different parts of the interaction. With [OpenAI function calling](https://platform.openai.com/docs/guides/function-calling), the application supplies a function definition and JSON schema. The model returns structured arguments, while application code decides whether and how to execute them. The [Model Context Protocol](https://atlan.com/know/what-is-model-context-protocol/) standardizes the connection beyond that exchange. An MCP host creates clients that connect to local or remote servers. The shared contract defined by [MCP’s architecture](https://modelcontextprotocol.io/docs/learn/architecture) lets compatible applications discover server capabilities without the need for designing a different service interface for each application. Atlan sits behind either route as the Context Layer for AI. It makes definitions, lineage, ownership, and policy context available through MCP, A2A, SQL, and APIs. As this explanation of [how MCP delivers business context](https://atlan.com/know/mcp-delivers-business-context/) shows, MCP provides the connection while Atlan supplies governed context that can remain useful across models and interfaces. The mechanisms can also operate within a single workflow: OpenAI’s Responses API supports function tools and [remote MCP servers](https://developers.openai.com/api/docs/guides/tools-connectors-mcp). This reflects the broader value of [agent interoperability protocols](https://atlan.com/know/agent-interoperability-protocols/): reducing provider-specific integration work. OpenAI controls its API contract, while MCP’s maintainers govern the shared protocol through a public contribution process. But what actually led the team at Anthropic to create MCP? It was the challenge of how applications repeatedly connect to external systems, not simply how a model requests a tool. --- ## Why did Anthropic build a protocol instead of a bigger prompt? A bigger prompt can describe a tool, but it cannot standardize discovery, system connections, result exchange, or capability changes. In its [November 2024 announcement](https://www.anthropic.com/news/model-context-protocol), Anthropic said every new data source required a custom implementation. MCP instead defines a common client-server contract. A team [implementing an MCP server](https://atlan.com/know/mcp-server-implementation-guide/) can expose tools, resources, and prompts through shared methods, while the host controls their use. Consider an analyst assistant using [an MCP server for Snowflake](https://atlan.com/know/mcp/mcp-server-for-snowflake/) alongside [an MCP server for Salesforce](https://atlan.com/know/ai-agent/mcp-server-for-salesforce/). Each system still needs its own credentials, permissions, and business logic, but compatible clients can discover and invoke both through the same protocol without the need for custom integrations. This explains [why MCP matters for AI agents](https://atlan.com/know/mcp/why-mcp-matters-for-ai-agents/). Teams [building MCP servers for enterprise data](https://atlan.com/know/ai-agent/how-to-build-mcp-servers-for-enterprise-data/) can maintain each system integration separately from the model. MCP does not remove that work; it prevents teams from having to rebuild it for every model integration. --- ## Why did function calling make sense inside OpenAI’s API? Function calling turns a model’s proposed action into structured output that application code can inspect and use. In OpenAI’s [function-calling workflow](https://platform.openai.com/docs/guides/function-calling), the application includes function definitions and JSON schemas in its API request. The model can return a function name and arguments, but the application validates them, decides whether to execute the function, and sends back the result. Execution remains outside the model and under the application’s direct control. This fits existing application architectures. Teams retain credentials, business logic, and side effects in their code, while OpenAI defines the model-facing schema and tool-selection behavior. The underlying function can serve other models, although each provider may require an adapter. Function calling is therefore a model API feature, not a complete service-integration protocol. When it comes to [tool use in AI agents](https://atlan.com/know/ai-agent/ai-agent-tool-use/), the [agent harness](https://atlan.com/know/what-is-an-agent-harness/) manages the execution. So, the teams [building an AI agent harness](https://atlan.com/know/how-to-build-ai-agent-harness/) still own validation, retries, approvals, and errors. --- ## What does the architectural fork look like in practice? The architectural difference becomes clearest when a coding assistant and an analytics assistant both need the same data catalog. With function calling, each application supplies tool definitions within its model integration. The catalog service can be shared, but teams must design how applications discover and connect to it. With the [Model Context Protocol](https://modelcontextprotocol.io/), the catalog integration can be exposed via a single remote server. Each compatible host creates a client, discovers its capabilities, and uses the same protocol. As this explanation of [MCP’s architecture](https://atlan.com/know/ai-agent/mcp-architecture-deep-dive/) shows, clients and servers are logical roles, and servers can run locally or remotely. In a broader [AI agent architecture](https://atlan.com/know/ai-agent/ai-agent-architecture-explained/), MCP changes the integration layer, not the entire agent. An [agentic AI](https://atlan.com/know/what-is-agentic-ai/) system still needs orchestration and permissions, while [agent skills and MCP](https://atlan.com/know/ai-agent/ai-agent-skills/agent-skills-vs-mcp/) address guidance and connectivity separately. A shared interface then raises the question of who controls it. --- ## What did the Linux Foundation donation actually change? On December 9, 2025, Anthropic contributed MCP to the Agentic AI Foundation (AAIF), a Linux Foundation project, alongside contributions from Block and OpenAI. The [Linux Foundation announcement](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation) presented a neutral home for shared agent infrastructure. [GitHub’s account of the transition](https://github.blog/open-source/maintainers/mcp-joins-the-linux-foundation-what-this-means-for-developers-building-the-next-era-of-ai-tools-and-agents/) explains that participants gained a common venue for developing the protocol. MCP did not become a system where every participant has an equal vote. Its [published governance model](https://modelcontextprotocol.io/community/governance) gives lead maintainers final authority, while core maintainers steer the project and major changes are proposed via public Specification Enhancement Proposals. Roles belong to individuals; no company has a reserved seat. The donation also did not create MCP’s adoption. The project’s [November 2025 anniversary report](https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/) recorded close to 2,000 registry entries. With MCP, enterprises gained less dependence on one company’s roadmap and a clearer path to contribution, not freedom from compatibility, security, or implementation work. --- ## What does MCP’s openness cost, and what does it buy? Open-sourcing MCP gave vendors and enterprises a common target for building clients and servers. Its published specification, SDKs, and repositories expand supplier choice and allow a single server to support multiple compatible applications. That model also distributes responsibility. Also MCP’s [design principles](https://modelcontextprotocol.io/community/design-principles) favor stability because additions create compatibility obligations. Clients and servers may support different versions and optional capabilities, while MCP’s [security model](https://github.com/modelcontextprotocol/modelcontextprotocol/security) leaves server selection, access restrictions, and deployment review to developers and operators. Adopters must therefore test deployed combinations, plan upgrades, and review a broader supply chain. Function calling can contain some risk within one application. Teams can expose sensitive actions as narrow functions, keeping validation and execution in application code, while using MCP for reusable capabilities. The additional adapter makes this a selective control rather than a replacement for MCP. OpenAI supports remote MCP servers alongside function tools, with filtering, approvals, and deferred loading to limit actions and context use. Anthropic’s [code-execution analysis](https://www.anthropic.com/engineering/code-execution-with-mcp) describes the cost of loading many tool definitions and returning intermediate results through the model. These controls help, but enterprises still own server trust, compatibility, and data-access decisions. --- ## Why is protocol choice a governance decision before an engineering one? Protocol choice determines who changes an interface, publishes capabilities, authorizes access, and accepts compatibility risk. Those governance decisions come before implementation. Review where control sits before choosing the integration: | Governance question | Where control sits | Enterprise decision | | :---- | :---- | :---- | | Who changes the interface? | OpenAI controls its function-calling contract. MCP maintainers control the protocol. | Define supported versions and how changes are tested and adopted. | | Who exposes tools? | Application teams supply function definitions. MCP server owners publish capabilities, while hosts allow servers and tools. | Name tool owners and approve trusted sources. | | Who authorizes execution? | Function-calling applications decide whether to execute a request. MCP distributes controls across the host, server, and connected service. | Define identity, approval, logging, and revocation rules. | | What survives a change? | Neither interface makes business definitions, permissions, or evaluation cases portable on its own. | Retain context and tests outside the model integration. |   The governance surface grows with each protocol. [Google’s A2A protocol](https://atlan.com/know/google-a2a-protocol/) covers agent communication, while the [MCP and A2A distinction](https://atlan.com/know/mcp/mcp-vs-a2a-protocol/) separates collaboration from tool and context access. Teams [choosing among MCP, A2A, and ANP](https://atlan.com/know/mcp/how-to-choose-mcp-a2a-anp/) or [implementing A2A](https://atlan.com/know/mcp/a2a-protocol-implementation-guide/) must assign ownership across those interfaces. Moving from [single-agent to multi-agent systems](https://atlan.com/know/single-agent-vs-multi-agent-systems/) also requires explicit [coordination patterns](https://atlan.com/know/multi-agent-coordination-patterns/) for failures, approvals, and handoffs. The most durable control is ownership of the context behind these interfaces. [Context portability](https://atlan.com/know/ai-agent/context-portability/) requires business definitions, permissions, and evaluation cases to remain usable when a model or protocol changes. That belongs in the broader [context architecture for AI agents](https://atlan.com/know/context-architecture-for-ai-agents/). --- --- ## Where does Atlan sit when context must outlast the interface? Atlan sits below the interface choice. Its role is to keep business definitions, policies, lineage, ownership, and evidence reusable, regardless of whether an application accesses them through MCP, A2A, SQL, or an API. This is the practical test when comparing [agent context layer tools](https://atlan.com/know/ai-agent/agent-context-layer-tools-compared/): can the context survive a change in model, framework, or protocol? | Enterprise requirement | Atlan capability | Practical effect | | :---- | :---- | :---- | | Protocol-neutral access | Atlan describes its [Context Lakehouse](https://atlan.com/context-lakehouse/) as accessible through MCP, A2A, SQL, and REST or Graph APIs. | Teams can change how applications access context without rebuilding the underlying definitions and policies. | | Governed MCP delivery | [Atlan’s MCP server](https://atlan.com/know/what-is-atlan-mcp/) exposes governed asset search, lineage, and context updates. | It can support use cases such as [MCP for data lineage](https://atlan.com/know/mcp/mcp-for-data-lineage/), although [lineage-based root cause analysis](https://atlan.com/know/mcp/data-lineage-rca-with-mcp/) still depends on complete and current relationships. | | Context lifecycle control | The [Context Engineering Studio](https://atlan.com/context-engineering-studio/) describes a lifecycle for versioning, testing, reviewing, deploying, and observing context. | Traces and drift visibility help teams understand [how agent context changes over time](https://atlan.com/know/ai-agent/ai-agent-context/), rather than checking only whether an endpoint responds. |   This distinction also separates [an agent context layer from RAG](https://atlan.com/know/ai-agent/agent-context-layer-vs-rag/). Retrieving relevant content does not establish which definition is authoritative, whether a policy applies, or whether the supporting lineage remains current. The goal is a shared business language, not another transport format. A practical evaluation should test one real workflow against a provider or protocol change. If its definitions, permissions, lineage, and expected answers remain intact, the context has outlasted the interface. That test also helps diagnose [why AI agents fail in production](https://atlan.com/know/why-ai-agents-fail-in-production/). --- ## Real stories from real customers: Context that survives the interface "Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs." — Joe DosSantos, VP Enterprise Data & Analytics, Workday Watch Now "Atlan is our context operating system to cover every type of context in every system including our operational systems. For the first time we have a single source of truth for context." — Sridher Arumugham, Chief Data Analytics Officer, DigiKey Watch Now Workday names an MCP server directly; DigiKey names a single source of truth spanning every operational system. Neither one stopped at the interface as the finish line. Book a Demo --- ## FAQ ### 1. Is MCP open source, and who currently controls the specification? MCP publishes its code and specification under open licenses. Its governance remains hierarchical: maintainers oversee components, core maintainers steer the project, and lead maintainers hold final authority. The Linux Foundation provides an institutional home and must approve governance changes, but it does not replace the maintainer structure. ### 2. Why did Anthropic build a new protocol instead of extending its own tool-use API? Anthropic was addressing repeated application-to-system integration, not just model-tool selection. Extending its tool-use API could improve Claude’s model-facing contract, but it would not create a shared connection that other applications and services could implement. MCP instead defines a common client-server protocol that can operate across vendors. ### 3. Can OpenAI models use MCP, or is MCP limited to Claude and Anthropic tooling? OpenAI models can use remote MCP servers through the Responses API, so MCP is not limited to Claude or Anthropic tooling. OpenAI exposes MCP as a built-in tool type alongside function tools. Compatibility still depends on the selected model, transport, authentication, and server capabilities. ### 4. What changed when Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation in December 2025? The contribution moved MCP into the Agentic AI Foundation under the Linux Foundation, giving it a neutral institutional home and formal contribution structure. It did not replace MCP’s maintainer hierarchy, in which core maintainers steer the project and lead maintainers retain final authority. It also did not change the protocol’s mechanics or ownership of existing clients and servers. ### 5. Does MCP replace function calling, or does function calling still happen inside an MCP-enabled agent? MCP and function calling operate at different layers, so one does not inherently replace the other. In a combined system, a provider’s tool-calling mechanism can let the model select an action while the host sends the corresponding request to an MCP server. Other orchestration methods can also invoke MCP, so function calling is common but not required. ### 6. What does OpenAI gain by keeping function calling proprietary instead of adopting an open protocol? OpenAI does not have to choose between them because its Responses API supports both provider-defined function tools and remote MCP servers. Keeping its own function-calling contract gives OpenAI direct control over model-facing tool definitions, schema enforcement, and API evolution. MCP can then serve the separate role of providing shared connections to external services. ### 7. Is MCP's client-server design philosophically closer to the Language Server Protocol than to a typical REST API? MCP is closer in design ambition to the Language Server Protocol, and its specification explicitly identifies LSP as an inspiration. Both establish a shared client-server contract, allowing multiple applications to use the capabilities without a custom interface for each pairing. REST is an architectural style for network APIs and does not itself define MCP’s discovery, capability negotiation, or AI-specific primitives. ### 8. Does adopting an open protocol like MCP actually reduce vendor lock-in for an enterprise building AI agents, or just move the lock-in to a different layer? MCP reduces lock-in at the connection layer by making server capabilities reusable across compatible clients. It does not remove dependencies on hosting, authentication, model behavior, proprietary service semantics, or stored context. Lock-in falls materially only when business context, permissions, and evaluation cases can also move independently. --- --- ## Sources 1. [Introducing the Model Context Protocol, Anthropic](https://www.anthropic.com/news/model-context-protocol) 2. [Official documentation, Model Context Protocol](https://modelcontextprotocol.io/) 3. [Architecture overview, Model Context Protocol](https://modelcontextprotocol.io/docs/learn/architecture) 4. [Function calling, OpenAI](https://platform.openai.com/docs/guides/function-calling) 5. [MCP and Connectors, OpenAI](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) 6. [Agentic AI Foundation announcement, Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation) 7. [MCP joins the Linux Foundation, GitHub Blog](https://github.blog/open-source/maintainers/mcp-joins-the-linux-foundation-what-this-means-for-developers-building-the-next-era-of-ai-tools-and-agents/) 8. [Governance and stewardship, Model Context Protocol](https://modelcontextprotocol.io/community/governance) 9. [Design principles, Model Context Protocol](https://modelcontextprotocol.io/community/design-principles) 10. [Security policy and trust model, Model Context Protocol](https://github.com/modelcontextprotocol/modelcontextprotocol/security) 11. [One-year anniversary retrospective, Model Context Protocol](https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/) 12. [Code execution with MCP, Anthropic](https://www.anthropic.com/engineering/code-execution-with-mcp)