LangChain with MCP and Skill: A Practical Guide to Agent Tool Invocation

As AI Agent development becomes increasingly mainstream, MCP (Model Context Protocol) and Skill have become key concepts that developers can't afford to ignore. Yet many developers still have a vague understanding of these two concepts—some have only heard the terms without ever actually using them. This article systematically breaks down the core logic of integrating MCP and Skill into LangChain Agents, helping you clarify concepts and identify the right use cases.

LangChain is one of the most popular frameworks for building applications with large language models, created by Harrison Chase in 2022. It provides a standardized abstraction layer that enables developers to combine LLMs with external data sources, tools, and APIs. The Agent concept in LangChain is particularly crucial—an Agent is an intelligent entity that dynamically decides which tools to call and in what order based on user input. Unlike simple Chains (fixed-process pipelines), Agents possess reasoning and decision-making capabilities, adjusting their strategy at runtime based on intermediate results. Understanding this background helps us better grasp the roles that MCP and Skill play within this ecosystem.

Why Does Agent Development Need MCP?

If we simply define MCP as "a protocol for LLMs to call external tools, business systems, or traditional interfaces," most people would be left scratching their heads. Linguistically it's a "protocol," but what problem it actually solves isn't immediately obvious.

To truly understand MCP's value, we need to revisit the history of software development. Before large models emerged, we had already accumulated decades of software systems: some built in Java, some in Go, some in PHP. The market has amassed a vast number of business systems and interfaces.

A critical question follows: now that large models are popular, should all these legacy systems be discarded? The answer is obviously no. If that were the case, 90% of programmers would be out of work, and society's entire software infrastructure would collapse.

Take an e-commerce system as an example—we have product search interfaces, inventory query interfaces, and many other business APIs. After large models appeared, these interfaces didn't disappear; instead, they need to be "understood" and "invoked" by the model. MCP was born precisely to solve this bridging problem.

From a technical positioning standpoint, MCP (Model Context Protocol) is essentially a standardized interface description and invocation protocol that defines the complete workflow for how large models discover, understand, and call external tools. Unlike traditional API Gateways or RPC protocols, MCP's core innovation lies in introducing a semantic layer—each tool must include not only technical specifications (parameter types, return values) but also natural language descriptions that enable models to decide when to invoke tools based on semantic matching. This design philosophy originates from the Model Context Protocol specification open-sourced by Anthropic in late 2024, aimed at solving the fragmentation problem in tool invocation.

The Nature of Traditional Interfaces: Designed for Programs, Not Models

To understand why MCP is necessary, we first need to see traditional interfaces for what they truly are.

The Call Chain of Traditional Interfaces

In a typical e-commerce system, the call flow looks roughly like this: the frontend handles page rendering, while the actual business logic is implemented by backend interfaces. When a user searches for products, the frontend calls the backend's product search service, the service layer executes business logic, queries the database, and finally returns a product list.

Typical enterprise applications adopt a layered architecture: presentation layer (frontend UI), application layer (business logic), service layer (domain services), and data layer (database). With the rise of microservices architecture, services typically communicate via RESTful APIs, gRPC, or message queues. These interfaces follow strict type contracts—the caller must know the exact endpoint address, HTTP method, request body format, and response structure. This design is efficient and reliable for machine-to-machine communication but lacks the semantic context that large models require.

The core insight here is: traditional interfaces are fundamentally designed for programs. For example, a search method in a ProductService—programmers instantly understand which layer it's in, which method to call, what the parameters are, and what the return type is (most likely a collection). All of this is crystal clear to trained software engineers.

Why Large Models Can't Understand Traditional Interfaces

But for large models, the situation is completely different. You can't simply tell a model to "call that search method."

Whether it's ChatGPT, Doubao, or DeepSeek, if you directly ask it to "call the method we just wrote," it has no way to proceed—it doesn't know what the interface does, how to pass parameters, when it should be used, or what the returned data looks like.

This is precisely the crux of the problem: traditional interfaces are designed for programs, while large models need semantic descriptions in natural language. They need a "tool"—a wrapper with clear descriptions (what this tool does, when to use it, what the parameters mean). Only when a model faces a clearly described "product search tool" can it correctly invoke it in the appropriate scenario.

To deeply understand this mechanism, we need to understand the technical principles of Function Calling. A large model's tool invocation capability (Function Calling) is the technical foundation that makes MCP possible. OpenAI pioneered Function Calling in 2023, with other major model providers following suit. The principle is: available tools are described in a structured format (typically JSON Schema) within the system prompt—including name, purpose, and parameters. When generating a response, the model can choose to output a tool invocation instruction rather than a direct text answer. The framework layer parses this instruction, executes the tool, and returns the result to the model for further reasoning. MCP further standardizes the registration, discovery, and invocation workflow on top of this, enabling tools from different sources to be used by Agents in a unified manner.

MCP's Core Value: Bridging Large Models and External Systems

Overall, MCP's value lies in building a bridge between large models and existing systems. It transforms traditional, program-oriented interfaces into semantically described "tools" that models can understand.

As a result:

• Business systems accumulated over decades don't need to be rebuilt from scratch
• Large models can invoke these capabilities through a unified protocol
• Agent developers don't have to hand-write complex adaptation logic for each interface

In the entire LangChain Agent development pipeline, MCP is an extremely important component. It makes the combination of "large model + business system" possible, rather than keeping the two isolated.

Differences and Use Cases: MCP, Skill, and RAG

Many developers are not only unclear about MCP but also frequently confuse Skill and RAG—unsure which one to use in which scenario. Here's a directional comparison:

• MCP (Model Context Protocol): Solves the problem of large models "calling external tools/system interfaces," emphasizing protocol-based capability integration
• Skill (Skill Unit): More oriented toward encapsulating a specific capability or skill unit; in some scenarios it's finer-grained and more flexible than MCP
• RAG (Retrieval-Augmented Generation): Solves knowledge retrieval augmentation, enabling models to answer questions based on external knowledge bases—a fundamentally different dimension from tool invocation

Regarding Skill, it's worth explaining its implementation forms across different frameworks. In Microsoft's Semantic Kernel, a Skill is defined as a collection of related functions, with each function representing an atomic capability. In the broader Agent development context, a Skill typically refers to a module encapsulating specific domain capabilities, potentially combining multiple tool calls, prompt templates, and post-processing logic. Unlike MCP's emphasis on "protocol-level standardized integration," Skill focuses more on "capability-level modular encapsulation"—a single Skill might internally invoke multiple external interfaces via MCP to complete a complex business action. For example, an "Order Processing Skill" might internally combine inventory queries, price calculations, and logistics scheduling across three MCP tool calls.

Regarding RAG, its technical principles deserve deeper exploration. RAG (Retrieval-Augmented Generation) was proposed by Meta AI in 2020. The core idea is embedding an external knowledge base retrieval process into the generation workflow. A typical RAG pipeline includes: chunking documents and converting them to vectors via an Embedding model, storing them in a vector database (such as Pinecone, Milvus, or FAISS), retrieving relevant document chunks when a user asks a question, injecting the retrieved results as context into the prompt, and finally having the LLM generate an answer based on that context. RAG addresses the "insufficient knowledge" problem (limitations in model training data's timeliness and specialization), while MCP addresses the "insufficient capability" problem (models cannot execute external operations). The former is about "letting the model know more," while the latter is about "letting the model do more."

These three are not mutually exclusive but serve different roles within an Agent architecture. Understanding the distinct problems each solves enables correct technology selection in real projects. In a complete Agent system, these three often work in concert: RAG provides knowledge support, MCP connects external systems, and Skill organizes and orchestrates complex business logic.

Conclusion: Understanding MCP by Starting from the Core Contradiction

For developers who have already learned LangChain, integrating MCP and Skill is essentially "adding new capabilities" on top of an existing foundation. The first step to understanding MCP isn't memorizing protocol definitions—it's thinking clearly about this: traditional interfaces were built for programs, while large models need semantically described tools. Once you grasp this core contradiction, the reason for MCP's existence becomes crystal clear.

In subsequent hands-on practice, clarifying the boundaries between MCP, Skill, and RAG is what truly enables you to build AI Agent applications that can both reuse existing systems and scale flexibly.