LangChain + MCP in Practice: Architecture Protocol and Agent Tool Integration

Large language models can converse and reason, but that alone is far from enough to truly connect them to an enterprise's internal business systems. The combination of LangChain and MCP is solving two core pain points: tool reuse and cross-framework compatibility.

What Is LangChain: A Framework for Building AI Applications

LangChain is a framework for developing large model applications. The model itself has reasoning capability—it can understand user intent and organize messy information—but its responses are based on training data and cannot directly access an enterprise's internal business data. To make the model converse in the context of company business, you need to bind tools to it: let it, beyond understanding the question, also call tools to obtain business data or text content, and then rely on its reasoning capability to produce an answer.

If you hand-write model invocation, tool management, and conversation history management from scratch, you'll spend a great deal of energy on low-level logic. LangChain encapsulates these capabilities into ready-made APIs, so developers can focus on the business itself. Similar frameworks include Cloud SDK and OpenAI SDK, but there's no need to hand-roll a LangChain replacement—standing on the shoulders of giants is more worthwhile.

To understand LangChain's positioning, you can break it down into several replaceable abstraction layers: Model (a unified wrapper around the invocation interfaces of various large models), Tool (describing business functions as structures the model can understand), Retriever (integrating with vector stores for retrieval augmentation), Memory / session state (managing multi-turn conversation history), and the Chain and orchestration layer that wires these together. When developers switch model providers, they usually only need to change one line of configuration in the Model layer; the rest of the business logic is unaffected.

LangChain uses the MIT open-source license and provides both Python and JavaScript/TypeScript implementations. Its community ecosystem includes a large number of ready-made document loaders, vector store adapters, and tool integrations. Note that LangChain was originally centered on "chains," but its orchestration capabilities gradually moved down into LangGraph, developed by the same team; LangChain itself now focuses more on component abstractions such as models, tools, and retrieval. This is also the origin of the technology stack layering mentioned in this article.

Agent Is a Higher-Level Encapsulation

An Agent goes a level higher than a plain large model call. Conversations with a large model generate a large amount of chat history, which an Agent can manage automatically; when a large model calls a tool on its own, it only knows that it wants to call it but does not actually execute it—an Agent actually completes the tool call and returns the result. Further, an Agent can judge from the tool's returned result whether it needs to continue calling tools.

In the LangChain framework, create_agent is the entry point for creating an Agent; you just specify the model and tools. LangChain itself provides a way to define tools, for example using add_tool to define business tools such as get_stock_price and search_news. But these tools have nothing to do with MCP, which leads to the reason MCP exists.

What Problem MCP Solves: Decoupling Tools from Models

In the early days, when an Agent called tools, different model vendors each had their own approach. Model A had one API for calling tools 1, 2, 3, and 4; Model B had another way to call the same four tools; Model C had yet another. The result: as soon as you switched the underlying model, the code for calling tools might have to be completely rewritten.

MCP (Model Context Protocol) is a protocol that specifies how tools are discovered, how they are called, and how their results are handled. Regardless of whether the upper layer is OpenAI, DeepSeek^Ad, Cloud, or another vendor's model, as long as a tool is developed according to the MCP protocol, it can be adapted and supported. It's like a computer's USB port: as long as an external device is compatible with the USB protocol, it will be recognized when plugged in.

MCP was proposed by Anthropic and quickly gained support from mainstream AI vendors after its release. According to the speaker's observation, almost all mainstream vendors' large models can call tools developed according to the MCP protocol, which brings great convenience.

Architecturally, MCP uses a client–server model: the MCP Server is responsible for exposing capabilities, and the MCP Client is usually built into an Agent host or AI application; the two communicate through standardized messages. The protocol defines three main capabilities—Tools (functions that can be called by the model), Resources (data or file context that can be read), and Prompts (preset prompt templates)—so that context provision beyond "tools" is also unified.

At the transport layer, MCP supports a local stdio method based on standard input/output, as well as a remote method based on HTTP (early on HTTP+SSE, later evolving into Streamable HTTP). The former is suitable for wrapping local scripts or databases into tools, while the latter is suitable for public services shared by a team. This design allows an MCP Server to be developed, deployed, and upgraded independently, fully decoupled from the Agent that calls it. As a result, an enterprise internal system only needs to implement one MCP Server to serve different teams, different frameworks, and even different vendors' AI products at the same time.

The Real Value of Integrating LangChain with MCP

Tools defined directly in LangChain can only be used by the Agent built in the current code. If a second piece of code builds a new Agent and wants to reuse the same two tools, it has to redefine them—poor reusability.

MCP brings two clear benefits. First, tools can be reused very well: when multiple codebases and multiple Agents need the same tools, you can manage them uniformly with MCP. Second, tools developed according to the MCP protocol are not limited to Agents built with LangChain—any Agent that complies with the MCP protocol can use them, including Agents developed with Cloud SDK and OpenAI SDK, as well as various AI coding tools, achieving decoupling from specific frameworks.

In practical discussion, the speaker also uses examples to put local tools and MCP tools in the same Agent, visually showing the difference between the two.

What Is the Relationship Between MCP and Function Calling?

Function Calling is a concept introduced by OpenAI, and MCP is a concept introduced by Anthropic. They do the same thing—just different names used by different companies. The difference is that Function Calling has not developed as well as MCP, and OpenAI today is also fully compatible with MCP. In today's context, it's fine to treat the two as the same thing; in industry discussion, MCP appears noticeably more often.

Function Calling is a structured output capability provided by large models: developers use JSON Schema to describe the names, parameters, and purposes of available functions; when needed, the model returns a call request that conforms to that Schema, and the host program executes it and returns the result to the model. Its essence is "the model tells you what to call"; the actual execution is still done by the application side. Therefore, Function Calling is a model-side capability, while MCP is an application-side communication protocol—they sit at different layers. An MCP tool call often works at the bottom precisely by using Function Calling to make the model generate the call intent, after which the MCP client completes discovery, transport, and result filling.

This also explains why the two are often conflated—from the developer's perspective, the final effect is the same: "the model used an external tool." But MCP additionally specifies the tool registration and discovery mechanism, the transport method (such as stdio and HTTP), and lifecycle management, so that the same tool implementation can be reused by different models and different frameworks. That is something plain Function Calling does not provide.

Technology Stack Layers and Common Questions

LangChain's technical architecture, from bottom to top, is: LangGraph as the lower-level API; Agents are developed on top of LangGraph and encapsulated at a higher level; above that is Deep Agent. The lower the API, the more flexible it is; the higher the encapsulation, the more convenient it is to use.

In addition, Harness is an architectural idea involving tool management, content isolation, file handling, automatic context compression, and more; its implementation is embodied in the Deep Agent layer, and Deep Agent itself is developed on top of LangChain and LangGraph.

For beginners who want to get started with large model development, the answer is that it's feasible, but you need to start from zero fundamentals. Agents themselves are not divided into domestic and foreign; what is divided into domestic and foreign are the large models. For developing Agents, it's recommended to use LangChain directly. As for tools like Codex and Cursor, they are mainly aimed at programming scenarios and are a different-level issue from building your own AI applications within an enterprise.