MCP vs Function Calling vs OpenAI Plugins: AI Agent Tool Integration Architectures Compared

Function calling, MCP, and OpenAI Plugins solve different layers of the AI-agent tool stack. Function calling is how a model expresses what it wants to do; MCP is how those tool requests are discovered and executed across providers; OpenAI Plugins is a deprecated ChatGPT-only manifest format now superseded by GPTs/Actions and MCP for cross-provider workflows.

TL;DR

Function calling is the per-LLM structured-output mechanism (OpenAI tools, Anthropic tool_use, Gemini function_declarations) that lets a model emit a JSON tool request inline with its reply.
MCP (Model Context Protocol) is an open Anthropic-led standard that decouples tools from agents: a single MCP server can expose tools, prompts, and resources to any MCP-aware client (Claude, Cursor, Windsurf, ChatGPT, custom agents).
OpenAI Plugins were a 2023-era ChatGPT-only manifest mechanism. OpenAI deprecated Plugins in early 2024 in favor of GPTs/Actions and now interoperates with MCP, so new builds should not target the Plugins surface.

Quick verdict

Building one app with one provider? Use function calling.
Building tools that should work across multiple AI clients (Claude, ChatGPT, Cursor, custom agents)? Use MCP (which still uses function calling under the hood at the model boundary).
Targeting only the ChatGPT consumer surface with a remote API? Use a GPT with Actions, not Plugins. Plugins is legacy.

Side-by-side comparison

Dimension	Function calling	MCP	OpenAI Plugins (legacy)
Layer	Inference boundary (model ↔ host app)	Transport + discovery (host app ↔ tools)	ChatGPT runtime ↔ third-party API
Standardization	Per-provider (OpenAI, Anthropic, Google)	Open spec, multi-vendor	OpenAI proprietary
Discovery	You hand-pass tool schemas every call	Server advertises tools, prompts, resources	ai-plugin.json manifest + OpenAPI
Reuse across models	Re-implement per provider	Write once, run with any MCP client	None — ChatGPT only
State / streaming	Stateless per call	Long-lived sessions, streaming, sampling	Stateless HTTP
Status (2026)	Standard everywhere	Production, growing client coverage	Deprecated; superseded by GPTs/Actions

Function calling: the structured-output contract

Function calling, sometimes called tool calling, is the mechanism every major frontier model now exposes for emitting a typed action request instead of free-form text. The host application:

Sends the model a list of available tools (name, description, JSON Schema for arguments).
Receives back either an assistant message or a tool call payload ({ "name": "search", "arguments": { "q": "..." } }).
Executes the tool itself.
Feeds the tool result back into the next model turn.

Function calling is what the model wants to do. The execution, retries, auth, observability, rate-limits, and side-effects all live in your application code. Each provider ships its own dialect — OpenAI's tools array, Anthropic's tool_use blocks, Gemini's function_declarations, Mistral's tools — but the underlying pattern is identical.

Strengths.

Lowest possible latency: it is just one extra round-trip in the same chat completion.
Full control over execution, retry, and logging.
No new infrastructure: any HTTP backend works.

Weaknesses.

Vendor-specific schema dialects mean you ship N integrations for N providers.
Tool catalogue is duplicated in every app that wants to use it.
No native discovery: the host always has to know which tools to register.

MCP: a tool plane for agents

The Model Context Protocol, introduced by Anthropic in late 2024 and widely adopted across IDEs and agent runtimes through 2025-2026, standardizes the channel between an AI host and the tools it uses. An MCP server exposes three primitives — tools (callable functions), resources (read-only context like files or rows), and prompts (named, parameterized prompt templates). An MCP client (Claude Desktop, Cursor, Windsurf, ChatGPT desktop with MCP, custom agents) connects to one or more servers over stdio or HTTP/SSE and surfaces those primitives to the model.

Crucially, MCP does not replace function calling — it sits above it. When the host turns and asks the model to act, it still uses the model's native tool-calling format. MCP just made sure the host already had the right tool schemas, descriptions, and execution endpoints.

Strengths.

Write a server once, get tool support across every MCP-aware client.
First-class discovery: list tools, read resources, run prompts — all without changing agent code.
Sessions are long-lived, so servers can stream, paginate, and even ask the model for sampling.
Aligns with how teams actually want to operate tools: governed, auditable, reusable services.

Weaknesses.

Adds a transport layer with its own auth, lifecycle, and observability concerns.
Maturity varies by client; not every host supports every primitive yet.
Local stdio servers can be hard to operate at scale; remote HTTP servers need their own gateway story.

OpenAI Plugins: why it is legacy

OpenAI Plugins launched in 2023 to let third parties expose APIs directly to ChatGPT users via an ai-plugin.json manifest plus an OpenAPI document. ChatGPT would parse the manifest, route eligible queries to the plugin, and stream responses back to the user.

OpenAI deprecated the Plugins store in early 2024 in favor of GPTs (custom assistants) with Actions (OpenAPI-defined tool calls scoped to a single GPT). For cross-client and developer workflows, OpenAI has since added MCP support inside ChatGPT and the Responses API. The result for 2026:

New consumer-facing ChatGPT integrations should be GPTs + Actions, not Plugins.
New cross-provider tool services should be MCP servers.
Existing Plugin manifests still resolve in some surfaces, but they receive no new features and should be migrated.

When to use which

Use function calling alone when the entire stack is one model from one provider, the tool catalogue is small (≤ 5-10), and there is no reuse across teams or clients. Internal scripts, vertical agents, and tightly scoped chatbots fit here.
Use MCP when more than one client must hit the same tools, when documentation/internal-data access is the goal, or when you want a single audit/observability plane across agents. Any docs, devtools, knowledge-base, or workflow-automation server should default to MCP today.
Use OpenAI GPTs + Actions (not Plugins) when the only target is the consumer ChatGPT surface and the integration has to live inside the GPT store.
Combine MCP + function calling in production: MCP for tool delivery and governance, native function calling for the actual model boundary. This is the dominant 2026 pattern.

Common misconceptions

"MCP replaces function calling." It doesn't. Hosts still use the model's tool-calling API; MCP just supplies the tools.
"OpenAI Plugins are the same as OpenAI tools." They are not. Plugins is a deprecated runtime; tools/function calling is a live API surface.
"Use MCP only if you use Claude." Claude shipped first, but Cursor, Windsurf, ChatGPT, and dozens of custom hosts speak MCP today.
"MCP is just RPC over HTTP." It is a session-oriented protocol with discovery, sampling, streaming, and prompt primitives — not a thin RPC.

How to apply this in a documentation publisher's stack

If you are running a docs/GEO content operation:

Wrap your search index, page loader, and analytics as one MCP server. Every internal agent (drafting, audit, QA) calls the same server.
Use native function calling for tightly scoped per-agent tools (formatters, validators) where the cross-team reuse story is weak.
Treat anything you would have built as an OpenAI Plugin as either an MCP server (if other teams or clients should use it) or a GPT Action (if it lives only inside one consumer-facing assistant).
Document each MCP server with an agent sandbox documentation spec so downstream agents understand isolation, auth, and rate-limit behavior.

FAQ

Q: Is MCP a replacement for function calling?

No. MCP and function calling solve different layers. Function calling is the model-side API for emitting tool requests; MCP is the host-side protocol for discovering and executing them. In production you almost always use both — MCP delivers the tool catalogue to the host, the host registers it via the model's native function-calling API, and the model emits a tool call.

Q: Are OpenAI Plugins still supported in 2026?

Plugins are deprecated and receive no new features. OpenAI's recommended paths are GPTs with Actions for consumer ChatGPT integrations and MCP for cross-client tooling. Existing plugin manifests may still load in legacy surfaces but should be migrated.

Q: Can ChatGPT use an MCP server?

Yes. ChatGPT (desktop and the Responses API) added MCP client support during 2025, joining Claude Desktop, Cursor, Windsurf, and other agent runtimes. The same MCP server can serve all of them.

Q: Do I have to choose between Anthropic and OpenAI to use MCP?

No. MCP is an open specification. Servers are model-agnostic; clients exist for Claude, ChatGPT, Cursor, Windsurf, custom LangChain/LlamaIndex agents, and more.

Q: What is the simplest migration path from Plugins to MCP?

Wrap the same OpenAPI surface that powered the plugin in an MCP server's tools primitive, port the manifest description into MCP tool descriptions, and connect from any MCP-aware client. You generally do not need to change the underlying API.