MCP vs function calling vs ChatGPT plugins: what API teams actually need in 2026

When teams start connecting APIs to AI agents, three terms arrive together and get used interchangeably: function calling, ChatGPT plugins, and the Model Context Protocol (MCP). They are different layers of the stack, and treating them as alternatives leads to architectures that do not survive contact with a second agent client. Here is the layered breakdown, what each one actually solves, and where an OpenAPI document becomes the source for all of them.

Function calling is a model capability

Function calling is a feature of a chat completion: you send the model a list of available functions with JSON Schema inputs, the model decides to emit a structured call, and your application executes it and feeds the result back. The contract lives in your prompt-time request; there is no network protocol for discovering tools, no standard transport, no persistence. You, the application developer, own:

• The tool catalog and how it is assembled.
• Authentication to the underlying APIs.
• Execution, retries, timeouts, and confirmation for dangerous actions.
• Mapping results back into the conversation.

Function calling is therefore a primitive inside an agent runtime, not an integration standard. Two applications using the same model with the same API still write two different tool integrations. That duplication is the problem everything below tries to remove.

ChatGPT plugins were a distribution experiment

The plugins system (announced 2023, later deprecated as a product line in favor of GPTs and the broader tools ecosystem) defined a way for ChatGPT to discover an API through an ai-plugin.json manifest pointing at an OpenAPI document. It was important historically because it validated the idea that models should discover HTTP operations from a contract rather than from pasted docs, but it was tied to one host, one product's review and distribution model, and one conversation surface. The lessons survived; the plugin protocol as a cross-vendor standard did not. If you see integration guides referencing plugins in 2026, they are describing a legacy path.

MCP is a client-to-server protocol

The Model Context Protocol standardizes the conversation the function-calling layer was hand-rolling. An MCP server exposes tools (callable functions with JSON Schema input), resources (readable context), and prompts over a defined transport — stdio for local processes, HTTP (streamable) for remote services. An MCP client (an IDE agent, a chat app, a CLI) connects, lists tools, and calls them; the server executes against your API and returns results.

The division of labor is the important part:

MCP does not replace function calling; the model still function-calls. It replaces the bespoke, per-application glue that exposed tools to the model. The same MCP server works with Cursor, Claude Code, IDE agents, and custom clients because the discovery and transport are standardized.

How the three compare

Where OpenAPI fits

An OpenAPI document is already a machine-readable catalog of callable operations with typed inputs and outputs — almost exactly the shape of an MCP tool list. The mapping is mechanical: operation to tool, parameters and request body to inputSchema, security schemes to runtime-injected credentials, responses to tool results. Generating the MCP server from the spec means:

• One source of truth. Docs, mocks, SDKs, and agent tools all derive from the same document instead of four hand-maintained descriptions.
• Pre-flight validation. The server rejects arguments that violate the schema before the HTTP call, turning a class of model mistakes into immediate, correctable tool errors.
• Consistent auth. Tokens live in the server configuration with scopes per audience; the prompt never sees credentials.
• Streaming included. SSE operations documented with their event contracts become tools that open the stream and return collected events instead of hanging.

The alternative — hand-writing MCP tool wrappers that repeat what the spec says — recreates the exact duplication the protocol was meant to eliminate, and rots on the first schema change.

When you still write custom tools

Not every agent capability is an API operation, and forcing everything through the OpenAPI-generated surface is the other mistake. Custom MCP tools make sense for composite, domain-level actions ("prepare release notes from the changelog and open the PR"), local capabilities (reading the workspace spec file), and actions requiring policy checks or human confirmation (anything that deletes or spends). The mature setup is generated tools for the API's operations plus a small set of hand-built workflow tools, all behind one MCP server, with the dangerous ones gated.

What API teams should actually build in 2026

1. Keep a tight, current OpenAPI 3.2 document with real descriptions, enums, and examples — it is now consumed by machines choosing actions, not just humans reading docs.
2. Serve it as an MCP endpoint: locally for developers (stdio over the spec file), hosted with scoped tokens for partners and internal agents.
3. Treat tool descriptions like API design: verb-first names, state when to call, document errors in machine-readable form (problem+json type values let agents self-correct).
4. Keep credentials and destructive-action policy in the server, never in prompts.
5. Ignore new plugin-shaped vendor lock-ins; MCP's multi-client support is the point.

Powerduck generates the MCP server from the same local spec used for design, mocks, and tests, and publishes a hosted, token-scoped MCP endpoint alongside docs from one revision — the step-by-step conversion walkthrough covers the operation-to-tool mapping in detail, and the demo shows the serve action.

What to read next: connect Cursor and Claude Code to your internal API over MCP is the hands-on setup, and your API already describes the tools your agent needs makes the discovery argument in depth.