Writing

MCP Architecture, Primitives, and Call Flow

·3 min read

MCP becomes much easier once you separate the three ideas:

  • The roles in the system
  • The capabilities a server exposes
  • The lifecycle of a request

Together, these form the mental model you need before building or using MCP servers.

The Three Roles

MCP has three core roles:

  • Host
  • Client
  • Server

The host is the AI application the user interacts with. It could be a desktop assistant, an IDE, a coding agent, a chat app, or an internal company agent.

The host owns the user experience. It receives the user's request, shows model responses, asks for confirmation, and decides which connected servers are available in the current context.

The client is the connector inside the host.

An MCP client speaks MCP to exactly one MCP server. If a host connects to five MCP servers, it usually has five clients running in parallel.

The client handles protocol details such as initialization, discovery, tool calls, results, and notifications.

The server exposes capabilities from an external system.

That external system could be GitHub, Slack, a database, a SaaS product, a local filesystem, or an internal workflow engine. The server turns that system into agent-friendly capabilities.

The Main Primitives

MCP servers expose capabilities through a small set of primitives.

The three server-side primitives to understand first are:

  • Tools
  • Resources
  • Prompts

Tools are functions the model can invoke.

Examples:

  • github_create_issue
  • db_run_query
  • stripe_refund_charge
  • linear_search_issues

A tool has a name, a natural-language description, an input schema, and a structured result. Tool descriptions matter because the model uses them to decide when a tool is relevant.

Resources are read-only pieces of context.

Examples:

  • File contents
  • Database rows
  • API responses
  • Configuration blobs
  • Documentation pages

The key distinction is simple: a resource is something the model reads. A tool is something the model calls.

Prompts are reusable templates or workflows provided by the server.

Examples:

  • Review this code change
  • Summarise this incident
  • Draft a support response
  • Generate a release note

Prompts are useful when a connected system knows the shape of a workflow and wants to offer it to the user or host in a reusable form.

How the Pieces Fit Together

A typical MCP flow looks like this:

  1. The user asks the host for help.
  2. The host gives the model access to discovered MCP capabilities.
  3. The model decides whether it needs a tool or resource.
  4. The host's MCP client sends a request to the MCP server.
  5. The server executes the action or returns the requested context.
  6. The result comes back to the model through the host.
  7. The host shows the answer or asks the user for confirmation before a sensitive action.

The agent does not directly speak to your REST API or database. It works through the MCP layer.

How an MCP Session Works

MCP is built on JSON-RPC 2.0.

That means messages are structured as requests, responses, and notifications. The protocol can run over different transports, but the message model stays consistent.


The two common transports are:

  • stdio for local, single-user integrations
  • Streamable HTTP for remote or multi-tenant deployments

A session usually follows this lifecycle:

  1. Initialise: the client and server exchange protocol version, capabilities, and basic identity information.
  2. Discover: the client lists available tools, resources, and prompts through calls such as tools/list, resources/list, and prompts/list.
  3. Decide: the model reads the user's request and chooses whether it needs an MCP capability.
  4. Invoke: the client sends a tools/call request or asks for a resource.
  5. Return: the server sends a structured result back to the client.
  6. Notify: the server may send updates when tool lists, resources, logs, or long-running operations change.
  7. Shutdown: the session closes when the host exits or the integration is removed.

Design Implication

Do not turn everything into a tool.

If the model only needs to read something, a resource may be better. If the user should explicitly choose a reusable workflow, a prompt may be better. If the model needs to perform an action or query a system dynamically, a tool is probably the right fit.

The best MCP servers use the right primitive for the right job.

The Takeaway

The host is the AI app. The client is the connector. The server exposes capabilities.

Tools let the model act. Resources let it read. Prompts give users reusable workflows.

Once you understand those roles, primitives, and session flow, MCP becomes much less mysterious.

Full knowledgebase: https://sagart-cactus.github.io/learn-mcp/

Originally published on LinkedIn.