How does MCP compare to LangChain tools/agents or OpenAI's function calling / plugin model?
Quick Answer
LangChain's tool/agent abstractions and OpenAI's function calling are both framework- or vendor-scoped: a LangChain tool is defined in and consumed by LangChain's own Python/JS abstractions, and OpenAI's function-calling schema is specific to OpenAI's API request/response shape. MCP is an open, vendor-neutral protocol at a different layer: it standardizes discovery and invocation so any MCP-aware client can use a server's tools regardless of what agent framework or model provider that client happens to use. In practice, they're not strictly competitors — LangChain can (and does) wrap MCP servers as LangChain tools, and a host using OpenAI's function-calling API can source its tool definitions from an MCP server and reshape them into OpenAI's schema. MCP's distinct value is portability: a tool built once as an MCP server works across many different hosts and frameworks without being re-implemented for each one.
Detailed Answer
It's easy to see "tools," "function calling," and "MCP" all in the same sentence and assume they're competing for the same job. They mostly aren't.
What each one actually is
| Scope | Portability | |
|---|---|---|
| OpenAI function calling | A specific API's request/response schema for letting a model emit structured function calls | Tied to that vendor's API shape |
| LangChain tools/agents | A framework's own abstraction for defining and orchestrating tools within LangChain-based apps | Tied to that framework, though it can wrap other things |
| MCP | An open protocol for how a server exposes tools/resources/prompts, and how any client discovers/invokes them | Works across any MCP-aware host or framework |
Where they compose rather than compete
MCP Server (tools/list) --> LangChain MCP adapter --> LangChain Tool object
|
v
LangChain Agent
MCP Server (tools/list) --> Host reshapes inputSchema --> OpenAI function-calling schema
|
v
OpenAI API request
Both LangChain and OpenAI-based applications can consume an MCP server's tools without the server author writing anything framework- or vendor-specific. The adapter/reshaping work happens on the consuming side, once, rather than the tool author needing to publish a separate integration for every framework.
The actual tradeoff to weigh
If you're building a tool that only needs to work inside one specific app you control, using that framework's native tool abstraction directly can be simpler. There's no protocol overhead, no separate process or transport to manage. Building it as an MCP server instead trades a bit of that simplicity for reuse: the same server works in Claude Desktop, an IDE, a custom agent, or any other MCP-compatible host without modification. The decision generally comes down to whether you expect, or want to enable, more than one consumer for the same integration.