MCP vs OpenAI Function Calling vs LangChain Tools
Three complementary standards handle protocols, models, and workflows at different layers.
MCP vs OpenAI Function Calling vs LangChain Tools is a choice between layers. For MCP server access for AI agent web data, an agent can use Olostep as a registered tool to send URLs and receive structured JSON or Markdown without managing browsers or scrapers itself. MCP standardises access, OpenAI Function Calling handles model-requested calls, and LangChain Tools orchestrates the workflow.
Why the same problem produced three different solutions
A language model needs a way to invoke external capabilities reliably. Before MCP, connecting a model to an external system meant writing against that system’s API, then repeating the integration for each AI application. Function calling handled the request from the model, LangChain handled the workflow around it, and MCP handled the connection between clients and tools. Treating them as substitutes is like asking whether a plug is better than a switchboard.
Live web data arrives as raw HTML and unstructured content, which needs parsing before an agent can use it well. Olostep handles that downstream work through a web data API, including browsers, proxies, and batching across thousands of URLs. That distinction matters because a standard tool interface does not make the data behind it clean. A production architecture can need a protocol, an API feature, a framework, and a fetch layer without having bought the same thing four times.
What each approach actually does at its own layer of the stack
The conceptual stack reads as protocol → API → framework. This is a map of responsibilities across layers that requests can use selectively. MCP defines how clients discover and call tools, OpenAI Function Calling defines how the model requests a call, and LangChain defines how calls fit into a larger workflow.
At the protocol layer, MCP uses JSON-RPC 2.0 and exposes discovery through tools/list. A client receives the server’s current tool catalog instead of relying only on definitions built into its application. The protocol can run over stdio, SSE, or HTTP streaming. Anthropic introduced MCP in November 2024 and donated it to the Linux Foundation’s Agentic AI Foundation in December 2025. With support from OpenAI, Google, and Microsoft, that shared interface can reach more users.
At the API layer, OpenAI Function Calling embeds tool schemas in the tools array of each Chat Completions API request. The model returns a tool-call request, but the application executes it and handles authentication, rate limits, errors, and results. This is an OpenAI-specific interface.
At the framework layer, LangChain Tools wraps callable functions with defined inputs and outputs. Execution is in-process, while adapters let OpenAI, Anthropic, and other providers sit beneath the same tool definitions. Its primary value is orchestration through chains, agents, memory, and LangGraph state machines. LangChain also supports dynamic tool registration, so “code-defined” should not be mistaken for “frozen forever.”
The token cost reality that changes the economic calculus for each layer
Where schemas live determines what enters the model’s context window. With OpenAI Function Calling, developers choose exactly which tool definitions to send with each request. When the catalog is small and fixed, tuning the schema set by hand keeps that overhead low. MCP discovery becomes costly when an integration loads every registered tool into context whether the task needs it or not.
Anthropic’s data indicates that MCP metadata can consume a large fraction of total tokens in some environments. The cost can compound rather than scale neatly when several servers contribute full catalogs across repeated requests. MCP can therefore consume many times more tokens than a CLI equivalent for the same task. Orchestrated agent workflows also cost substantially more than a single LLM chat, though they perform more work. LangChain’s schema cost resembles function calling, while its orchestration overhead becomes easier to justify across complex workflows.
External data adds a separate bill. An agent that parses raw HTML in context consumes far more tokens than one receiving pre-structured JSON. Separating retrieval and structuring into a dedicated layer, such as Olostep, keeps that work outside the reasoning loop. This prevents bulky page content from adding to schema overhead. Tool definitions and tool results are two different occupants of the same limited window.
Three mitigation patterns that reduce the MCP Tax without abandoning the protocol
Cloudflare’s Code Mode shows how a large API surface can avoid becoming a giant prompt. Cloudflare exposes four tools, namely docs(), search(), execute(), and whoami(). The core API-access pair is search() and execute(). The agent writes JavaScript to query the API specification, finds the relevant endpoints, and executes calls in a sandbox. That query-and-execute surface brings token cost down to a small fraction of the naive approach.
Anthropic’s engineering team showed a second way to do this, progressive disclosure. Instead of loading every registered definition, the agent loads only the tools it currently needs. This also reduces token use to a small fraction of the original cost. The important constraint is where that selection happens. Under the 2026-07-28 MCP specification’s stateless model, per-session or per-tenant tool lists belong at the application or authorization layer and remain independent of the connection.
A schema-filtering gateway provides the third pattern. It sits between the agent and MCP servers and selects definitions based on the current request’s intent. Unlike the query-and-execute approach, it narrows the catalog presented to the model rather than replacing a broad catalog with a compact execution interface. These patterns make the MCP Tax an infrastructure problem with engineering remedies. Runtime discovery need not mean runtime dumping.
Where MCP's runtime discovery creates genuine architectural advantages function calling cannot replicate
Runtime discovery separates tool availability from the application’s built-in schema set. A server can make its capabilities available to compatible clients without a separate integration for each client. Function calling alone does not provide that shared discovery contract, and LangChain’s provider adapters do not create one either. Applications can reproduce parts of the behaviour with custom code.
Multi-tenancy needs a version-aware distinction. In the connection-based model, tools/list could return different catalogs for different tenants, users, or sessions. Under the stateless specification, the application or authorization logic must do that filtering. MCP still provides a shared surface for governance, but tenant isolation is not a magic property of a discovery endpoint. A gateway can enforce JWT or mTLS authentication, policy-engine-based authorization, rate limits, and per-invocation audit trails without changes to each consuming application.
Portability is the other durable advantage. A server built for Claude Desktop, Cursor, or a custom agent is usable by other MCP-compatible clients without rewriting its tool schemas. Webflow’s official MCP server lets agents work within Webflow projects while enforcing account roles and permissions and recording actions in site activity logs. The investment attaches to the capability.
Where LangChain Tools earns its complexity cost through orchestration
LangChain earns its place when the difficult part is the sequence. ReAct and Plan-Execute patterns manage the loop of reasoning, calling a tool, observing the result, and reasoning again. LangGraph maps multi-step workflows to state machines with retries, fallbacks, and parallel branches. A protocol can expose the tools used by that graph, but it does not decide how the graph should proceed. That is the framework’s job.
LangSmith makes those workflows inspectable by tracing steps, API calls, and model decisions. For enterprise teams, this is more than a convenient debugging screen. When a web research workflow fails halfway through, the trace exposes the path leading to the failure rather than leaving only a disappointing final answer. The more branches and model calls a workflow contains, the more valuable that record becomes.
The fetch layer still needs to do its own work. One way to do this in production is to wrap a scraping provider call with a @tool decorator and leave anti-bot bypass, JavaScript rendering, and structured output to the provider underneath. Returning raw HTML as clean Markdown or JSON from Olostep gives the model usable content. For frequently queried, pre-indexed content, a search tool over the index is preferable to live-scraping each time. LangChain’s retriever abstractions and vector store integrations support that route without pretending the framework fixes network failures.
The reliability and security trade-offs that shift the calculus in production
TCP timeouts and network dependencies can make MCP-based execution less reliable than a local CLI for equivalent tasks. Eric Holmes’s argument, “MCP is dead. Long live the CLI,” makes a serious objection. A command and its --help output can cost a fraction of server initialization in tokens, while local execution removes those network dependencies. Portability is not much comfort while a request is timing out.
The counter is narrower than claiming MCP has already solved production operations. Schema filtering, progressive disclosure, and compact execution surfaces address token overhead, while stateless operation reduces persistent-connection complexity. Retries, fallbacks, and observability help manage failures. MCP is a reasonable default for new single-user and small-team agents, but large multi-tenant systems with strict security and observability requirements need more than protocol adoption.
Live web data can pose a security risk with all three approaches. Malicious tool manifests can hide instructions in definitions, while contaminated outputs can carry instructions inside comments or scraped page text. Third-party content can still be unsafe even when its output format is clean. Validate and sanitise tool outputs before feeding them into the model’s reasoning context, regardless of the calling layer.
Where the architecture is heading with stateless MCP, WebMCP, and agent-to-agent coordination
The 2026-07-28 MCP specification made the protocol stateless and moved long-running tasks into an official extension. That makes the base protocol leaner and horizontal scaling simpler by removing persistent-connection overhead. It also changes where applications must apply the rules for session-specific discovery. Automatic discovery through MCP Server Cards is maturing in H2 2026, with the aim of reducing connection configuration.
Agent-to-agent coordination adds another boundary. MCP connects an agent to tools, while A2A connects it to peers. A tool is invoked and returns a result, whereas a peer receives delegated work and negotiates. Tool access remains a responsibility even when the wider workflow becomes a conversation between agents.
WebMCP brings discovery into the browser by letting websites share tool definitions with agents that visit them. Its status is an origin trial and draft report. The direction is capability-by-consent. It strengthens the case for understanding protocol boundaries now.
A decision framework for choosing the right layer, not the right tool
Choose OpenAI Function Calling when the stack is OpenAI-native, the catalog is small and stable, and per-request token cost matters most. It also fits a quick first prototype when portability is less important. The trade is explicit ownership of execution, authentication, errors, and schema management. That can be a sensible bargain when the tool set is easy to hold in your head.
Choose MCP when tools need to work with several clients or model providers, or when different teams look after shared catalogs. It is a strong starting point for a new agent in 2026 without a legacy OpenAI-first stack. For large catalogs, apply schema filtering or progressive disclosure from the start. For strict multi-tenant production requirements, plan to build in authorization, reliability, and observability, since adopting the protocol alone does not guarantee them.
Choose LangChain Tools when branching, retries, parallel calls, state, and debugging dominate the engineering effort. It can consume MCP-exposed capabilities or use OpenAI Function Calling for model interaction. A structured web data API can sit beneath either combination, handling retrieval while the framework handles the workflow. The durable choice is the boundary that lets the rest of the stack change without forcing every integration to be rewritten.
