LangChain and MCP Integration in Practice: From Framework to Agent Development

Why We Need LangChain: Stop Reinventing the Wheel Down at the Bottom Layer

Large models have strong reasoning abilities—they can understand questions and give answers—but the content they produce is essentially knowledge from their training data. To get a large model to converse using a company's internal business data, a common approach is to bind tools to it: the model can not only understand the question but also call tools to fetch business data or text content, then rely on its reasoning abilities to organize an answer.

The problem is that if you hand-write the entire stack—model invocation, tool management, conversation history management—your energy gets consumed by low-level details, making it hard to focus on the business. LangChain is a development framework built precisely for this: it wraps model invocation, tool definition, conversation state management, and other capabilities into ready-to-use APIs, letting developers build applications standing on the shoulders of giants.

The instructor in the course also clears up a common misconception: hand-rolling a LangChain-style framework is not recommended. Since a mature framework already exists, spending time reimplementing low-level invocation and state management isn't worthwhile—focusing on the business is the more sensible choice.

Agent Is a Higher-Level Wrapper Over the Large Model

An agent can be understood as a higher-level wrapper over the large model. When you talk to a large model on its own, you have to manage the chat history yourself; when calling tools, the model only knows that it "wants to call" something but doesn't actually execute it. The agent fills in these gaps: it automatically manages history, actually executes tool calls and returns results, and can judge based on tool results whether it needs to continue calling tools.

According to the instructor, LangChain implements agent capabilities at the bottom with LangGraph—LangGraph is closer to the metal and more flexible, while the agent layer adds a higher-level wrapper that's easier to use. The APIs the framework provides get better encapsulated and more user-friendly the higher up you go.

LangGraph is the low-level orchestration framework released by the LangChain team, and its core abstraction is the "graph": nodes represent computation steps (such as calling a model or executing a tool), edges represent the flow conditions between steps, and state is passed and accumulated between nodes. Compared with LangChain's earlier chain structure, the graph structure supports loops, branching, and interrupt-resume, making it naturally suited to implementing an agent's multi-turn closed loop of "reason—call tools—decide the next step based on results." LangChain's agent layer builds default graph templates and convenient parameter wrappers on top of LangGraph, so developers can get a complete tool-calling loop without hand-writing a state machine—at the cost of slightly less flexibility than using LangGraph directly.

MCP Solves the "Interface Standard" Problem for Tool Calling

Early on, large models from different vendors each had their own way of calling tools: model A had one API style for calling four tools, and model B needed a completely different one for the same four tools. Once the underlying model of an agent changes, the tool-calling code may need to be completely rewritten.

MCP (Model Context Protocol) is a protocol that emerged to eliminate this fragmentation. It specifies how tools are discovered, how they are called, and how results are returned; as long as tools are developed according to this protocol, they can be compatibly adapted regardless of which vendor's model sits on top. The instructor uses a USB analogy: as long as a peripheral is compatible with the USB protocol, it can be recognized the moment you plug it into a computer.

MCP was proposed by Anthropic (the company behind Claude Code), and according to the course, almost all mainstream AI vendors have supported MCP since the protocol was released—this ecosystem compatibility brings enormous convenience.

Are function calling and MCP the same thing?

The course specifically addresses this frequently asked question: function calling is a concept introduced by OpenAI, and MCP is a concept introduced by Anthropic—they do the same thing, just under different names from different companies. According to the instructor, OpenAI is now fully compatible with MCP as well, so it's fine to treat the two as the same thing—people used to talk about function calling, and now they mostly just say MCP.

Tool discovery and registration is an easily overlooked but crucial part of the MCP protocol. Per the MCP spec, tools are exposed externally by an MCP Server as structured descriptions (name, purpose description, input JSON Schema), and the Client first pulls this tool list when connecting, then hands it to the large model to decide when to call and how to fill in parameters. This means adding or modifying tools only needs to be done on the Server side—all connected agents automatically get the update without changing caller code. The protocol also defines transport methods (such as local stdio, remote HTTP/SSE) and result return formats, enabling tools to be deployed independently and reused across processes or even across networks.

Integrating LangChain with MCP: The Focus Is on the Agent

LangChain provides APIs for calling large models and developing agents, while MCP provides tool sets developed according to the protocol—integrating the two means enabling agents built with LangChain to call MCP tools. Since using a large model alone lacks context management and middleware handling, what's discussed in practice is more about integrating the agent with MCP, that is, integration at the LangGraph level.

Why use MCP when built-in tools already exist?

LangChain itself provides ways to define tools—for example, when creating an agent with create_agent, the model parameter specifies the large model and the tools parameter specifies the tool list; the tools themselves can be defined using something like add_tool. The two tools in the course example—get_stock_price, which looks up a stock price by company name, and search_news, which searches company news—have nothing to do with MCP; they are purely tools developed inside LangChain.

That being the case, why develop MCP tools at all? There are two core reasons:

1. Tool reuse: built-in tools can only serve the agent built in the current code. If a second agent created elsewhere in the code wants to use the same tools, they have to be redefined. Managing tools with MCP lets multiple agents and multiple codebases share the same set of tools.
2. Cross-framework decoupling: LangChain built-in tools can only be recognized by agents developed with LangChain. But in reality there are also frameworks like Cloud SDK and OpenAI SDK, plus all kinds of AI tools—they are also agents and also need to call tools. Tools developed according to the MCP protocol can be provided to any agent, decoupled from any specific framework.

Tool interceptor is a commonly used mechanism in MCP integration: it inserts a layer of programmable logic before and after the agent actually executes a tool call, used for parameter validation, permission checks, call logging, result masking, or failure retries. Since MCP tools come from external servers and callers often cannot directly modify their internal implementation, the interceptor becomes the place to uniformly apply control policies on the client side. It complements MCP's philosophy of "decoupling"—tools provide capabilities according to a standard protocol, while control policies are layered on by the caller as needed, and the two don't have to be coupled in the same piece of code.

Other Key Points from the Course and Learning Advice

• Version info: the course is based on LangChain version 1.3.
• LangChain4J: the instructor recommends learning LangChain directly—LangChain4J isn't widely used yet, and the Python version of LangChain has a more complete ecosystem.
• Learning path: beginners can start from zero and learn large model development; if you don't even know what a large model is, the course will be a bit challenging—a large model is a large language model, which can be understood as a system that can converse and produce reasoned responses.
• Tool choice: for building in-house enterprise AI applications, a framework like LangChain is suitable; if you just want a coding assistant, ready-made tools like Claude Code or Cursor work fine.
• Architectural relationships: Harness is an architectural philosophy (how to manage tools, isolate content, automatically compress context, etc.), DeepAgent is one implementation of that philosophy, and DeepAgent is built on top of LangChain and LangGraph.

What comes next in the course

According to the original course outline, this tutorial covers MCP Server development, client integration, tool interceptors, and an e-commerce agent project—a from-0-to-1 hands-on path. This article covers the conceptual groundwork; understanding the framework layering and the value of the protocol is the prerequisite for later hands-on development of MCP Servers and agent projects.

One-line Summary

LangChain wraps low-level calls so developers can focus on the business, while MCP uses a protocol standard to enable cross-framework tool reuse.

Paragraph Summary

The article revolves around two core concepts: LangChain and MCP. LangChain wraps model invocation, tool definition, and conversation state management into APIs, sparing developers from hand-writing low-level logic; its agent layer is a higher-level wrapper over the large model, implemented at the bottom by the more flexible LangGraph. MCP, meanwhile, solves the interface standardization problem for tool calling, specifying how tools are discovered, called, and how results are returned—analogous to a USB interface—decoupling tools from specific model vendors. The article clarifies that function calling and MCP are essentially different names for the same thing, and points out that the core value of using MCP lies in tool reuse and cross-framework decoupling. It ends with learning advice and the MCP Server development and e-commerce agent practice covered later in the course.