Skip to content

8.2 MCP in Plain Language

Before MCP, every AI-to-tool connection was custom carpentry: this assistant integrates that database this way, that one that way, N tools × M assistants = chaos. MCP — the Model Context Protocol, an open standard Anthropic released and the industry adopted — replaced the chaos with one socket. This lesson gives you the working model of how it fits together, minus the spec-reading.

What you will learn

  • Explain the USB-C analogy accurately — what's the port, the device, the cable.
  • Name the moving parts: host, server, tools, resources — and each one's job.
  • Follow one real request end-to-end through the pieces.

Builder principle

You don't need to build the plumbing to be great at using it — but you do need to know what's plumbing and what's magic. (Spoiler: it's all plumbing.)

The USB-C analogy, done right

Before USB, every device needed its own port. USB fixed it with one standard plug: any device, any computer, matched expectations on both sides.

MCP is that, for AI:

  • The computer = your AI application (Claude Code, Claude desktop, others) — MCP calls this the host.
  • The device = an MCP server: a program that exposes one system's capabilities. A Postgres server, a browser-automation server, a GitHub server, a Slack server.
  • The plug shape = the protocol itself: a fixed way for hosts to ask "what can you do?" and servers to answer "here's my menu" — and then to call items off that menu.

One standard means the ecosystem compounds: anyone who builds a server has equipped every MCP host at once; every host improvement benefits every connection. That's why the server catalog went from dozens to thousands so fast — and why learning MCP is learning infrastructure, not a product feature (your 2.5 tool filter would approve: open standard, no island).

The menu: tools and resources

When Claude Code connects to a server, the server presents its menu. Two kinds of items matter to you:

Tools — actions the agent can invoke, each with a name, a description, and defined inputs. A database server might offer:

query        — run a read-only SQL query    (input: the SQL)
list_tables  — show all tables               (input: none)
describe     — show a table's columns        (input: table name)

Here's the beautiful part, and it should feel familiar: the agent chooses tools by reading their descriptions — exactly how Skills activate (7.1). You say "which customers signed up this week?"; the agent sees query on the menu, recognizes the match, writes the SQL, calls the tool. Nobody hardcoded that flow. Description-driven matching, all the way down.

Resources — data the server can supply as context (files, schemas, documents), for when the agent needs to read something the system holds rather than do something to it.

One request, end to end

"Which of my invoices are overdue?" — with an accounting MCP server connected:

1. You ask, in plain language.
2. Agent scans its available tools — sees list_invoices on the
   accounting server's menu. Description matches. (GATHER begins)
3. Agent calls list_invoices with status=unpaid.
4. Server does the actual API work, returns structured data.
5. Agent reasons over the results — compares due dates to today,
   sorts by amount. (the model's home turf)
6. You get: "Three overdue: Acme 47 days ($2,400)..." (VERIFY-able
   against your real books — and you should, first few times.)

Notice who did what: the server handled system access (auth, API calls, data format); the model handled understanding, judgment, and language. MCP's whole design is that division of labor — servers are hands, models are brains, the protocol is the nervous system between.

And notice what the agent did not get: your accounting password. The server holds its own credentials; the agent only gets the menu. That separation is a load-bearing wall in 8.5's security story.

Everything above is the working mental model for this course. Before the next lesson's hands-on, remember that connecting a server is configuration rather than proof that the connection is appropriate. The trust decision comes first.

Under the hood for the curious: JSON-RPC over stdio for local servers or HTTP for remote ones; servers declare capabilities at handshake; tool schemas are JSON Schema. Use the current Model Context Protocol documentation and official SDK guidance when estimating or implementing a server. Scope and security review determine the work; the course does not assign a universal build time.

Try it now

Window-shopping trip (connections next lesson):

  1. Browse the MCP server ecosystem — search "MCP servers" or start from modelcontextprotocol.io's examples.
  2. Find servers for three systems from your 8.1 gap list. Note who publishes each — official vendor? Community? (8.5 will care a lot.)
  3. For your starred system: read its server's actual tool list. Which tools would your delegated task use? READ tools or WRITE tools?
  4. Journal: one thing on a server's menu you wouldn't want enabled. (There's always one. Finding it is the beginning of security judgment.)

Check your understanding

  • Map the USB-C analogy: what are the computer, the device, and the plug shape?
  • What's on a server's menu, and how does the agent choose from it? (What Chapter 7 mechanism does this rhyme with?)
  • In the invoice walkthrough, what did the server own vs. the model?
  • Why doesn't the agent hold your accounting password, and why will that matter later?