{"slug": "building-an-agentic-ai-assistant-with-langgraph-and-mcp", "title": "Building an Agentic AI Assistant with LangGraph and MCP", "summary": "A developer built an agentic AI assistant using Python, LangGraph, the Model Context Protocol (MCP), Groq, and Streamlit that supports multi-turn conversations and coordinates multiple tool calls through a ReAct-style agent pattern. The assistant connects to sandboxed filesystem and web-search MCP servers via MultiServerMCPClient from langchain-mcp-adapters, launched as stdio subprocesses, and uses LangGraph's MemorySaver with a thread_id to persist conversation state. The developer cautions that MCP standardizes tool communication but does not make tools safe, so applications must still validate inputs, limit permissions, and constrain execution.", "body_md": "A basic chatbot receives a question and generates a response. An AI agent can go further: it can select tools, execute actions, observe the results, and decide what to do next.\n\nI explored this approach in my **Agentic AI Assistant with MCP Tools** project, built with Python, LangGraph, the Model Context Protocol (MCP), Groq, and Streamlit.\n\nThe assistant supports multi-turn conversations and can use a sandboxed filesystem tool and a web-search tool. This article explains how the components fit together and what I learned about building tool-using AI systems.\n\nConsider a user asking:\n\n\"Search for the latest LangGraph release notes and save a short summary in a text file.\"\n\nA simple chatbot might explain how to perform these steps. An agent can instead work through the task:\n\nThe important difference is that the application can coordinate multiple tool calls rather than generating only a text response.\n\nTool use does not mean an agent is always correct. The model can choose an unsuitable tool, misunderstand results, or produce an inaccurate summary. The surrounding application must therefore control which actions are available and how they are executed.\n\nLangGraph provides orchestration for agent workflows.\n\nIn my project, the assistant uses a ReAct-style agent pattern. The model can alternate between reasoning about the request, selecting a tool, receiving its output, and deciding whether another action is needed.\n\nThe simplified flow is:\n\n`User request → Agent → Tool call → Tool result → Agent → Final response`\n\nSome requests require only a final response. Others require multiple tool calls.\n\nThe agent orchestration is handled through LangGraph's prebuilt agent functionality, while the Streamlit application provides the conversational interface.\n\nThis separation is useful because the interface does not need to implement the agent's decision-making logic itself.\n\nIntegrating every external tool directly into an agent can make the application tightly coupled to individual implementations.\n\nThe Model Context Protocol (MCP) defines a standard way for applications to communicate with tool-providing servers and discover available capabilities.\n\nIn this project, I use MCP to connect the agent to two separate servers:\n\nThe agent uses `MultiServerMCPClient` from `langchain-mcp-adapters` to connect to the servers and retrieve their available tools.\n\nIn the current implementation, the servers are launched as subprocesses and communicate over standard input/output (stdio).\n\nThis architecture separates the agent's orchestration from the individual tool implementations. Adding another compatible server can extend the assistant's capabilities without placing every tool implementation directly inside the agent.\n\nMCP standardizes communication; it does not automatically make a tool safe. The application still needs to validate inputs, limit permissions, and control access to sensitive resources.\n\nTool discovery allows the agent application to learn which operations a connected MCP server exposes.\n\nFor example, the filesystem server provides operations for listing, reading, and writing files within its allowed directory. The search server exposes a web-search capability.\n\nThe application retrieves these tools and makes them available to the agent.\n\nWhen a request arrives, the model can select an appropriate tool based on the request and the tool descriptions. The orchestration layer then routes the call to the correct server and returns its result to the agent.\n\nThis approach is more flexible than writing a separate hard-coded branch for every possible user request.\n\nHowever, the model's choice should never be treated as authorization by itself. Tool execution must remain constrained by the application's actual permissions.\n\nWithout conversation history, a chatbot may struggle with follow-up questions such as \"Now save that result to a file.\"\n\nMy project uses LangGraph's `MemorySaver` with a conversation-specific `thread_id` to maintain state across turns.\n\nThe application assigns a thread identifier to the session, allowing follow-up requests to access the relevant conversation history.\n\nThis helps the agent understand references to earlier questions and results.\n\nThere is an important distinction between in-memory conversation state and durable storage. An in-memory checkpointer is useful for a prototype, but its state should not be assumed to survive every process restart or to provide a permanent database-backed conversation archive.\n\nAn AI agent that can read and write files needs stronger safeguards than a chatbot that only generates text.\n\nMy filesystem tool restricts access to a designated sandbox directory and resolves requested paths against that directory. Paths that attempt to escape the sandbox, such as those containing traversal sequences, are rejected.\n\nThis is an important defense because an agent may construct a path incorrectly or respond to an unsafe instruction.\n\nOther safeguards worth considering include:\n\nA sandbox is one layer of defense, not a guarantee of complete security.\n\nThis project helped me understand several practical aspects of agent development:\n\nBuilding an agentic assistant helped me explore how language models, workflow orchestration, and external tools can work together to complete multi-step tasks.\n\nLangGraph manages the agent workflow, MCP provides a consistent tool-integration layer, and Streamlit makes the system accessible through a chat interface.\n\nThe most important lesson is that useful agents need more than tool access. They also need clear boundaries, reliable error handling, and careful control over what actions they are permitted to perform.\n\n**Project:** [Explore Agentic AI Assistant with MCP Tools on GitHub](https://github.com/Vedant01111/Agentic-AI-Assistant-with-MCP-tools)\n\n**Live demo:** [MCP-Assistant](https://vedant-agentic-assistant.streamlit.app/)\n\n**Technologies:** Python, LangGraph, MCP, Groq, Tavily, Streamlit, and Docker.\n\n**Further reading:** [LangChain and LangGraph learning resources](https://docs.langchain.com/oss/python/learn) · [MCP documentation](https://modelcontextprotocol.io/)", "url": "https://wpnews.pro/news/building-an-agentic-ai-assistant-with-langgraph-and-mcp", "canonical_source": "https://dev.to/vedant01111/building-an-agentic-ai-assistant-with-langgraph-and-mcp-j0", "published_at": "2026-10-29 14:43:31+00:00", "updated_at": "2026-10-29 14:49:58.820098+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "large-language-models", "developer-tools"], "entities": ["LangGraph", "Model Context Protocol", "Groq", "Streamlit", "langchain-mcp-adapters", "MultiServerMCPClient", "MemorySaver", "Python"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/building-an-agentic-ai-assistant-with-langgraph-and-mcp", "markdown": "https://wpnews.pro/news/building-an-agentic-ai-assistant-with-langgraph-and-mcp.md", "text": "https://wpnews.pro/news/building-an-agentic-ai-assistant-with-langgraph-and-mcp.txt", "jsonld": "https://wpnews.pro/news/building-an-agentic-ai-assistant-with-langgraph-and-mcp.jsonld"}}