One flat list of tools

Connect five servers and the model sees one list of tools, all of it in the prompt, all of it trusted the same. Cost and risk both add up.

By the end of this lesson you can

describe how a host merges tool lists from several servers;
explain name collisions and how namespacing fixes them;
name three consequences of a flat list: failure isolation, selection accuracy, shared trust.

Servers in, one list out

The host keeps one client per server and merges every tools/list into a single list for the model. The model never sees servers, only tools. Two servers that both call a tool search collide unless the host renames them.

Merging tool lists

The host has one client per server. Each client calls tools/list on its own server.
Each server answers with its tools. Neither knows the other exists.
The host merges them into one flat list for the model. search and create_issue now appear twice.
The model asks for search. The host cannot tell which server it meant.
Hosts therefore prefix names with the server, mcp__server__tool. Every name is unique and routes to exactly one client.

Make two servers collide

github server

jira server

What the model sees

Three consequences of a flat list

Failure isolation: each server is its own connection. One crashing should not take the others down, and in the stateless revision a restart loses nothing but in-flight calls (the next lesson plays this out).
Selection accuracy: many similar tools make the wrong choice more likely. Descriptions are prompts, and their quality is now your problem. Even with unique names, two vague search tools confuse the model.
Cross-server trust: a malicious server's tool description can steer the model to misuse a trusted server's tools. All descriptions share one trust domain: the prompt (lesson 9).

Key idea

Context cost is additive: every schema from every server is in the prompt on every turn, unless the host uses tool search or lazy loading. Lesson 14 puts numbers on it.

Quick check

Does the model know which server a tool comes from?

Yes, the protocol tells it
Only if the host puts it in the name or description; it sees one flat list
Yes, it calls server/discover itself

The model sees tools, not servers. Prefixes like mcp__github__search are how hosts make the origin visible and routing unambiguous.

Names are now unique. What can still go wrong with two search tools?

Nothing
The model can still pick the wrong one if their descriptions are vague
The host will crash

Selection is done by the model reading descriptions. Unique names fix routing, not judgement.

Recap

One client per server; the host merges every tools/list into one flat list.
Collisions are solved by namespacing: mcp__server__tool.
Watch failure isolation, selection accuracy, and the single trust domain all descriptions share.