API teams are currently wasting cycles debating whether to use function calling, ChatGPT plugins, or the Model Context Protocol (MCP) as mutually exclusive options. This is a category error. A new analysis published on DEV.to on October 3, 2026, clarifies that these are distinct layers in the agent stack, not competing alternatives. Treating them as such results in brittle architectures that fail the moment you introduce a second agent client, such as moving from a custom CLI to Cursor or Claude Code.

Function Calling Is Just a Model Primitive

Function calling is strictly a feature of the chat completion API, not an integration standard. When you send a list of JSON Schema inputs to the model, the model decides to emit a structured call, but your application still owns the entire lifecycle: tool catalog assembly, authentication, execution, retries, and result mapping. There is no network protocol for discovery and no persistence. Two applications using the same model and API still require two separate, hand-written tool integrations. This duplication is the exact friction MCP was designed to eliminate.

Plugins Are Dead; MCP Is the Transport Layer

ChatGPT plugins, announced in 2023 and later deprecated in favor of GPTs, were a distribution experiment tied to one host and one product's review model. While they validated the concept of manifest-driven discovery, they never became a cross-vendor standard. MCP, by contrast, is a client-to-server protocol that standardizes the conversation function calling was previously hand-rolling. It defines transports for both local stdio processes and remote streamable HTTP services. Crucially, MCP does not replace function calling; the model still performs the function call. MCP simply replaces the bespoke glue code that exposed tools to the model, allowing a single server to work with any MCP client.

OpenAPI Is the Source of Truth

The most efficient path to an MCP server is generating it directly from an OpenAPI 3.2 document. The mapping is mechanical: operations become tools, parameters become input schemas, and security schemes become runtime-injected credentials. This approach ensures that docs, mocks, SDKs, and agent tools all derive from a single source, preventing the rot that occurs when hand-written wrappers drift from the actual API schema. By keeping credentials and destructive-action policies inside the server rather than in prompts, you maintain security boundaries that function calling alone cannot enforce.

Key Takeaways

  • Function calling is a model capability; MCP is the protocol for tool discovery and transport.
  • ChatGPT plugins are a legacy path; MCP is the current cross-vendor default for 2026.
  • Generate MCP servers from OpenAPI specs to avoid duplication and ensure schema consistency.
  • Keep authentication and dangerous action policies server-side, never in the prompt.

The Bottom Line

Stop hand-rolling tool wrappers. If your OpenAPI spec isn't powering your MCP server, you are building technical debt that will break as soon as you switch IDEs or agent clients.