Adding Resources in Single-Server MCP

The agent we built can now perform actions with tools and follow guided workflows with prompts, but it still lacks access to external context such as files, logs, or other data sources. Without additional context sources, it cannot retrieve file contents or inspect logs to inform its responses. MCP resources address this need by exposing contextual data to clients that can then provide it to the model. In this lesson, we will add resource access to the agent, allowing it to incorporate external context into its responses.

Introduction to resources

At its core, an MCP resource is a discoverable, read-only data source that a server can expose. Think of resources as the files on an agent’s virtual desk. They can be text files, log entries, database records, or even the output from a previously run tool. The primary purpose of a resource is to provide the LLM with specific, timely context that it wouldn’t otherwise have access to. By making the agent aware of these resources, we enable it to answer questions and perform tasks that require knowledge of this private data.

Resources vs. tools vs. prompts

It is essential to understand the distinct roles these three elements play in our agentic system:

• Tools: Tools are for action. They are executable functions that the agent calls to interact with the world.

• Prompts: Prompts are for guidance. They are user-initiated templates that orchestrate a complex reasoning workflow for the LLM.

• Resources: Resources are for context. They are passive, read-only data sources the agent consults to become informed before acting.

Scenario: Creating a context-aware logistics agent

Let’s imagine our weather agent is now assisting a logistics coordinator. This coordinator maintains a simple text file, delivery_log.txt, which lists all the destination cities for today’s shipments. Currently, their process is entirely manual: they read each city from the file and then ask our agent to check the weather, one by one. This is not only tedious but also inefficient. The agent itself has no direct way to access the delivery log; it’s completely reliant on the user feeding it information piecemeal.

To solve this, we will enhance our weather_server by exposing the delivery_log.txt as a discoverable resource. This will allow the client application to load the entire list of cities into the agent’s context in a single step. Once the agent is aware of the delivery schedule, the user can issue a simple command like, “Check the weather for all cities in this log and report any potential delays,” empowering the agent to perform its get_weather task based on the provided data.

Adding a resource to our weather_server

We’ll begin by adding the delivery_log.txt resource to our weather_server.py. Our ...