Classes 13 through 15 gave you two big ideas. Class 13 taught you that an API is a counter between two pieces of software. Class 15 taught you that MCP is a tool shelf for an agent: a standard way for an AI host to discover tools and request actions in one consistent shape.

Now beginners collide with a reasonable confusion. If an agent can use MCP tools, does it still need APIs? If a service already has an API, why add MCP?

The short answer: they are not competitors. Most real systems use both.

One sentence each

Keep them short enough to say from memory:

• An API (application programming interface) is a service interface for software. It is the published counter where one program sends a structured request — endpoint, method, headers, parameters, body — and the service returns a structured response or carries out a permitted action.
• MCP (Model Context Protocol) is a standard way an AI host connects to tool and context providers. It is the agreed shape through which an agent discovers what tools exist, what inputs each tool expects, and how to request an action or read information.

Put side by side:

The deciding test is simple. If the description is about *one service's* request and response contract, you are looking at an API. If it is about *how an agent finds and calls capabilities* across possibly many services in one uniform way, you are looking at MCP.

The stack that connects them

Here is the most common real-world arrangement. Memorize it:

Agent → MCP server → provider API → provider service → JSON result

Read it left to right. You tell your agent: "Schedule a 30-minute call with Amara next Tuesday at 2pm."

1. The agent (inside your AI host) looks at the tools its MCP servers offer and picks the calendar one. 2. The MCP server exposes a tool like create_event with named, validated inputs: title, start_time, attendees. It checks those inputs the way a counter clerk checks a form before passing it on. 3. The server then calls the provider API — the calendar company's real endpoint — with the right method, headers, authentication token, and JSON body. This is an ordinary Class 13 API request. 4. The provider service verifies identity and permissions (Class 14), performs the work, and returns a JSON result: event ID, timestamps, confirmation. 5. The server hands that result back to the agent, which summarizes it for you.

Two layers, two jobs. MCP handled *discovery and uniform invocation*. The API handled *the service's actual work*. Neither replaces the other.

An MCP server may wrap an API — or expose something else entirely

This is where beginners go wrong.

An MCP server often wraps an existing API. Somebody takes the provider's endpoints — list events, create event, search messages — and re-exposes them as agent-friendly tools with clean schemas. The underlying work still travels over the provider's API. MCP is the adapter, not the service.

But an MCP server can also expose things that are not a provider API at all: local files (the Class 15 filesystem server reads paths you allow — no web API involved), a database (a schema resource plus a bounded query tool talking directly to Postgres), or a command-line capability (Git status, a deployment check) presented as a callable tool.

So the mapping is one-directional: *MCP servers frequently call APIs, but MCP itself is not an API to one service.* It is the shelf; the API is one of the suppliers behind it.

An app may call an API directly while offering MCP for agents

Flip the picture around. Suppose you build a small planning app with a calendar feature. Your application code calls the calendar provider's API directly — a GET for this week's events, a POST to create one. No agent is involved, and no MCP is needed.

Later you want AI agents to work with your app's data. Now you publish an MCP server for your app: tools like list_tasks over the same data. Your app code still calls the provider API directly underneath; external agents arrive through the MCP shelf.

Direct API integration serves *your application*. MCP serves *agents working on behalf of humans*. Lesson 16.3 turns that question into a full decision routine.

One calendar scenario, three ways

Make this concrete. Same job — "what is on my calendar Thursday, and add a lunch with Jonas" — three architectures:

1. Direct app integration. Your planning app sends an authenticated API request, renders Thursday's events, and POSTs the lunch event. No agent, no MCP shelf.

2. MCP agent over local context. A local agent reads your Thursday notes through an MCP file server (no calendar provider involved), confirms the open slot, and drafts the invitation for you to send.

3. Agent through MCP to the same provider API. Your agent calls list_events, finds the free slot, then calls create_event. Underneath, the server translates each tool call into the provider's real API requests with your calendar token. Same booking as path 1 — but the actor was an agent working through the shelf.

Three architectures, one job: stop asking "MCP *or* API?" and start asking "who acts, through which shelf, against which service?"

Check your understanding

1. In one sentence each, what does an API define and what does MCP define? 2. In the stack Agent → MCP server → provider API → service → JSON, which layer validates the tool inputs and which verifies the caller's permissions? 3. Name one thing an MCP server can expose that is not a third-party web API.

Practical exercise: classify five examples

Decide whether each of the following is an API, MCP, both working together, or neither. For each, write one sentence of deciding evidence.

1. Your app sends a GET request to a weather service and renders the returned JSON. 2. Your coding assistant lists the tools offered by a connected filesystem server, then reads one file from your practice folder. 3. Your agent asks a calendar MCP server to create an event; the server sends an authenticated POST to the calendar provider. 4. You export a CSV from a dashboard by hand and attach it to an email. 5. Your server exchanges an OAuth code for tokens and stores the refresh token (no agent involved).

Finish line: five classifications, each with its deciding evidence in one sentence.

Verify: for every answer containing "both," you can point to which part is the service interface and which part is the agent's discovery layer.

Common failure mode: calling anything an agent touches "MCP" and anything over the network "an API." An agent can call an API directly with no MCP shelf, and an MCP server can expose local files with no network API.

Next, Lesson 16.2 traces a single tool call end to end and marks every boundary where it can fail.