MCP Complete Tutorial - Connect Local AI Agent (Ollama) to Tools with MCP Server and Client

Model Context Protocol (MCP) is positioned as a standardized way to connect AI models to external tools and data without hand-building bespoke integrations for every service. Instead of wiring an agent directly to systems like GitHub, Slack, or a database, MCP introduces a host/client/server pattern where the client discovers what a server can do—its available resources, tools, and prompts—then calls those capabilities through a common interface. The practical payoff is portability: a tool exposed via MCP can be plugged into different AI applications using the same protocol mechanics.

The tutorial frames MCP as an “adapter” layer over AI applications. Under the hood, MCP uses JSON-RPC for request/response messaging and supports two main transports. For local setups, communication can run over standard input/output. For more production-friendly deployments, it can run over HTTP using Server-Sent Events (SSE), enabling streaming responses. Before any tool calls happen, MCP performs a handshake where both sides advertise capabilities and versioning, so the client knows what resources, tools, and prompts the server offers.

MCP servers provide three core building blocks. “Resources” act like context endpoints (similar in spirit to REST GET requests), returning data based on parameters such as a resource path. “Tools” are the actionable functions an agent can invoke; they include parameter schemas and documentation so the client can present them correctly to the model. “Prompts” let servers supply reusable, parameterized prompt templates, shifting prompt construction away from the client.

A key implementation walkthrough builds a minimal FastAPI-style MCP server that exposes a single tool, list tasks, which returns a filtered list of to-do items based on max results. The server is created with an MCP instance configured with a name, host, port, and an SSE transport path. Running the server locally also enables an MCP inspector endpoint that lists discovered resources, prompts, tools, and health checks. Through the inspector, the tool’s input schema becomes visible, and direct tool calls return the expected task list.

The tutorial then connects a custom MCP client to that server using the official MCP SDK. The client constructs the server URL, opens bidirectional streams, initializes the session, and queries available tools. Tool metadata—names, descriptions, and JSON-schema-like input types—arrives from the server, and the client can invoke a tool by name with structured arguments. The response comes back as content suitable for downstream agent logic.

From there, the tutorial scales the concept into a complete to-do application. It defines an in-memory task manager (task objects with id, name, and completion status) and wraps its operations—get tasks, add task, remove task, complete task—into MCP tools. On the client side, the MCP tool list is converted into LangChain-compatible structured tools so an LLM can decide when to call which MCP tool. The agent runs an iterative loop with a max-iteration guard, using a system prompt that instructs the model how to represent task completion (e.g., emoji markers) and when to invoke tools.

Finally, everything is wired into a Streamlit UI. With a local Ollama model (configured as Qwen 2.5) running alongside the MCP server, users can ask questions like “What are my tasks for today?” or request new items, and the app translates those requests into MCP tool calls (e.g., list tasks or add task) and renders the agent’s updated results. The result is a working example of how standardized tool access can turn an AI agent into a functional app backend without custom glue code per tool.