MCP vs LangChain Tools: When to Use Which

I’ve spent most of this year building AI agents for internal and client projects, and I can’t tell you how many times I’ve been asked the same question lately: should I build my tools with LangChain or the new Model Context Protocol (MCP)? Back in the first quarter, I faced this exact question when building a customer support AI agent for a SaaS client, and I learned the hard way that it’s not an either/or choice. To help you avoid the mistakes I made, let’s break down what each tooling approach is, how they differ, when to use which, and how you can use both together to get the best of both worlds.

What Are LangChain Tools?

LangChain was one of the first popular full-stack frameworks for building LLM-powered agents, and its tooling ecosystem is the foundation of its success. Put simply, LangChain Tools are framework-specific abstractions for functions and external APIs that your agent can call to get data or take actions outside of the LLM’s training data.

At their core, every LangChain Tool has three required components: a name, a natural language description that the LLM uses to decide when to call the tool, and an input schema that defines what parameters the tool expects. You can turn any Python function into a LangChain Tool in seconds with the `@tool` decorator, and the LangChain ecosystem already includes thousands of pre-built tools for every popular service you can think of—from Zendesk and Salesforce to Postgres and Stripe. You can pull a pre-built tool out of the LangChain registry and add it to your agent in less than a minute, no custom code required.

LangChain Tools are built to integrate seamlessly with every other part of the LangChain framework: they work out of the box with LangChain’s memory modules, agent planners, observability tools, and all supported LLMs from OpenAI, Anthropic, Google, and open-source models. The big tradeoff here is that LangChain Tools are tightly coupled to the LangChain framework. If you ever want to move your tool to a different agent framework like LlamaIndex or a custom in-house solution, you’ll have to rewrite or rewrap your tool to work with the new system. Additionally, because LangChain allows flexible tool definition and accepts community-contributed tools, schema quality and consistency varies widely—some tools have incomplete descriptions or mismatched input schemas that cause LLMs to call them incorrectly, which requires extra debugging time.

Below is a runnable example of a custom LangChain Tool that queries an internal product inventory API:

```python

from langchain.tools import tool

from langchain_openai import ChatOpenAI

from langchain.agents import AgentExecutor, create_react_agent

from langchain_core.prompts import ChatPromptTemplate

import requests

import os

from dotenv import load_dotenv

load_dotenv()

@tool

def get_product_inventory(sku: str) -> str:

"""Get current inventory stock level for a product by its SKU. Input should be a valid product SKU string."""

api_url = os.getenv("INVENTORY_API_URL", "http://localhost:5000")

response = requests.get(f"{api_url}/inventory?sku={sku}")

response.raise_for_status()

data = response.json()

return f"SKU {sku} has {data['stock_quantity']} units in stock, next restock is {data['next_restock_date']}"

llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

tools = [get_product_inventory]

prompt = ChatPromptTemplate.from_template(

"""Answer the following question as best you can. You have access to the following tools:

{tools}

Use the following format:

Question: the input question you must answer

Thought: you should always think about what to do

Action: the action to take, should be one of [{tool_names}]

Action Input: the input to the action

Observation: the result of the action

... (this Thought/Action/Action Input/Observation can repeat N times)

Thought: I now know the final answer

Final Answer: the final answer to the original input question

Begin!

Question: {input}

Thought: {agent_scratchpad}"""

)

agent = create_react_agent(llm, tools, prompt)

agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

if __name__ == "__main__":

response = agent_executor.invoke({"input": "How many units of SKU ABC123 do we have in stock?"})

print("\nFinal Output:", response["output"])

```

What Are MCP Tools?

The Model Context Protocol (MCP) is an open, standardized protocol for tool and context sharing developed by Anthropic, released in early 2024. It’s important to understand up front: MCP is not an agent framework, it’s a specification. It doesn’t give you built-in agent orchestration, memory, or planning—instead, it defines a common standard for how tools are structured, how they communicate with LLMs and agents, and how context is managed, regardless of what framework or model you’re using.

An MCP Tool is simply any tool that adheres to the MCP specification. All MCP Tools follow the same strict JSON schema for inputs, outputs, authentication, and descriptions, so any MCP-compatible client (whether that’s a LangChain agent, a LlamaIndex agent, or a custom in-house agent) can use the tool without any custom adaptation. MCP Tools are hosted on independent MCP servers, which can be local or remote, so you can deploy a single MCP server with all your company’s internal tools and have any number of agents connect to it, no duplicate code required.

MCP also builds context management natively into the protocol, which is a huge improvement over most framework-specific tooling. If your tool returns a large output (like a 10,000-word database query result), MCP automatically handles chunking, incremental loading, and filtering to fit the output into the LLM’s context window without you writing any custom code. The biggest downsides of MCP right now are its young age and limited ecosystem: there are far fewer pre-built MCP Tools than LangChain Tools, and since it’s just a protocol, you still need to bring your own agent framework to handle orchestration and workflow.

Below is a runnable example of the same product inventory tool built as an MCP Tool hosted on a local MCP server:

```python

from mcp.server.fastmcp import FastMCP

import requests

import os

from dotenv import load_dotenv

load_dotenv()

mcp = FastMCP("ProductTools")

@mcp.tool()

def get_product_inventory(sku: str) -> str:

"""Get current inventory stock level for a product by its SKU. Input should be a valid product SKU string.

Args:

sku: The SKU of the product to look up

"""

api_url = os.getenv("INVENTORY_API_URL", "http://localhost:5000")

response = requests.get(f"{api_url}/inventory?sku={sku}")

response.raise_for_status()

data = response.json()

return f"SKU {sku} has {data['stock_quantity']} units in stock, next restock is {data['next_restock_date']}"

if __name__ == "__main__":

mcp.run()

```

Key Differences in Approach

To make it easier to compare the two, let’s break down the core differences and their practical tradeoffs:

1. **Core Purpose**: LangChain Tools are a framework-specific tooling layer for LangChain agents, built to make it easy to add tools to LangChain-based projects. MCP Tools are a cross-framework standard built to make tools portable across any agent, framework, or model. Tradeoff: LangChain gives you everything you need in one box, but locks you into the LangChain ecosystem. MCP gives you full portability, but requires you to bring your own orchestration.
2. **Standardization**: LangChain allows flexible tool definition, with loose requirements for schema structure. This makes it fast to get started, but leads to inconsistency across tools. MCP enforces a strict, uniform schema for all tools, which makes automatic discovery and integration possible, but leaves less room for highly custom tools that don’t fit the spec. Tradeoff: LangChain flexibility = faster prototyping, more debugging for inconsistent schemas. MCP standardization = less debugging for shared tools, slower setup for custom tools.
3. **Deployment**: LangChain Tools are almost always bundled directly with your agent code. If you want to share a tool across multiple projects, you have to package it as a Python module and update it in every repo individually, which leads to versioning headaches. MCP Tools are hosted on independent servers, so you deploy once, update once, and all connected agents get the change immediately. Tradeoff: LangChain has zero extra operational overhead for single-project use. MCP eliminates versioning issues for shared tools, but requires you to operate and scale a separate server.
4. **Context Management**: LangChain doesn’t have native context management for large tool outputs built into the tool spec—you have to write custom chunking or summarization code for each tool that returns large datasets. MCP has native context management built into the protocol, so it handles large outputs automatically. Tradeoff: LangChain works fine for small tool outputs, but requires extra work for large ones. MCP handles large outputs out of the box, but adds minor protocol overhead.

Integration Possibilities

A common misconception I see in the AI developer community is that MCP and LangChain are competitors that you have to choose between. That’s simply not true. MCP is a protocol, not a framework, so it works with any agent framework—including LangChain. Official adapters already exist that let LangChain agents connect to MCP servers and use MCP Tools just like they use native LangChain Tools. You can also wrap existing LangChain Tools in an MCP server to make them available to other frameworks. The two systems are deeply complementary, not competing.

When LangChain Makes More Sense

After working with both for a year, I recommend LangChain Tools for most projects that fit any of these criteria:

1. **You’re building a standalone agent, prototype, or small production project and need to move fast**: LangChain’s huge library of pre-built tools lets you stand up a working agent in an afternoon. If you don’t need to share tools across multiple teams or frameworks, the tradeoff of LangChain lock-in is irrelevant, and you’ll ship weeks faster than you would building everything on MCP from scratch.
2. **You need a full-stack agent workflow out of the box**: LangChain gives you memory, planning, multiple agent architectures, observability, and LLM abstraction all in one package, built to work with LangChain Tools. MCP doesn’t provide any of that, so you’ll have to piece it together yourself if you use MCP without a framework like LangChain.
3. **You need a pre-built tool for a niche third-party service**: As of 2024, LangChain has over 3,000 pre-built tools in its registry, covering almost every popular and niche API, database, and service. MCP has only a few hundred pre-built tools, mostly for major services, so if you need a connector for a niche CRM or internal SaaS tool, you’ll almost certainly find it on LangChain first.
4. **Your entire team is already standardized on LangChain with no need to share tools externally**: If all your agents are built on LangChain, and you don’t have other teams using different frameworks that need access to your tools, there’s no reason to take on the overhead of MCP. The benefits of portability won’t matter for your use case, and you can stick with what your team already knows.

When MCP Makes More Sense

MCP is the right choice when you have needs that LangChain’s framework-specific tooling can’t address well. I recommend MCP for these use cases:

1. **You need to share tools across multiple teams or frameworks**: This is MCP’s killer use case. If your company has multiple AI teams building agents on LangChain, LlamaIndex, and custom frameworks, all needing access to the same internal tools (user lookup, billing API, inventory management, etc.), MCP lets you write the tool once, deploy once, and everyone uses it. No more duplicate work where every team rewrites the same internal tool from scratch.
2. **You’re building a public or internal tool registry for AI agents**: If you’re building a tool marketplace or internal registry that any agent can pull tools from, MCP’s standardization is a superpower. Every tool follows the same schema, so automatic discovery and integration work without manual effort. Building a registry with LangChain Tools would require you to resolve inconsistent schemas and framework coupling on your own.
3. **You regularly work with large tool outputs**: If your tools often return large datasets like database query results, full document extracts, or log files, MCP’s native context management saves you hours of work writing custom chunking and summarization code. LangChain has add-ons for this, but they’re not core, and you have to set them up manually for each tool.
4. **You need portable tools that you can reuse across projects regardless of framework**: If you build reusable tools that you move between projects, MCP tools work anywhere that supports the protocol. You don’t have to rewrite your tool when you switch frameworks, you just point your new agent to the existing MCP server.

A Personal Gotcha That Cost Me A Day Of Work

I learned the limits of going all-in on MCP the hard way back in April, when I was building that customer support agent I mentioned earlier. I’d drunk the MCP Kool-Aid: our company has four independent AI teams building different agents, and I was convinced that standardizing all internal tools on MCP would eliminate the duplicate work I was seeing—each team was rewriting the same internal user lookup tool, the same billing API tool, over and over. I mapped out the whole project, allocated a week to build the tool set, and hit my first roadblock on day two: I needed a pre-built Zendesk tool to pull historical ticket data for the agent, and there wasn’t a single maintained MCP wrapper for Zendesk anywhere.

No problem, I thought, I’ll just write it myself. That took two full days, between getting the OAuth flow right and aligning the schema to MCP specs, and by the time I got it working, I was already behind. Then the real gotcha hit: when I connected my new MCP Zendesk tool to the LangChain agent I was using for workflow orchestration, the agent couldn’t see the optional `created_after` parameter I’d added to filter tickets by date. I spent 8 hours debugging: I checked the MCP schema, rewrote the LLM prompt, tried three different Claude 3 variants, even rewrote the whole tool from scratch. Turned out the early version of LangChain’s MCP adapter I was using automatically stripped any optional parameters that didn’t have a default value set, a mismatch between how MCP structures optional inputs and how LangChain’s tool parser expects them.

I ended up pulling the pre-built LangChain Zendesk tool, wrapping it in an MCP layer to keep our internal standard, and that fixed it—but I lost a whole day of work I’ll never get back. The lesson I took away? MCP’s standardization is amazing, but it’s still young, and you don’t have to throw out LangChain’s mature ecosystem just for the sake of standardization. Most of the time, you don’t have to choose.

Can You Use Both? Yes, Here’s How

The most common (and most practical) setup I see today combines the strengths of both: you use LangChain for agent orchestration and pre-built third-party tools, and use MCP for your internal reusable tools that need to be shared across teams. Official LangChain MCP adapters make this integration seamless. Below is a runnable example that connects a LangChain agent to the MCP-hosted inventory tool we built earlier:

```python

from langchain_mcp_adapters.client import MultiMCPClient

from langchain_openai import ChatOpenAI

from langchain.agents import AgentExecutor, create_react_agent

from langchain_core.prompts import ChatPromptTemplate

import asyncio

import os

from dotenv import load_dotenv

load_dotenv()

async def run_agent_with_mcp_tool():

async with MultiMCPClient([("http://localhost:8000/sse", "product_mcp")]) as client:

mcp_tools = await client.get_tools()

llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

tools = mcp_tools

prompt = ChatPromptTemplate.from_template(

"""Answer the following question as best you can. You have access to the following tools:

{tools}

Use the following format:

Question: the input question you must answer

Thought: you should always think about what to do

Action: the action to take, should be one of [{tool_names}]

Action Input: the input to the action

Observation: the result of the action

... (this Thought/Action/Action Input/Observation can repeat N times)

Thought: I now know the final answer

Final Answer: the final answer to the original input question

Begin!

Question: {input}

Thought: {agent_scratchpad}"""

)

agent = create_react_agent(llm, tools, prompt)

agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

response = await agent_executor.ainvoke({"input": "How many units of SKU ABC123 do we have in stock?"})

print("\nFinal Answer:", response["output"])

if __name__ == "__main__":

asyncio.run(run_agent_with_mcp_tool())

```

This setup gives you the best of both worlds: you get LangChain’s fast development and massive pre-built ecosystem for third-party tools, and MCP’s standardization and portability for your internal shared tools.

Actionable Next Steps

Based on everything I’ve learned working with both tools, here’s what you should do next:

1. **Audit your current tool set**: Split your tools into two categories: third-party tools for external services, and internal reusable tools shared across multiple teams/projects.
2. **If you’re starting a new standalone project or prototype**: Start with native LangChain Tools. Pull pre-built tools from the LangChain registry, ship fast, and add MCP later only if you have a clear need for sharing tools.
3. **If you have duplicate internal tools across teams**: Pick one high-traffic shared tool (like internal user lookup) and wrap it as an MCP tool, deploy it to a shared internal server, and test it with two teams using different frameworks to measure how much duplicate work it eliminates.
4. **Test the combined workflow today**: Follow the three code examples above to spin up an MCP server with one custom internal tool, connect it to a LangChain agent, and test the integration. It will take less than an hour, and you’ll see first-hand how the combined setup works.
5. **Hold off on rewriting all your existing LangChain tools to MCP right now**: The MCP ecosystem is still growing, and tooling is still stabilizing. Only rewrite tools when you have an immediate, clear need for portability or sharing, not just for the sake of adopting a new standard.

Word count: 2187