# EP10 Website Draft

## Goal

Make MCP feel like a capability decision, not a plugin dump.

## Hero

**Claude Code Deep Dive**

One sentence:
MCP belongs in the capability plane, where external tools are added deliberately and with a clear trust boundary.

## Page Structure

1. hero summary
2. capability-plane map
3. MCP vs local tools comparison
4. tool-boundary experiment
5. minimum viable integration pattern
6. official-doc links

## Interactive Blocks

### 1. Capability Map

Show where MCP sits in the five-layer model and what it should not absorb.

### 2. Tool Boundary Switcher

Let the reader switch between:

- local tool
- MCP tool
- manual workflow

The page should show how the trust boundary and ownership change.

### 3. Integration Risk Demo

Show what happens when the tool surface is too broad:

- noisy outputs
- unclear ownership
- hidden failure modes

### 4. Comparison Table

Compare these pairs:

- MCP vs local tools
- MCP vs hooks
- MCP vs skills
- capability plane vs control plane

Each row should answer:

- what it is
- when it loads
- what it can control
- what it cannot guarantee

## Minimum Viable UX

- clear visual hierarchy
- one strong capability motif, not a generic admin shell
- mobile-safe comparison blocks
- concise labels and strong callouts

## Teaching Rules

- Every block must map back to the five-layer model.
- Every block must show one concrete failure mode.
- Every block must include a decision point: connect, keep local, or reject.

## Official Links

- memory
- settings
- hooks
- sub-agents
- MCP

## Exit Outcome

The reader should leave knowing when MCP is the right fit, when it is overkill, and how to keep the integration boundary narrow.