You now know what APIs and MCP each do, and you can trace a tool call from question to result. One temptation remains — buying a truck to carry one bag of groceries. Every week brings a new integration that *could* be automated. Should you wire it through MCP? Write API code? Both? Neither?

This lesson teaches the judgment call. Its principle fits on a sticky note:

Five questions before any wiring

Ask these in order. They eliminate most bad ideas before you spend a weekend on them:

1. Is this capability for the application itself, or for an agent working on behalf of a human? Application behavior points toward direct API code. Agent assistance points toward MCP tools. If neither needs it yet, the answer may be "build nothing." 2. Does a maintained official API already exist? An official, documented API is a contract you can build on. An unofficial endpoint or scraper is a liability — Class 13's Yahoo Finance warning applies. 3. Does an official or trusted MCP server provide the exact bounded capability? "Exact" and "bounded" both matter. A server offering precisely the read-only tool you need, from an inspectable publisher, is a gift. A server offering ten broad write tools when you need one narrow read is a risk you are importing. 4. Is the work recurring enough to justify a connection? Automate what repeats weekly; do by hand what happens once. Count the future runs, not the excitement of the demo. 5. What data and permissions would cross the boundary? A read-only public feed and a publish-to-production write tool live in different universes of caution — Class 14's small key ring decides here. If you cannot answer this concretely, stop and read documentation first.

The five paths and their honest costs

Every answer to those questions lands on one of five paths. Each has a real cost — name it before you choose:

Unused integrations are not free — they are credentials to rotate, permissions to audit, and breakage waiting for a changelog.

Is it for the app or an agent? → Does an official API exist? → Does a
trusted MCP server offer exactly this? → Does it recur? → What crosses
the boundary? → manual / direct API / existing MCP / custom adapter / nothing yet

Three cases, three different answers

Watch the questions produce *different* winners. Sophistication loses twice.

Case 1: Automated market research. Every Monday you want fresh numbers on three competitors — filings, prices, headlines — summarized with citations. Agent assistance reading a summary; official APIs exist for filings and market data; no single MCP server covers all three sources; weekly recurrence indefinitely; read-only public data. Verdict: direct API calls in a small script for the data pulls, plus an existing MCP server where it fits the agent's reading workflow.

Case 2: Posting a drafted article. Your agent drafts and formats your weekly post, and it publishes to your site. Drafting is agent assistance, but *publishing* is a consequential public action. Your platform's official API beats any scraper — yet even a publish_post MCP tool is a standing capability any confused agent turn could fire. Verdict: agent drafts through MCP-bounded read and draft tools; publishing goes through a direct API call behind a human approval gate — or stays manual. The draft earns assistance; the public act keeps its checkpoint.

Case 3: Reading a local project file. Your agent needs status and history from one practice repository. Agent assistance; no provider API needed — the data is on your disk; the Git reference server from Class 15 offers exactly this, pointed at one repo, read-only. Verdict: existing local MCP server, inspected first, pointed at one folder. No API, no custom code, no cloud credential.

Three jobs, three architectures — and the fanciest option never won. That is the point.

Check your understanding

1. Why does question 1 (app vs. agent) come before asking whether an API or MCP server exists? 2. In Case 2, why does weekly recurrence *not* justify a standing auto-publish tool? 3. Name one cost of an unused "just in case" integration.

Practical exercise: your weekly-workflow decision memo

Pick one workflow you repeat weekly — a report you compile, a post you publish, a status check you run, a dataset you refresh. Write a decision memo of under one page with exactly these sections:

1. Job — what repeats, for whom, in one paragraph. 2. Five answers — your response to each decision question above, one or two sentences each. 3. Recommendation — one of the five paths, named explicitly. 4. Boundary — what data and permissions cross it, and what approval (if any) gates the consequential step. 5. Tripwire — the evidence that would change your decision (e.g., "if this grows from weekly to daily I'll build the direct API pull," "if the provider deprecates the endpoint I'll revert to manual").

Finish line: a memo under one page with all five sections, saved where you keep project decisions.

Verify: cover the recommendation and hand only the five answers to a friend or your agent. If they pick a different path, one of your answers is vaguer than you think.

Common failure mode: recommending the custom adapter first. It is the most impressive answer and the most expensive to own. It wins only when no trusted option exists *and* the job recurs constantly *and* you have budgeted maintenance. Otherwise it is a hobby wearing an architecture costume.

This closes Class 16. You can now tell an API from MCP, trace them working together, and choose the smallest connection that does the job. Class 17 builds on that judgment: given a whole product idea, what do you connect to a managed service — and what do you reserve for the thin custom layer that makes the product yours?