MCP with LangChain and LangGraph — Practical Integration

Recall Module 11’s own real, generic translation layer — it genuinely works, but it’s more boilerplate than a real, current integration actually needs. This module covers the real, idiomatic, current patterns your own LangChain and LangGraph coursework provide directly.

The real, current LangChain MCP adapter

Recall Module 11’s own hand-written make_langchain_tool function — the real, official langchain-mcp-adapters package does this same job, with far less code.

We’ll load every real tool from an MCP server directly into LangChain’s own native tool format, in one, genuine call.

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
from langchain_mcp_adapters.tools import load_mcp_tools
from langchain.chat_models import init_chat_model
from langchain.agents import create_agent

server_params = StdioServerParameters(command="python", args=["support_server.py"])

async def build_agent():
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()  # recall Module 4's own real lifecycle
            tools = await load_mcp_tools(session)  # one real call, replacing Module 11's entire function
            agent = create_agent(model=init_chat_model("openai:gpt-4o-mini"), tools=tools)
            return agent

flowchart LR
    A[Module 11: hand-written\ntranslation function] --> B["Module 12: load_mcp_tools(session)\none real, official call"]

Notice load_mcp_tools(session) genuinely replaces every real line of Module 11’s own make_langchain_tool — discovery, wrapping, and translation, all handled directly by real, official, maintained code. Notice also stdio_client and ClientSession here come directly from the underlying, official mcp SDK, not from FastMCP — langchain-mcp-adapters is built to work with the real, raw protocol session directly.

Multiple real MCP servers, one real agent

Recall Module 3’s own real, multi-client architecture — one Host, several real, distinct connections. LangChain’s own adapter genuinely supports this directly.

We’ll connect to two, genuinely separate MCP servers, and combine both real toolsets into one agent.

from langchain_mcp_adapters.client import MultiServerMCPClient

async def build_multi_server_agent():
    client = MultiServerMCPClient({
        "support": {"command": "python", "args": ["support_server.py"], "transport": "stdio"},
        "github": {"url": "https://mcp.github.example/mcp", "transport": "streamable_http"},  # recall Module 8
    })
    tools = await client.get_tools()  # real tools from BOTH servers, combined
    agent = create_agent(model=init_chat_model("openai:gpt-4o-mini"), tools=tools)
    return agent

Notice MultiServerMCPClient genuinely manages two, real, separate connections — recall Module 8’s own distinction, one using stdio, one using streamable_http — and combines their real tools into one, single list, exactly the way a real, complex enterprise assistant would need.

MCP inside a real LangGraph node, the idiomatic way

Recall Module 11’s own hand-written LangGraph node — let’s build the same real capability using the official adapter directly.

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain.chat_models import init_chat_model

class State(TypedDict):
    question: str
    answer: str

async def mcp_agent_node(state: State) -> dict:
    client = MultiServerMCPClient({"support": {"command": "python", "args": ["support_server.py"], "transport": "stdio"}})
    tools = await client.get_tools()
    model_with_tools = init_chat_model("openai:gpt-4o-mini").bind_tools(tools)
    response = await model_with_tools.ainvoke(state["question"])
    return {"answer": response.content}

builder = StateGraph(State)
builder.add_node("mcp_agent", mcp_agent_node)
builder.add_edge(START, "mcp_agent")
builder.add_edge("mcp_agent", END)
graph = builder.compile()

Recall your LangGraph course’s own .bind_tools(...) pattern — genuinely unchanged. MCP tools, once loaded through the real adapter, behave exactly like any other real LangChain tool from that point forward.

Why the real, official adapter is worth using over Module 11’s version

Recall your LangChain course’s own real “don’t reinvent what’s already solved” discipline. Module 11’s hand-written translation layer is genuinely valuable for understanding what’s happening underneath — recall this course’s own recurring commitment to never leaving an abstraction unexplained. But real, ongoing production work should reach for langchain-mcp-adapters directly: it’s maintained, it correctly handles real edge cases — like a tool’s schema changing — that a hand-written version genuinely might miss.

Common mistakes worth avoiding

Hand-writing your own MCP-to-LangChain translation layer in real, production code. Recall this module’s own real comparison — load_mcp_tools genuinely does this correctly, and stays current as MCP itself evolves; Module 11’s version was for understanding the mechanism, not for real, ongoing use.

Opening a separate MultiServerMCPClient per request in a real, high-traffic application. Recall Module 11’s own same, real warning — a genuine production system should reuse real, persistent connections, not reconnect on every single call.

Assuming MultiServerMCPClient requires every server to use the same real transport. Recall this module’s own real example — stdio and streamable_http genuinely coexist in the same, single configuration, each server using whichever real transport actually fits it.

What you should take away from this module

• langchain_mcp_adapters.tools.load_mcp_tools is the real, official, current replacement for Module 11’s hand-written translation function.
• MultiServerMCPClient genuinely manages several, real, separate MCP connections at once, combining their tools into one list — mixing transports freely.
• Once loaded, MCP tools behave exactly like any other real LangChain tool — .bind_tools(), create_agent, and every pattern from your prior coursework applies unchanged.

Where this goes next

The next module covers the same, real practical integration specifically for LlamaIndex — its own, idiomatic pattern for loading MCP tools directly into a real FunctionAgent.