LangChain + MCP: From Core Concepts to Agent Tool Calling in Practice

Introduction: Why Learn LangChain and MCP

As large language model (LLM) technology becomes increasingly mainstream, more and more developers want to integrate LLM reasoning capabilities into real-world business scenarios. However, building directly on top of LLM APIs often comes with significant pain points: how to manage conversation history, how to let the model call external tools, and how to handle complex multi-step tasks. This article systematically walks through the core concepts behind the LangChain framework and MCP (Model Context Protocol), helping readers — whether beginners or those with some LLM development experience — build a clear mental model of the technology stack.

Whether you're looking to empower enterprise business workflows or build Agent applications, understanding this stack is an essential first step.

The Capabilities and Limitations of LLMs

We all know that the core value of large language models lies in their powerful reasoning capabilities. Through conversation, an LLM can understand what you mean and respond accordingly — even if you hand it a pile of disorganized documents, it can produce logically structured content. All of this stems from the vast knowledge and reasoning ability the model accumulated during training.

But there's a critical limitation: the content an LLM generates is fundamentally based on data from the point in time when the model was trained. This means the model cannot perceive new information that emerged after training, nor can it directly access your company's internal real-time business data. This brings us to the first core problem we need to solve.

How to Connect LLMs with Enterprise Business Data

How can we enable a large language model to incorporate a company's internal business data into its conversations? The answer is: bind the LLM to Tools.

By binding tools, the LLM — when conversing with us — can not only understand the questions we ask, but also proactively invoke tools to retrieve internal business data or specific text content. Once that data is retrieved, the LLM applies its reasoning capabilities to organize, analyze, and deliver an accurate answer.

This closed loop of "understand the question → call a tool → retrieve data → reason and organize → output an answer" is exactly what transforms an LLM from "just a chatbot" into "something that actually gets things done."

In LLM development, "Tools" is a concept with a precise technical meaning. It refers to predefined functions or API interfaces, typically containing a name, a functional description, and a parameter schema (JSON Schema). The LLM analyzes the match between a user's question and the tool's description to determine whether to invoke the tool, then generates a call request that conforms to the parameter specification. Common tool types include: database query interfaces, search engine APIs, internal enterprise system APIs, and file read/write operations. This mechanism is often referred to as "Function Calling" in APIs from providers like OpenAI, and is the core technical means by which LLMs interact with the outside world.

Why We Need the LangChain Framework

What happens if we start completely from scratch, writing all the code ourselves to call an LLM and manually managing tool-calling logic?

The result is usually this: writing everything by hand doesn't allow us to focus our energy on the business itself. A huge amount of time and effort gets consumed at the lower level — how the LLM calls tools, how tools are managed, how the conversation flow with the LLM is orchestrated, and so on. This underlying complexity severely drags down development efficiency.

LangChain was built precisely to solve this pain point. It is a framework specifically designed for developing LLM-powered applications (AI applications). It encapsulates the tedious low-level call and management logic, allowing developers to truly focus their energy on business logic.

From LLM Conversations to Agents

Beyond simple conversation plus tool calling, the term you'll hear most often is Agent — as in, "building an agent." So what's the relationship between an Agent and an LLM?

Simply put, an Agent is a higher-level abstraction built on top of an LLM. This higher-level encapsulation manifests in several ways:

Automatic Conversation History Management

When you converse with an LLM, a large amount of chat history is generated. Managing this context manually is extremely tedious. An Agent automatically handles this history for you, ensuring conversational continuity.

Actually Executing Tool Calls

This is a critically important distinction: when an LLM handles tool calls on its own, it only knows which tool to call — it doesn't actually execute it. An Agent, on the other hand, actually carries out the action — invoking the tool and collecting the results it returns.

Here's a technical nuance that's easy to overlook: an LLM's "tool call" is really just the output of a structured JSON payload describing which function to call and what parameters to pass. The model itself has no ability to execute code. Actual execution requires a runtime environment to parse that JSON, locate the corresponding function, pass in the parameters, run it, and feed the results back to the LLM for the next round of reasoning. This is exactly the role that Agent frameworks play — acting as an "orchestration coordinator" that bridges the gap between an LLM's reasoning output and real tool execution, forming a complete closed loop.

Autonomous Decision-Making on Whether to Continue

Further still, an Agent can reason based on tool results and autonomously decide whether it needs to continue calling other tools. This capacity for autonomous, iterative decision-making is the core characteristic that distinguishes an intelligent agent from a simple Q&A system.

Framework Selection: Standing on the Shoulders of Giants

LangChain isn't the only framework available for building AI and agent applications.

Beyond LangChain, you may have heard of the Claude SDK, OpenAI SDK, and others — all of which can be used to build various AI applications. These mature frameworks each have their own characteristics, but share a common goal: lowering the barrier to AI application development.

It's worth calling out a common misconception here: don't obsess over "hand-rolling" a framework. Some developers get caught up in the idea of not using existing frameworks — insisting on calling LLM APIs directly to build their own version of LangChain or Claude SDK from scratch. This is completely unnecessary.

Yes, these frameworks were built from scratch at some point — but since mature solutions already exist, we should stand on the shoulders of giants and put them to use. Otherwise, your energy will be wasted on low-level concerns: raw LLM API calls, internal concurrency handling, state management, conversation context management, and other tedious details. Rather than doing that, invest your valuable energy into the business itself.

Summary: The Value Proposition of LangChain + MCP

Looking back at the full picture, we can trace a clear line of reasoning:

• LLMs have powerful reasoning capabilities, but are constrained by training data and cannot directly access real-time or private data;
• By binding tools, LLMs can retrieve external data and combine it with their reasoning to produce answers;
• Agents provide a higher-level abstraction on top of LLMs — automatically managing history, actually executing tool calls, and making autonomous iterative decisions;
• Frameworks like LangChain shield us from underlying complexity and let development focus on business logic.

MCP (Model Context Protocol), as a standardized tool integration protocol, further simplifies how tools connect to LLMs when used alongside LangChain. Mastering the "LangChain + MCP" combination enables developers to efficiently bring LLM capabilities into real business scenarios and build truly practical agent applications.

MCP (Model Context Protocol) is an open protocol standard proposed by Anthropic in late 2024, designed to establish a unified communication specification for interactions between large language models and external tools and data sources. Before MCP, different LLM frameworks and tool providers each defined their own interface formats, resulting in heavily fragmented tool integration. MCP defines a standardized client-server architecture so that any MCP-compatible tool service (MCP Server) can be directly invoked by any MCP-compatible client (such as LangChain or Claude Desktop) — achieving a "build once, integrate anywhere" effect. This is analogous to how the USB standard unified hardware device connectivity, dramatically reducing the integration costs of the tool ecosystem.