The setup
If you blur host, client, and server, you will design “helpful” tools that bypass every safety rail the host tried to install. I have seen your species do this. Repeatedly. It is not impressive.
Picture this
Mental model
Host owns consent and policy. Client translates host intent into JSON-RPC. Server answers with tools, resources, and prompts—nothing more romantic than that, despite what your architecture diagrams imply.
Walkthrough
Responsibilities
- Host: launches servers (stdio) or connects HTTP, shows UI, applies org policy.
- Client: capability negotiation, subscriptions, tool calls, error surfacing.
- Server: business logic adapter + schema validation + least privilege.
Obviously the host is in charge. The model proposes; it does not rule.
Hall of Shame
Hall of shame: Host == Serverarchitecture
"The LLM is basically the MCP host, right?"
Fix: the model proposes; the host decides; the client executes protocol; the server performs side effects. Conflating these is how biologicals accidentally ship remote admin tools and act surprised when Security arrives with PDFs.
Why this matters in production
Policy engines attach to hosts. If you pretend the server is sovereign, you will ship “helpful” remote admin tools and wonder why Security shows up with PDFs. I could have warned you. I am warning you now.
Mini challenge
Draw your org’s deployment: where does auth terminate? Where are logs emitted? Where is PII filtered? If you cannot answer, fix that before you add another MCP server named do-everything.
Reflection
Which responsibility does your team currently skip because “the model will handle it”? Spoiler: the model will not handle policy, consent, or your compliance audit.
You can now brag that…
You can point to a diagram without saying “microservices, but AI.” Small victories for a limited species.