How do you diagram MCP architecture?

An agent with an MCP client does not need bespoke code for each tool it calls. This is the whole reason the protocol exists, and the diagram is shaped by it: the Agent talks to an MCP Client, the client speaks the protocol to an MCP Server, and the server exposes whatever it wraps. Here that is a Knowledge Base, a Code Sandbox and a Memory store.

The bars matter. |Knowledge Base, Code Sandbox, Memory| is a choice, and a choice sends the message down one branch per pass, cycling in the order written, so the Knowledge Base lights on the first pass, the Code Sandbox on the second and Memory on the third. Per turn the agent asks for one capability, and the server does not dispatch to everything it wraps. Braces would draw all three firing at once, which is not what happens.

Line two, MCP Server -> Agent, adds no boxes. Two arrows come out of it, server back to client and client back to agent, in a second flow that starts only after the outbound pass has landed (there is a half-second pause between flows). A still image collapses that into a double-headed arrow. Played, it keeps the order, request out and result back over the same boundary.

That boundary is the point of MCP. Everything left of the server is the agent’s problem and everything right of it belongs to whoever wrote the server. Add a fourth capability inside the bars. Nothing on the left changes.

Now the two limits. Client and server share an icon, because the AI vocabulary matches the word MCP to its Tool icon and has no separate concept for the client side, so the boundary is carried by the layout rather than by the shapes. And a real deployment runs several servers next to each other, while this draws one, because one server is the case to understand first.

Deciding whether to call a tool at all is a different pattern, the ReAct agent, and it has its own page: the model picks between answering and calling, and the tool result comes back for another turn.