How do you diagram MCP architecture?

The Model Context Protocol exists so an agent does not need bespoke code for each tool it calls. The Agent talks to an MCP Client, which speaks the protocol to an MCP Server, and the server exposes whatever it wraps: a Knowledge Base, a Code Sandbox, a Memory store.

The pipes are a choice, and here the choice is the truth. A server does not dispatch to everything it wraps on every call; the agent asks for one capability per turn. Watch two passes of the animation and you see it, because a choice sends one message per pass and takes a different branch the next time round. Braces would claim all three fire at once, which is exactly the kind of quiet lie an architecture diagram tells when nobody is checking.

The second line is the other half of the argument. MCP Server -> Agent does not draw one long arrow backwards; the answer retraces the route it came by, back through the client, after the outbound pass has finished. That ordering, request out and result back across the same boundary, is the part a still image flattens into two arrowheads.

The boundary is the point. Everything left of the server is the agent’s problem; everything right of it belongs to whoever wrote the server. Add a fourth capability and the left-hand side does not change. That is what MCP sells, and it is visible here as a shape.

Two limits. The client and the server render with the same icon, because the vocabulary has one concept for “thing that speaks a tool protocol” and MCP has two, so the boundary is carried by the layout rather than the shapes. And a real deployment runs several servers side by side; this draws the single-server case because it is the one worth understanding first.

If you want the loop that decides whether to call a tool at all, that is a different pattern with its own page: the ReAct agent, where the model chooses between answering and calling, and the result comes back for another turn.