How to build MCP Client using LangGraph | Agentic AI using LangGraph | CampusX

Agentic AI tool integrations get brittle fast when every chatbot hard-codes custom “tool” wrappers for each external service. MCP (Model Context Protocol) is presented as a cleaner, more maintainable way to connect LLM apps to tools by separating the heavy, service-specific logic on a server from the lightweight client configuration inside the LangGraph app—so API changes on the tool side don’t force repeated client rewrites.

The walkthrough starts with a practical pain point. A LangGraph chatbot already uses three tools: an internet search tool, a calculator tool, and a “get stock price” tool. When a manager asks for GitHub-backed question answering—like listing pull requests from GitHub repositories—the usual approach is to create a custom user-defined tool. That tool needs inputs such as repository owner, repository URL, pull request state (open/closed), and how many pull requests to return. It also requires GitHub authentication via a token and additional headers, then calls GitHub’s REST API, parses JSON, and formats results.

The fragility shows up when GitHub changes its API. A major version shift (from API 1.0 to API 2.0) can alter URL paths and response fields (for example, renaming attributes). With the “tool code inside the chatbot” approach, the chatbot breaks immediately and developers must update the tool wrapper. The maintenance burden multiplies: one API change can require edits across many tool implementations, and even more so across multiple chatbots and additional integrations like Gmail, Slack, or other services.

MCP is introduced as the fix for that maintenance problem. Instead of embedding service-specific code directly in each chatbot, MCP runs tool logic on an MCP server and exposes standardized tool definitions to clients. The LangGraph side holds only configuration needed to connect to the MCP server. When the server updates for upstream API changes, the client configuration remains stable, because the client doesn’t depend on GitHub’s evolving API details.

After the conceptual case, the coding section demonstrates building an MCP client inside LangGraph. The existing LangGraph chatbot is first converted from synchronous execution to asynchronous execution because the MCP client library used for integration works in async mode. The original calculator tool node is then replaced with an MCP client that connects to a locally running MCP math server (built with a library such as “langchain mcp servers”). The client fetches the available tools from the server—addition, subtraction, multiplication, division, power, and modulus—then binds those tools to the LangGraph LLM.

A second demo adds a remote MCP server for expense tracking (deployed over HTTP with a “streamable HTTP” transport). The same LangGraph chatbot can now list, add, and summarize expenses by simply extending the MCP client configuration with the remote server URL and transport settings—no new tool code inside the chatbot.

Finally, the lesson expands into a mixed architecture: the chatbot can use both traditional LangGraph tools and MCP-based tools together. A larger Streamlit + LangGraph + SQLite setup is adapted to support MCP clients, with additional async-compatible components (like an async SQLite layer) and an async streaming function. The result is a chatbot that can answer questions using both web/search tools and MCP-served capabilities, with a strong emphasis on future-proofing and reducing integration churn.