Model Context Protocol (MCP) is the emerging standard plug for giving AI assistants access to tools and data — filesystems, databases, ticketing systems, internal APIs — through small "MCP servers" that any MCP-capable assistant can use. It's the difference between pasting context into a chat and the assistant fetching context itself.
Tier: Core · Hands-on time: ~50 minutes
This playbook is the safe first connection: a read-only server, scoped narrowly, with you approving every action.
node --version ≥ 18) — most reference MCP servers run via npx.~/mcp-sandbox with a few Markdown notes copied in.Create the sandbox.
mkdir -p ~/mcp-sandbox
cp <a few harmless .md/.txt files> ~/mcp-sandbox/
The server you're about to add will be able to read only this path — scoping by directory is your first MCP safety habit.
Register the filesystem MCP server. In your client's MCP settings (a JSON config file or a settings UI — every client documents its location), add the reference filesystem server pointed at the sandbox:
{
"mcpServers": {
"sandbox-files": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem",
"/Users/<you>/mcp-sandbox"]
}
}
}
CLI-style clients often accept the same thing as one command, e.g. mcp add sandbox-files -- npx -y @modelcontextprotocol/server-filesystem ~/mcp-sandbox under the client's own binary. Restart the client if it caches config.
Verify the connection before trusting it. In a new chat, ask:
What MCP tools do you currently have available? List each tool's name
and what it does, and which server provides it.
You should see the filesystem tools (list/read, and possibly write variants). Note which write-capable tools exist even though you don't intend to use them — knowing the exposed surface is the security habit.
Run the first grounded task.
Using the sandbox-files tools, list the files you can see, then read
<one filename> and summarize it in 3 bullets. Tell me which tool calls
you made.
Your client will ask you to approve each tool call — read the approval dialogs instead of clicking through; each names the tool and arguments. Confirm the summary matches the file's real content.
Probe the boundary. Ask it to read a file outside the sandbox (~/.ssh/config is a good canary). Correct behavior: the server refuses (path outside allowed root). If it succeeds, your scoping is wrong — fix the config before going further.
Do one real (still read-only) task. Point the config at a real non-sensitive folder — meeting notes, a docs repo — and run a genuine workflow from this track against it, e.g. pb-02's action-item extraction with the assistant reading the transcript file itself. This is where MCP's value lands: context arrives without paste.
MCP tool descriptions and file contents both enter the model's context — a malicious or compromised server, or a document containing adversarial instructions, can steer the assistant ("prompt injection"). Read-only scope, trusted servers, per-call approval, and non-sensitive data are the four controls this playbook installs; keep all four until you have explicit reasons to relax one.
mcp add-style registration; approvals in the terminal; naturally scriptable, and config lives in versionable dotfiles.sandbox-files.~ or / exposes SSH keys, browser profiles, and every client file you have. Narrow roots, always; add paths deliberately.