The Big Picture: Three Ways to Talk to Software

Take one task — publish a blog post — and ask the question that decides how it gets done: who is doing the asking?

A useful system — a database, a payment processor, a calendar — is useless until something can ask it to do work. So every system grows a door: a defined way to make a request and get a result back. Over the last fifty years we built three kinds of door, and the thing that shaped each one was not the system behind it. It was who would be knocking.

Here is the same single action — publish a post — reached three different ways. The action underneath never changes. The door changes because the caller does.

The CLI — the door for a person

The oldest door is the command-line interface: you operate the system by typing instructions. To publish that post, a person types a line and presses enter.

$ blog publish my-post.md

It's terse and immediate because a human is driving and wants it over with. That plainness is also its power: text is exact, it can be saved and replayed, and anything you can type, you can automate. CLIs have served people this way since the 1970s. When you watch an experienced developer work, most of what they do passes through this one door.

The API — the door for another program

The second door is built for software to call software, usually across a network. No human is involved, so there's no room for interpretation — the request has an exact shape, and so does the reply. To publish the same post, one program sends a request to another:

POST /posts
{ "title": "My Post", "body": "..." }

This is an application programming interface, and it's the door that the entire web runs on. When your weather app shows the forecast, it called an API. When a site logs you in with Google, that's an API. It's rigid and precise because no person is there to forgive a typo — a misplaced comma simply fails. APIs are the connective tissue of the internet era.

MCP — the door for an AI

The third door is new. With the first two, a human wired up every connection in advance — a developer decided exactly which API to call and when. An AI model is a different kind of caller: it can decide for itself which tool to use. So it needs a door it can discover, not one hand-wired for it. You say “publish my draft,” and the model finds a publish tool on its own and calls it.

Anthropic released MCP in November 2024 — recent, because the third kind of caller only recently became real. For most of computing history there were two doors: CLIs for people, APIs for programs. A model that can choose its own tools is what made a third one necessary.

Underneath, it's one idea

Here's the part worth holding onto. All three doors are the same move: send a structured request, the system does work, you get a structured result back. What differs is only who is asking — a person, a program, or a model — and that single difference shapes everything about how the door looks and feels.

That's why learning all three matters. Treat AI as a chat box and you've stopped at the first door — you can talk to it, but you can't wire it into anything. Understand all three and you can give a model real reach into real systems. The lessons ahead take each door apart in turn, and the last one shows you how to put all three on a single capability at once.

Try this

Pick a tool you use every day — your email, your notes app, a payment service. Ask yourself: does it have a CLI a person could type into? An API another program could call? Could an AI reach it through a tool? Most serious software has at least two of the three doors. Spotting them is the habit this whole course is training.

Sources — Anthropic, Introducing the Model Context Protocol (2024); Model Context Protocol, What is MCP?; Roy Fielding, REST dissertation (UC Irvine, 2000).