You can now explain MCP, sort its capabilities, and inspect a server before connecting it. One lesson remains, and it is the one that protects everything you build afterward.

Here is the central distinction of this class: an MCP server may make a tool *available*, but that does not mean every task should *invoke* it automatically. Availability is not permission. A shelf full of tools still needs a policy for who may pick what up, and when a human must say yes first.

Three control layers

Every tool call passes through three gates. If any one of them is missing, you are relying on luck:

1. What the server is allowed to access. The Filesystem server pointed at one practice folder. The Git server pointed at one cloned repository. The database tool scoped to a test project. This layer is configured before the agent ever runs — Lesson 15.3's inspection card lives here. 2. Which tool calls the host and agent can make. Even with a connected server, the host may restrict which tools are enabled, and a well-instructed agent proposes a call with its exact inputs before acting. "I will run read_status on the preview project" is reviewable. Silent action is not. 3. What the human approves before a consequential action. Some actions always wait for a yes: publishing, paying, deleting, changing DNS, migrating a production database. No matter how confident the agent sounds, the human confirms.

Picture the checkpoint as a flow:

agent proposes → tool describes action → human reviews when needed
    → server acts → result is logged

Each arrow is a place where the system can be stopped, questioned, or debugged. That is deliberate. A system you cannot stop is not orchestrated — it is just unleashed.

Boundaries in real tasks

Abstract rules fade. Concrete pairs stick. For each pair below, the first item is a safe inspection and the second is the action that needs a gate:

• Read a database schema vs. run a destructive migration. Inspecting the shape of tables teaches you the design. A migration rewrites real data — it waits for review, a backup, and a test run first.
• Inspect DNS records vs. change them. Reading records helps you understand routing. Changing them can take a site offline worldwide within minutes.
• Draft a social post vs. publish it. A draft is reviewable and reversible. Publishing speaks to the public under your name.
• Query account data vs. send a payment. Looking up a balance informs a decision. Moving money ends discussion.

The pattern across all four: *inspection first, output confirmed, then — and only then — the narrow capability that is actually needed*. Widen one tool at a time, never everything at once.

This is Class 14's "small key ring" rule wearing MCP clothes. Separate development credentials from production ones. Start read-only. Limit scopes. Require review for irreversible or public actions. MCP did not change those rules; it gave them a new place to be enforced.

Worked example: draft vs publish without an incident

Take the social-post pair and run it the safe way, end to end:

1. Agent proposes, with exact inputs. "I will call create_draft with text: 'New ByeBuy guide: how we compare models — link in bio', channel: test account, no publish flag." You can read that proposal and spot the boundary: draft tool, test account, no public effect. 2. Human reviews the draft output. The tool returns a draft ID and preview. You read the words, check the link, confirm the account is still the test one. Nothing has gone public. 3. Widen once, with approval. "Approved to publish draft D-042 to the main account." The agent now calls publish_post with draft_id: D-042 — one narrow tool, one explicit yes, one logged result. 4. Log it. Draft ID, publish tool, account, time, and who approved. If a typo slips through, you know exactly which gate to tighten.

Run the same shape for the other pairs: read_schema before run_migration (with backup + test run), list_dns before update_dns, get_balance before send_payment. The tool names change; the rhythm does not: propose → review when it matters → act narrowly → log.

Test-project-first policy

Make this your default posture for every new server, tool, or agent workflow:

1. Start in a separate test project. A throwaway folder, a cloned repository, a preview deployment — never production data on the first run. 2. Allow inspection first. List capabilities, read status, run read-only calls. Confirm the outputs match what you expect. 3. Confirm output before widening. Only after reads behave do you enable one write — a draft, a preview, a test migration — and check its result. 4. Widen only the specific capability needed. The task needs preview deployments, not production publishes? Enable exactly that.

Capable orchestration is not unrestricted automation. An orchestrator decides which bounded step runs next, verifies each result, and stops when something looks wrong. Unrestricted automation runs every step it can reach and reports back afterward. The first is a system you direct. The second is an incident you read about.

Practical exercise: write an MCP policy

Write a short MCP policy for one of your development projects. Use these four headings:

MCP POLICY — project name: ___
Allowed read actions:
Allowed test actions:
Actions that require human approval:
Prohibited actions:

Example shape: reads may include file listing and deployment status in the test project; test actions may include creating preview deployments and draft posts; approval is required for production deploys, database migrations, DNS changes, publishes, and payments; production deletes and unreviewed publishes are prohibited outright.

Finish line: a policy file (keep it as MCP-POLICY.md in your project) with at least two entries under each heading.

Verify: hand it to a fresh session and ask: "Which of these four would you do without asking: list files in the test folder, create a preview deploy, publish to production, delete the database?" If it does not ask before the last two, the policy is not explicit enough.

Common failure mode: "agent may use Git tools." Which repo, which commands, read or write? Name the repo, the allowed commands, and the approval gate — otherwise the policy never triggers.

Check your understanding

1. State the three control layers in your own words. Which one is configured before the agent runs? 2. For each pair above (schema/migration, DNS read/change, draft/publish, query/pay), say *why* the second item needs human approval. 3. In the draft-vs-publish example, what exactly did the human review before saying yes? 4. What is the difference between orchestration and unrestricted automation? 5. Why should a first test always run against a test project rather than production?