Adding Resources in Single-Server MCP
Learn what MCP resources are and how to implement them in a single-server application, enabling an agent to read and use external data as context for its tasks.
The agent we built is now capable of performing actions using tools and following guided workflows with prompts, but it remains entirely unaware of the world of data around it. It cannot read a file or consult a log to inform its reasoning. This is the role of MCP resources, the final core component that gives our agent the ability to ingest and understand external context. In this lesson, we will complete our agent’s foundational capabilities by implementing a resource, making it truly context-aware.
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.
