Computer Communication: From stdin to MCP

/ Naixian Zhang

When I first started learning networking, every acronym felt like another rabbit hole:

HTTP, REST, TCP, UDP, SSE, WebSocket, RPC, gRPC, MCP…

They all seemed related, but no one explained how they fit together into one coherent picture.

Eventually, I realized they are simply different layers solving different communication problems.

Level 1 — Two processes need to talk

At the lowest practical level, two programs simply need a way to exchange information.

If they’re running on the same computer, they don’t need the network at all.

They can communicate through mechanisms like stdin/stdout, pipes, or shared memory.

For example, when Claude Desktop launches a local MCP server, it doesn’t send HTTP requests. It starts the Python process and exchanges JSON messages through stdin/stdout.

Conceptually, this is already RPC (Remote Procedure Call)—one process asks another process to execute a function—but it’s entirely local.

Level 2 — What if the processes are on different computers?

Now imagine moving that MCP server onto a Linux server inside your company.

Suddenly, stdin/stdout isn’t enough.

The computers need:

  • IP addresses
  • Routing
  • Network protocols
  • Reliable delivery

This is where TCP and UDP come in.

TCP

TCP guarantees:

  • packets arrive
  • packets stay in order
  • lost packets are retransmitted

Perfect for:

  • banking
  • APIs
  • databases
  • AI tool calls

Reliability matters more than speed.

UDP

UDP makes almost no guarantees.

Packets may:

  • arrive late
  • arrive out of order
  • never arrive

Why would anyone want that?

Because sometimes fresh information matters more than perfect information.

Examples:

  • online games
  • robotics
  • voice calls
  • live video

If one frame disappears during a Zoom call, it’s usually better to skip it than pause the conversation waiting for a retransmission.

Level 3 — Now we have a network. How should applications communicate?

TCP only moves bytes.

Applications still need a language.

One of those languages is HTTP.

HTTP is simple:

Client asks → Server answers.

Example:

GET /companies/NVDA

Server:

{
  "ticker": "NVDA",
  "name": "NVIDIA"
}

Request.

Response.

Done.

REST — Think in resources

REST isn’t a protocol.

It’s an architectural style built on HTTP.

Instead of asking a server to execute functions, REST asks for resources.

GET /users/123

means:

Give me the representation of User #123.

You interact with nouns:

  • users
  • companies
  • portfolios
  • orders

REST is resource-oriented.

RPC — Think in functions

RPC takes a different philosophy.

Instead of asking for resources, you ask another machine to execute a function.

calculateRisk(portfolio)

or

searchCompanies(keyword)

It feels just like calling a local function, even though the function actually runs somewhere else.

REST asks:

“Give me this object.”

RPC asks:

“Run this operation.”

gRPC

gRPC is simply a modern, high-performance implementation of RPC.

It lets one service call functions on another service efficiently over the network.

Many cloud systems and microservices use gRPC internally.

SSE — Sometimes one response isn’t enough

Normal HTTP looks like this:

Request
↓
Response
↓
Connection closes

But sometimes you want continuous updates.

That’s what Server-Sent Events (SSE) does.

Connect
↓
event...
↓
event...
↓
event...
↓
connection stays open

Instead of repeatedly asking,

“Anything new?”

the server pushes updates whenever they happen.

This is why SSE is commonly used for streaming AI responses.

Where does MCP fit?

This is the part that made everything click for me.

MCP (Model Context Protocol) is essentially RPC for AI.

Instead of another program calling functions, an AI model calls tools.

For example:

search_company("NVIDIA suppliers")

Claude doesn’t know how to search a database.

It sends a structured request to an MCP server, which executes the function and returns the result.

Whether that server is:

  • running locally through stdin/stdout, or
  • running remotely over HTTP/SSE,

the mental model stays the same:

The AI is calling a function on another process.

The hierarchy that finally made sense

Application
    |
    |  MCP
    |  REST
    |  RPC
    |  gRPC
    |
HTTP / SSE / WebSocket
    |
TCP / UDP
    |
IP
    |
Operating System
    |
Hardware

Each layer solves a different problem.

  • TCP/UDP move data.
  • HTTP defines conversations.
  • REST organizes data as resources.
  • RPC organizes communication as function calls.
  • MCP standardizes AI tool calling.
  • SSE keeps the conversation alive for streaming.

They’re not competing technologies—they’re building blocks stacked on top of one another.

My biggest takeaway

For a long time, networking felt like memorizing unrelated acronyms.

Now I think of it much more simply:

  • TCP vs UDP → How should data travel?
  • HTTP vs SSE → How should conversations flow?
  • REST vs RPC → Should I request resources or execute functions?
  • Local vs Remote → Are the processes on the same machine or across a network?
  • MCP → A standardized RPC layer that lets AI models call external tools.

Once you organize everything by the problem each technology is solving, the entire networking landscape becomes much easier to navigate.

Leave a Reply