MCP Protocol in 60 Seconds: A Real Session, Message by Message

A short YouTube demo uses a real session to make MCP (Model Context Protocol) crystal clear. The author moved the tools that were hardcoded into the Agent in the previous episode onto a server built with the official MCP SDK. The tool location changed, not a single line of the Agent's logic was modified, and the final answer is still the same port 8080. This article breaks down the collaboration mechanism behind those 9 JSON messages.

Tools Move House: From Hardcoded to Standalone Server

In the previous episode, the Agent had its tools written directly into the code — change a tool and you'd have to change the Agent. This time, the author built a separate server using the official MCP SDK, with all file system capabilities attached to that server.

On the surface this looks like a purely engineering cleanup, but the implications are significant: tool definitions and the Agent implementation are now fully decoupled. The Agent doesn't need to know how a tool is implemented, where it runs, or what language it's written in — as long as the other side speaks MCP, it's good. Tools went from being "part of the Agent" to being "external capabilities anyone can plug into."

MCP (Model Context Protocol) was initially open-sourced by Anthropic at the end of 2024, with the goal of defining a unified communication standard between large models and external tools and data sources. It uses JSON-RPC 2.0 as its message format and supports two common transports: stdio transport based on standard input/output (inter-process communication, suited for local tools) and HTTP-based Streamable HTTP (suited for remote services). Architecturally, the protocol divides participants into three roles — Host (the host application, such as an editor or Agent runtime), Client (the client inside the host responsible for connecting to a single server), and Server (the service that exposes tools, resources, or prompt templates). This layering lets the same server be reused by different Hosts, which is precisely the premise that makes the "tools move house" scenario in this article possible.

Handshake: First the Agent Asks, Then the Server Answers

At the start of the session, the Agent has no idea what capabilities the other side has. Its first move is to ask: what tools do you have?

The server then returns a list, itemizing each tool's name, description, and input parameters. Only after receiving this list does the Agent know what new cards it now holds in its hand.

This step is the crux of the entire MCP collaboration. It's not that the Agent knows the tools in advance, looks up documentation, and writes adapter code — instead, it's dynamic discovery at runtime. The tools can be new, the Agent may have never seen them, and that doesn't stop it from getting to work.

MCP capability discovery isn't a single step. Once the connection is established, the Client and Server first perform an initialization handshake (initialize / initialized), exchanging protocol version numbers and their respective capabilities (for example, whether the server supports resources, prompts, or tools, and whether the client supports sampling). Only after the handshake completes can the Client call tools/list to fetch the tool list, and the server can afterward proactively send notifications/tools/list_changed to signal that the tool list has changed. In addition, each tool in the tool list carries a JSON Schema describing its input parameters, and the model generates its call arguments based on this schema. Understanding this explains why the Agent doesn't need to know in advance what the tools look like — the metadata is provided at runtime by the server.

Execution: The Agent Forwards, the Server Does the Work

The actual execution phase is even more interesting. When the model proposes "list files," the Agent itself runs nothing.

It simply forwards the call request to the server, which reads the directory, executes the logic, and sends the result back. Here, the Agent acts like a middleman: it receives the model's intent, translates it into an MCP call, and hands the response back to the model. The actual I/O and side effects all happen on the server side.

The benefit of this split is straightforward — permissions, auditing, and sandboxing can all be centralized on the server end, and the Agent neither needs nor should possess these capabilities.

The Loop Doesn't Change: Same Model, Same Task, Same Answer

One easily overlooked point: this change didn't touch the Agent's reasoning loop at all.

Same model, same task, same output — port 8080. The source of the tools changed, the integration method changed, but from the model's point of view, nothing about the world changed. It's still working in a "state a request — wait for result" loop, and it doesn't care who is running that code in between.

This also explains why MCP is easy to integrate: it isn't trying to change the architecture of the model or the Agent, but rather to define a unified slot for the tool layer.

Behind the Scenes: 9 JSON Messages Are Enough

The whole session isn't as complicated as you might imagine. The author notes that underneath, it's just 9 JSON messages round-tripping over the pipe — the request and response for the tool list, the request and response for the call, plus a bit of process control.

Once the server is set up, any Agent that speaks MCP can plug right in. This means the cost of reusing tools goes from "rewriting them for every Agent" to "build once, available to everyone."

From a protocol design perspective, what MCP does is very similar to what LSP did back in the day for unifying editors and language services: it compresses an N×M adaptation matrix into N+M. The more thriving the tool ecosystem, the more pronounced this benefit becomes.

LSP (Language Server Protocol) is a communication standard between editors and language intelligence services that Microsoft proposed for VS Code around 2015. It reduced the N×M adaptation problem — where every editor once had to write a separate plugin for every language — into an N+M model where an editor implements an LSP client once and a language implements an LSP server once, and they can connect. This dramatically lowered the cost of ecosystem expansion. MCP's design philosophy is highly consistent with this: it likewise compresses the adaptation matrix between large model applications and tools into N+M. The difference is that LSP targets code editing scenarios, while MCP targets the model's tool invocation and context injection scenarios.

Summary

The point of this demo isn't how complex the protocol itself is, but that it proves one thing: swapping in a new set of tool sources for an Agent requires no changes to the model and no changes to the loop — just swap in a server that speaks MCP. In the 60-second session, the one actually making decisions is still the model, the one actually doing the work is the server, and connecting the two is just 9 JSON messages.