Class 13 taught you that an API is a counter between two pieces of software: one program sends a structured request, another returns structured data. Class 14 taught you who is allowed to approach that counter, and with which keys.

Now a harder question arrives. Your AI agent may need dozens of counters — files, databases, calendars, deployment services, company filings. Each one has its own address, its own field names, its own authentication. How does the agent discover what it can use, and invoke it in a consistent way?

That discovery problem is what this lesson solves.

From APIs to a discovery problem

Think back to the OpenRouter call from Class 13. Your app knew exactly which endpoint to call and which JSON fields to send, because you read that one page of documentation.

Now imagine a research agent. It needs to search company filings, read a local project folder, check the time in three zones, and fetch a public documentation page. That is four different services, four shapes of request, four ways of authenticating. If every agent had to learn every service's private dialect from scratch, every integration would be custom work — and every agent would break whenever one service renamed a field.

Software faced this kind of mess before. The answer is usually a standard: agree once on how capabilities are described and invoked, so many programs can interoperate without custom wiring each time.

MCP — the Model Context Protocol — is that kind of standard for AI systems. It is an open standard for connecting an AI application to external tools and context in a consistent, discoverable way.

Put simply: an API is how one service accepts requests. MCP is how an agent finds out which tools exist, what inputs they expect, and how to call them through one consistent shape.

The five pieces

MCP has a small vocabulary. Learn these five terms and you can read any MCP diagram:

• Host. The AI application you actually use — for example, a coding assistant, a chat app with tool access, or an agent workbench. The host is the program the human talks to.
• Client. The connection the host manages on your behalf. One host can hold several clients, one per connected server. You rarely configure a client directly; the host sets it up from the server information you give it.
• Server. A program that exposes capabilities — tools, readable information, or reusable instructions. A server sits between the agent and the real thing: files on your disk, a database, or a provider's API.
• Tool. An action the agent can request through the server: search filings, read a file, convert a time zone, create a preview deployment. The server runs the action; the agent only asks.
• Resource. Information the agent can read through the server: a file's contents, a deployment status, a product catalog. Reading is not doing — a distinction Lesson 15.2 makes precise.
• Prompt / prompt template. A reusable guided instruction a server can offer, such as "prepare a release checklist from this repository." Think of it as a pre-written work order the agent can fill in.

The model itself never touches your files or the network directly. It decides *what to ask for*. The server supplies *the function that does it*. That separation matters for everything in Lessons 15.3 and 15.4.

Follow one request through the system

Here is the flow to memorize:

Human → AI host / agent → MCP client → MCP server
                              ↓
                      tools, resources, prompts
                              ↓
                    files / database / API / service

Walk it with a concrete example. You ask a research agent: "File the latest filings from three competitors, with citations."

1. You give the task to the host. 2. The host, through its client connection, asks the research server: "What tools do you offer?" The server answers with a machine-readable list — search filings, retrieve filing, list saved notes. 3. The agent chooses search_filings with named fields like company and filing_type, the same way an API request carries named JSON fields. 4. The server validates those inputs, calls the underlying filing database or API, and returns structured results. 5. The agent summarizes the results with citations and proposes the next step.

Nothing about this makes the model smarter. MCP does not make an agent wise, correct, or automatically trusted. It gives a model-facing application a structured connection to capabilities — nothing more, nothing less. A badly designed tool, a stale database, or a careless permission still produces bad outcomes through a perfectly working MCP connection.

Local process or remote service?

An MCP server can run in two places, and the difference matters for safety:

• Local process. The server runs on your own machine — for example, a filesystem server that can see one folder you named, or a Git server pointed at a practice repository. Local servers are excellent for learning because you can see exactly what is exposed. Nothing leaves your computer except what you approve.
• Remote service. The server runs on someone else's computer and reaches you over the network — for example, a hosted company-data service. Remote servers are convenient, but every call sends data outward, and you depend on that operator's security and uptime.

When you are learning, prefer local. A local server pointed at a throwaway folder teaches you the whole pattern — list capabilities, inspect inputs, call one read action — without risking real data.

Why a standard beats custom wiring

Without MCP, each of your agent's powers would need bespoke code: one integration for files, another for the database, another for each provider API, each with its own calling convention. Add a fifth service and you write a fifth integration.

With MCP, the agent learns one pattern — ask the server what it offers, send named inputs, receive structured results — and every conforming server speaks it. New capability, same shape. That is the whole payoff: less custom glue, more predictable behavior, and a permission boundary you can inspect in one place instead of five.

Check your understanding

1. In your own words, what problem does MCP solve that a single API does not? 2. Who runs the action — the model or the server? Why does that distinction matter? 3. Name the five MCP pieces and one sentence for each. 4. Why is a local server a safer first experiment than a remote one?

Exercise: design a tool shelf

For an imagined "research my competitors" agent, name three tools and two resources it would need. For each one, write one sentence saying what it can do or return.

Example starting points: a tool that searches filings by company name, a tool that retrieves one filing's text, a resource that holds your saved notes. Be specific about inputs ("takes a company name and a year") rather than vague ("does research").

Finish line: a short list — three tools, two resources, one sentence each. In the next lesson you will learn why tools, resources, and prompts must not be treated as the same thing.