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.
I explored this approach in my Agentic AI Assistant with MCP Tools project, built with Python, LangGraph, the Model Context Protocol (MCP), Groq, and Streamlit.
The 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.
1. From chatbots to agents
Consider a user asking:
"Search for the latest LangGraph release notes and save a short summary in a text file."
A simple chatbot might explain how to perform these steps. An agent can instead work through the task:
- Interpret the user's request.
- Decide to use a web-search tool.
- Examine the search results.
- Summarize the relevant information.
- Use a filesystem tool to write the summary.
- Report the result to the user.
The important difference is that the application can coordinate multiple tool calls rather than generating only a text response.
Tool 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.
2. What does LangGraph do?
LangGraph provides orchestration for agent workflows.
In 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.
The simplified flow is:
User request → Agent → Tool call → Tool result → Agent → Final response
Some requests require only a final response. Others require multiple tool calls.
The agent orchestration is handled through LangGraph's prebuilt agent functionality, while the Streamlit application provides the conversational interface.
This separation is useful because the interface does not need to implement the agent's decision-making logic itself.
3. Why use the Model Context Protocol?
Integrating every external tool directly into an agent can make the application tightly coupled to individual implementations.
The Model Context Protocol (MCP) defines a standard way for applications to communicate with tool-providing servers and discover available capabilities.
In this project, I use MCP to connect the agent to two separate servers:
- Filesystem server: Lists, reads, and writes files inside a designated sandbox directory.
- Search server: Uses Tavily to perform web searches.
The agent uses MultiServerMCPClient from langchain-mcp-adapters to connect to the servers and retrieve their available tools.
In the current implementation, the servers are launched as subprocesses and communicate over standard input/output (stdio).
This 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.
MCP 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.
4. Understanding tool discovery
Tool discovery allows the agent application to learn which operations a connected MCP server exposes.
For example, the filesystem server provides operations for listing, reading, and writing files within its allowed directory. The search server exposes a web-search capability.
The application retrieves these tools and makes them available to the agent.
When 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.
This approach is more flexible than writing a separate hard-coded branch for every possible user request.
However, the model's choice should never be treated as authorization by itself. Tool execution must remain constrained by the application's actual permissions.
5. Adding memory to multi-turn conversations
Without conversation history, a chatbot may struggle with follow-up questions such as "Now save that result to a file."
My project uses LangGraph's MemorySaver with a conversation-specific thread_id to maintain state across turns.
The application assigns a thread identifier to the session, allowing follow-up requests to access the relevant conversation history.
This helps the agent understand references to earlier questions and results.
There 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.
6. Why sandboxing matters
An AI agent that can read and write files needs stronger safeguards than a chatbot that only generates text.
My 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.
This is an important defense because an agent may construct a path incorrectly or respond to an unsafe instruction.
Other safeguards worth considering include:
- Validating tool arguments before execution.
- Keeping API keys in environment variables rather than source code.
- Limiting network and filesystem permissions.
- Recording tool calls and errors for debugging.
- Requiring user confirmation for consequential actions.
A sandbox is one layer of defense, not a guarantee of complete security.
7. Lessons from building the assistant
This project helped me understand several practical aspects of agent development:
- Tool calling requires orchestration, not just a capable language model.
- MCP can separate tool providers from the agent that consumes them.
- Multi-turn memory helps the assistant interpret follow-up requests.
- Tool descriptions and return values influence how effectively the agent works.
- Filesystem access should be restricted and validated.
- Observability becomes increasingly important as workflows involve multiple tool calls.
Conclusion
Building an agentic assistant helped me explore how language models, workflow orchestration, and external tools can work together to complete multi-step tasks.
LangGraph manages the agent workflow, MCP provides a consistent tool-integration layer, and Streamlit makes the system accessible through a chat interface.
The 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.
Project: Explore Agentic AI Assistant with MCP Tools on GitHub
Live demo: MCP-Assistant
Technologies: Python, LangGraph, MCP, Groq, Tavily, Streamlit, and Docker.
Further reading: LangChain and LangGraph learning resources · MCP documentation
Top comments (0)