How MCP Actually Works — A Practical Walkthrough - Thoughts on Building Data & AI Systems

We covered what MCP is. Now let’s trace what actually happens during a real interaction — step by step.

Key idea: MCP doesn’t decide what action to take — the model decides. MCP defines how requests are structured, transmitted, and safely returned.

If you’re anything like me, knowing what something is only gets you halfway. You want to know how it works. What actually happens when Claude asks GitHub for your open issues? What messages get sent? What’s happening behind the scenes?

The Two Layers of MCP

MCP is built in two layers.

The Transport Layer is how messages physically travel from one system to another.

The Data Layer defines the meaning and structure of those messages.

Mental model:
Transport layer → moves messages
Data layer → defines meaning

You can change the transport without changing the message format. This separation makes MCP flexible.

Transport: How Messages Travel

STDIO (Standard Input/Output)

This is the local transport. The AI application launches the MCP server as a local process and communicates using the operating system’s standard input and output streams.

The client writes a JSON message to the server’s stdin. The server processes it and writes the response to stdout.

No network, extremely fast, and ideal for local tools such as file systems or local databases.

Limitation: both programs must run on the same machine.

Streamable HTTP

This is the remote transport. The MCP server runs as a web service. The client communicates over HTTP.

The client sends POST requests and may receive streaming responses using Server-Sent Events (SSE).

Example: STDIO is like speaking to someone sitting next to you. Streamable HTTP is like calling them remotely.

The Data Layer: What Messages Say

All MCP messages follow the JSON-RPC 2.0 structure.

Request:
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Response:
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": { "tools": [...] }
}

The method defines the action. The id connects response to request. The result carries the data.

A notification is similar but has no id — meaning no response is expected.

The Lifecycle

Phase 1: Initialization

The client and server introduce themselves and exchange capabilities.

Client sends initialize request
Server responds with supported features
Client confirms initialization

No other actions occur before this handshake.

Phase 2: Operation

The client requests tools, calls them, and receives results.

tools/list
tools/call
resources/read
prompts/list

Phase 3: Shutdown

The connection closes. STDIO closes the process. HTTP closes the session.

Putting It All Together

User asks:

What are the open issues in the frontend repo?

User → Model → MCP Client → MCP Server → GitHub API
                                     ← Results

The model formats the results into a human-readable answer.

Why Not Just Call the API?

Discovery of tools
Capability negotiation
Transport independence
Session context
Model independence

Security

MCP manages communication. Authentication is handled by the server implementation.

Recap

Handshake
Discover tools
Model chooses tool
Request sent
Server executes
Result returned
Model answers

Takeaway: MCP standardizes communication and lifecycle — the model decides actions, MCP guarantees reliable execution.

Next post: building a real MCP server.