What you’ll be able to do
- Design tool discovery for an agent connected to multiple MCP servers
- Resolve naming collisions between tools from different servers
- Architect for a slow or unavailable MCP server without stalling the agent
What you need to know
Multiple servers means multiple sources of truth for “what tools exist”
A single MCP server gives an agent one flat list of tools. The moment a second server joins, the architecture now has two independent, potentially overlapping tool catalogs — and nothing about MCP itself guarantees they won't define a search tool each. Discovery has to happen at connection time and has to reconcile names before the agent ever sees a merged tool list, not react to a collision after it's already caused a wrong call.
The common resolution is namespacing: prefixing each server's tools with a stable identifier (filesystem.search vs web.search) so the model's tool list is unambiguous even when two servers independently chose the same short name. This has to be a design decision made when the second server is added, not a patch applied after the first collision is reported.
A slow server is a latency problem for the whole agent turn
An agent connected to three MCP servers is only as responsive as the slowest one it happens to call in a given turn. If one server hangs on a network call, and the integration architecture has no timeout or fallback around that connection, the entire agent turn stalls — not just the one tool call.
- Set a timeout per server connection, independent of the model's own generation timeout, so a hung server surfaces as a tool error the agent can react to.
- Treat "server unavailable" as its own structured failure, distinct from "tool call failed" — the agent's useful response differs (try a different tool, or tell the user this capability is temporarily down) depending on which one occurred.
Gateway versus direct connection is a fan-out decision
Connecting every agent instance directly to every MCP server works cleanly at small scale and becomes an operational problem at larger scale: N agent instances times M servers is N×M connections to manage, secure, and monitor individually. A gateway that agents connect to once, which itself fans out to the underlying servers, centralizes auth, connection pooling, and failure handling in one place — at the cost of an extra hop and a new single point that itself needs to be reliable.
The exam frames this as a scale question: a handful of agents and a couple of servers rarely justifies gateway complexity; many agents against many servers usually does.
Key concept
Adding a second MCP server multiplies the integration surface — naming collisions, per-server latency, and connection fan-out all become the architecture’s problem, not something MCP resolves for you.
When a scenario mentions multiple connected servers and asks about a "wrong tool called" or "the agent hangs," check for a naming collision or a missing per-server timeout before looking anywhere else.
Practice scenario
search tool for internal-only queries after the Web server was added.Work it through, then open this
Both servers expose a tool literally named search, and nothing in the integration namespaced them before merging the tool lists. The fix is namespacing each server’s tools at discovery time — docs.search and web.search — so the model’s tool list is unambiguous. This should have been decided when the second server was connected, not patched after the misrouted calls were noticed.
Build exercise — Design discovery for a two-server agent
Intermediate · 20 min
What you’ll learn
- Spotting a naming collision before it causes a wrong tool call
- Deciding what happens to an agent turn when one server is slow
- Recognizing when direct connections should become a gateway
-
List the tool names exposed by two MCP servers your architecture might connect, and check for any exact or near-duplicate names.
- Why: Collisions are invisible until two servers are actually connected together — check for them deliberately rather than reactively.
- You should see: Either a clean set of names, or a pair worth namespacing before they’re ever merged.
-
Decide what your agent does if one connected server doesn’t respond within two seconds: proceed without it, fail the turn, or retry.
- Why: Without an explicit answer, the default behavior is “the whole turn hangs,” which is rarely the intended design.
- You should see: A concrete timeout policy you could actually implement, not “it should just work.”
Exam traps
Assuming tool names from different servers won’t collide
Nothing in MCP guarantees unique names across independently developed servers — namespace at discovery time.
Letting one slow MCP server block the entire agent turn
Without a per-server timeout, the agent’s responsiveness is capped by its slowest connection.
Connecting every agent instance directly to every server with no gateway
Fine at small scale; becomes an N×M connection-management problem as agents and servers both grow.
Treating server unavailability as equivalent to a tool-level error
The agent’s best response differs between “this one call failed” and “this whole capability is down.”
Not revalidating tool discovery when a connected server’s tools change
A stale tool list can offer the model a tool that no longer exists or behaves differently.