LangChain MCP Integration in Practice: From Concepts to Building Multi-Tool AI Applications

From LLMs to AI Applications: Why We Need Development Frameworks

The core capability of Large Language Models (LLMs) is powerful reasoning and understanding—we can communicate through dialogue to have them understand intent and provide responses. However, LLMs have an inherent limitation: their knowledge is frozen at the snapshot of training data and cannot perceive an enterprise's real-time business data. Specifically, LLM training data has a knowledge cutoff—for example, GPT-4's training data cuts off at April 2023, and Claude 3's at early 2024. This means the model knows nothing about events after the cutoff date. More importantly, the model can never access enterprise private data—such as customer information in CRM systems, inventory data in ERP, or internal knowledge base documents. This limitation gave rise to two major technical approaches: RAG (Retrieval-Augmented Generation) and tool calling.

To enable LLMs to engage in dialogue combined with internal business operations, a key approach is binding tools to the LLM. The underlying mechanism of Tool Binding works as follows: developers pass tool names, descriptions, and parameter schemas to the LLM in structured JSON format. During inference, the model determines whether it needs to call a tool based on the user's question. If so, it outputs a structured tool call request (containing the tool name and parameter values). It's important to note that the LLM itself does not execute tools—it only "decides" which tool to call and what parameters to pass. The actual execution requires an external program. With tools bound, the LLM can not only understand your questions but also call tools to retrieve real-time enterprise data, then leverage its reasoning capabilities to organize and deliver logical answers.

However, if we hand-code all the low-level logic for LLM calls, tool management, and conversation content management from scratch, all our energy gets consumed by infrastructure rather than focusing on the business layer that truly creates value. LangChain is an AI application development framework born precisely to solve this problem. Created by Harrison Chase in October 2022, LangChain has evolved into one of the de facto standard frameworks for AI application development. Its core modules include: LangChain Core (base abstraction layer), LangChain Community (third-party integrations), LangGraph (stateful multi-step orchestration), and LangSmith (observability platform). LangChain connects model calls, prompt templates, output parsers, and other components through a unified Runnable interface, supporting LCEL (LangChain Expression Language) declarative orchestration, significantly reducing the code needed to build complex AI application chains. It encapsulates tedious work like LLM calls, concurrency control, state management, and conversation history management, letting developers stand on the shoulders of giants and focus on business logic.

It's worth emphasizing: similar frameworks include Claude SDK, OpenAI SDK, and others, all of which can be used to build AI applications. It's not recommended to reinvent the wheel for the sake of it—those mature frameworks themselves are excellent solutions built from scratch, and duplicating them only wastes effort.

Agents: Higher-Level Capability Encapsulation Beyond LLMs

Beyond directly dialoguing with LLMs to call tools, the hotter concept today is the Agent. An Agent provides higher-level encapsulation on top of LLMs, with capabilities manifested in several ways:

• Automatic conversation history management: LLM dialogues generate massive chat histories, and Agents can automatically manage this context for you.
• Actual tool execution: When an LLM alone calls a tool, it only "knows" which tool to call but doesn't actually execute it. An Agent can truly operate tools, execute calls, and return results.
• Multi-turn autonomous decision-making: Agents can also determine whether to call the next tool based on previous tool results, forming an autonomous reasoning loop.

The Agent's multi-turn autonomous decision-making capability stems from the ReAct (Reasoning + Acting) paradigm, proposed by Yao et al. in 2022. Its core idea is: the model first reasons (Thought), then decides on an action (Action), observes the result (Observation), and enters the next reasoning round. This cycle continues until the model believes it has gathered enough information to answer the user's question. This "think-act-observe" loop gives Agents complex task-handling capabilities that go beyond single-turn Q&A.

For this reason, what this article discusses as LangChain integrating MCP is essentially about the integration of Agents with MCP. In LangChain's technology stack, the Agent's underlying implementation relies on LangGraph—a more low-level, flexible API layer. LangGraph models the Agent's execution flow as a Stateful Graph, where developers can define Nodes and Edges. Nodes represent specific operations (such as calling the model or executing tools), and edges represent transition conditions (such as flowing to the tool execution node when the model decides to call a tool). Compared to traditional chain-based calls, the graph structure supports loops, conditional branches, and parallel execution, expressing more complex Agent behavior patterns. LangGraph also has built-in Checkpoint mechanisms supporting persistence and recovery of conversation state. Looking from bottom to top: LangGraph is the most flexible, LangChain's Agent API sits in the middle, and DeepAgent offers the highest level of encapsulation and user-friendliness.

MCP Protocol Explained: The USB Port of the AI World

MCP (Model Context Protocol) is the core concept for understanding this article. The pain point it addresses is very specific.

Pain Point: Different LLMs Have Different Tool-Calling Implementations

Suppose your Agent uses an LLM from a specific vendor (such as DeepSeek, OpenAI, or Claude) under the hood. Each vendor has its own API format for calling tools. This means:

Once your Agent switches to a different LLM vendor, the original tool-calling code often breaks and needs to be rewritten for the new model. For complex systems with multiple models and tools, this creates an enormous maintenance burden.

Solution: One Standard Protocol Compatible with All Models

MCP was proposed by Anthropic (the parent company of Claude) in November 2024. Anthropic was founded in 2021 by former OpenAI Research VP Dario Amodei and is known for AI safety research. MCP's design motivation stemmed from an industry pain point: at the time, every AI vendor had its own tool-calling format, requiring developers to maintain different tool adaptation code for different models. MCP uses JSON-RPC 2.0 as its underlying communication protocol, defining standardized operations such as tool discovery (list tools), tool invocation (call tool), and resource access (read resource), with specification documents and SDKs maintained open-source on GitHub.

It establishes a unified standard: regardless of whether you're using OpenAI, DeepSeek, Claude, or models from Microsoft or Amazon, as long as tools are developed following the MCP protocol, any protocol-compliant model can discover, call, and process the return results from those tools.

A brilliant analogy explains this: MCP is like a computer's USB port. External USB drives, hard drives, and other devices (corresponding to various tools) can be recognized by any computer as long as they're USB-compatible. And on the computer side (corresponding to the LLM), regardless of the model, it can recognize devices with standard interfaces.

Currently, virtually all major AI providers support MCP. The previously popular Function Calling (a concept proposed by OpenAI) essentially does the same thing. Function Calling was first introduced by OpenAI in June 2023 alongside the GPT-3.5/GPT-4 API release, defining how models output structured function call requests. However, Function Calling only standardized the output format on the model side without specifying how tool servers register, discover, and expose tools. MCP goes further—it not only covers the calling protocol but also standardizes the complete lifecycle of tool registration, discovery, description, and permission control. In essence, Function Calling solved "how models express calling intent," while MCP solved "how tools are uniformly managed and shared across systems." Today, OpenAI is also fully MCP-compatible, and MCP has become the de facto standard.

Limitations of LangChain's Native Tools

The LangChain framework itself provides ways to define tools, such as declaring them directly via decorators:

from langchain.agents import create_agent

# Define LangChain native tools
def get_stock_price(company: str):
    """Get stock price by company name"""
    ...

def search_news(company: str):
    """Search news related to the specified company"""
    ...

agent = create_agent(
    model="...",           # Specify the LLM
    tools=[get_stock_price, search_news]  # Specify tools
)

Since LangChain can already define tools, why use MCP? The key lies in two major issues: reusability and decoupling.

Limitation 1: Tools Cannot Be Reused Across Codebases

Tools defined natively in LangChain can only be used by the Agent built within the current codebase. If you build a new Agent in another codebase and want to reuse the same tools, you must redefine them all over again—there's no good way to achieve reuse.

Limitation 2: Tools Cannot Be Used Across Frameworks

LangChain native tools can only be recognized by LangChain Agents. But in reality, Agent frameworks are diverse—Claude SDK, OpenAI SDK, and various coding assistants like Cursor, Codex, etc., are all intelligent agents capable of calling tools. Tools written using LangChain's native approach cannot be provided to these heterogeneous frameworks.

MCP fills exactly these two gaps:

1. Tool Reuse: Through centralized tool management via MCP, multiple codebases and Agents can all connect to the same set of MCP tools. This is similar to the microservices architecture philosophy of extracting common capabilities into independent services—tools run as independent MCP Servers, and any Agent needing that capability simply connects to use it without reimplementation.
2. Framework Decoupling: As long as tools are developed following the MCP protocol, they can be provided to any Agent, whether it's LangChain, Claude SDK, or OpenAI SDK. This achieves complete decoupling between tool providers and tool consumers, allowing developers to independently evolve tool implementations without affecting upstream Agents.

MCP Server and Client: Two Core Roles and Communication Mechanisms

When building MCP applications, you need to understand the two core roles:

• MCP Server: The side that builds and exposes a set of tools. You package tools and publish them externally through the Server.
• MCP Client: The side that uses tools—the side where the Agent resides. The Agent connects to the MCP Server to call tools, playing the Client role.

Using the USB analogy from above: the Client side is like the LLM/computer host, and the Server side is like peripherals with various tools attached.

Two Communication Methods: Stdio and Streamable HTTP

There are two typical communication scenarios between Client and Server:

1. Stdio (Standard Input/Output)

When Client and Server run on the same node (or even the same process), the Stdio method can be used. It communicates via standard input/output streams, suitable for local development and debugging. More precisely, the technical implementation of Stdio mode works as follows: the Client process launches the Server process via a subprocess mechanism, then communicates through operating system pipes. The Client writes JSON-RPC requests to the Server's stdin and reads JSON-RPC responses from the Server's stdout. The advantages of this approach are zero network overhead, no port configuration needed, and inherent security (no network interface exposed). The disadvantage is that Client and Server must be on the same machine, and the Server's lifecycle is bound to the Client.

2. Streamable HTTP

When the Server is deployed remotely and the Client is in another process or node, Streamable HTTP (often abbreviated as HTTP) is used. Streamable HTTP is a remote communication method introduced to the MCP protocol in March 2025 (replacing the earlier SSE approach). It's based on standard HTTP protocol—the Client sends JSON-RPC messages to the Server's /mcp endpoint via POST requests. The Server can choose to return a direct JSON response or upgrade to an SSE (Server-Sent Events) streaming response, suitable for long-running tool calls. This design balances low latency for simple scenarios with streaming capabilities for complex ones, while natively supporting production-grade infrastructure like load balancing and TLS encryption—ideal for distributed, service-oriented production deployments.

Summary: The Complete Path from Concepts to Practice

This article has outlined the complete technical lineage from LLMs to Agents to MCP:

• LangChain is an efficient framework for building AI applications, letting developers focus on business rather than underlying implementation.
• Agents encapsulate conversation management, tool execution, and multi-turn decision-making capabilities on top of LLMs.
• MCP as a unified protocol, like a USB port, achieves decoupling between tools and models, delivering two core values: cross-codebase reuse and cross-framework compatibility.

With these concepts understood, you can move into practice: set up an MCP Server to publish tools, build an Agent using LangChain/LangGraph as a Client to connect to tools, and use both local tools and MCP tools simultaneously within the same Agent to experience the differences firsthand. This is also the critical first step toward building multi-tool AI applications.