Adding Resources in Multi-Server MCP

Our agent is now an effective orchestrator, capable of managing a diverse set of tools and user-driven prompts from both the weather_server and the task_server. However, its awareness of the world is still incomplete. While we have seen how resources can provide context from a single source, a truly powerful assistant must be able to draw upon data from multiple, specialized domains.

The next orchestration challenge is managing resources across multiple MCP servers. How can the client discover resources exposed by multiple servers? How can it read a resource from one server and provide that context to a workflow that uses capabilities from another? In this lesson, we will expose resources from both servers and update the client to discover, read, and route resource content from connected MCP servers, allowing the agent to incorporate context from multiple servers into its workflows.

Expanding our multi-server scenario

In earlier lessons, we built an agent with the ability to read the delivery_log resource from the weather_server. But in any real-world application, relevant data is rarely stored in one place. It is often distributed across different systems and domains. Let’s expand our scenario to reflect this reality. Imagine our user, a team lead, not only needs to check the weather for deliveries but also needs to manage action items from their weekly sync. These action items are stored in a separate meeting_notes.txt file, which is naturally managed by the task_server.

This presents a clear orchestration challenge for our client:

• How can it present a unified view of all available data sources, the delivery log from the weather_server and the meeting notes from the task_server?

• When a user wants to load the meeting notes, how does the client know to query the task_server specifically?

• How can we empower the user to load the meeting_notes to create new tasks, and then seamlessly switch contexts to load the delivery_log to check for weather delays?

The simple client we have now cannot handle this distributed context. It needs to be upgraded into a more intelligent orchestrator that can manage and present a catalog of resources from our entire multi-server ecosystem.

To enable our client to solve this orchestration problem, our first step is to ensure that both servers are properly configured to expose their unique data resources.

Adding resources to our MCP servers

We will now enhance each of our existing servers, using the @mcp.resource() decorator to expose ...