Foundations · Lesson 15 — Your first MCP server

F15Foundations

Foundations · Lesson 15● live

Your first MCP server

The 20-minute setup, the gotchas, when MCP beats writing a tool.

15 min read · 20 min applyno prereq

What MCP is

MCP — Model Context Protocol — is the standard Anthropic shipped for connecting external services to Claude as first-class tools. An MCP server exposes a typed set of tools (functions Claude can call) plus optional resources (data Claude can read). The agent loads the tool definitions on session start and can invoke them like any other tool.

The practical effect: services with an MCP server become available inside Claude Code without leaving the chat. Supabase MCP lets you run SQL. Gmail MCP lets you draft and label emails. Notion MCP lets you query and update pages. Hugging Face MCP lets you search papers and models. Each one collapses a Cmd-Tab workflow into in-conversation tool calls.

MCP is leverage when used carefully and noise when used reflexively. Every connected MCP loads its tool definitions into every session’s context. 30 MCPs × 5 tools each = 150 tool definitions Claude evaluates on every turn. Latency goes up, costs go up, the model can get distracted picking the wrong tool from a crowded list.

The skill is twofold: install MCP when it pays back, and audit your install regularly to keep it clean. This lesson walks both.

When MCP beats writing a tool

The decision rule is three questions:

Frequency. Will this integration fire at least weekly? If no, write a one-off script and forget MCP.
Existing MCP. Does an official or reputable open-source MCP already exist? If yes, install it (with toolFilter to narrow scope). If no, ask if it’s worth writing one — usually only if multiple operators on the team will use it.
Stakes. Does this MCP touch credentials, money, secrets, or data outside your control? If yes, the install needs a permission review (see Foundations 17). Don’t reflex-accept.

Examples from the portfolio:

MCP wins: Supabase MCP for trupath_tasks queries — fires daily, official package, scope narrowed via toolFilter.
MCP wins: Hugging Face MCP for Parley research — paper search and model lookup fire weekly during research phases.
Don’t MCP: A one-off SBA loan packet PDF fill — a Bash + Python script is cheaper to write and dies cleanly when done.
Don’t MCP: Reading the QC repo — Claude Code already has Read/Edit/Bash. Adding an MCP for repo access is duplicative.

Three MCP traps

№ 01

Installing every MCP available

claim looks like“"There's an MCP for that — let me add it."”

what’s missingEach connected MCP server adds tool definitions to every session's context. 30 MCPs × 5 tools = 150 tool definitions Claude has to consider on each turn. The model gets distracted; latency goes up; bills go up.

the moveInstall only MCPs you actually use weekly. Audit quarterly. Delete the ones whose tools haven't fired in 30 days.

№ 02

Vendor MCP without permission review

claim looks like“Operator installs a third-party MCP, accepts the default permissions in 3 seconds.”

what’s missingA connected MCP can read files, make network calls, run shell commands depending on its scope. Default permissions vary. Some MCPs request more than they need.

the moveOn every MCP install, read the tool list. For each tool, ask: 'does this need that permission?' Deny anything beyond what the documented use case requires.

№ 03

Building MCP for a one-off

claim looks like“"I'll write a custom MCP server for this CSV import."”

what’s missingMCP earns its setup cost when the integration fires repeatedly. For one-off work, a script + Bash tool is cheaper to write, easier to read, and dies cleanly when done.

the moveWrite MCP for: third-party services you'll hit weekly, internal data sources you query repeatedly, capabilities other operators on the team will use. Skip MCP for: one-off scripts, throwaway data ops.

The pattern across all three: MCP install is configuration, not free leverage. Treat it like any other dependency — review on install, audit quarterly, narrow scope.

The vendor-MCP audit

The quarterly audit that keeps your MCP install honest.

Vendor-MCP audit — run quarterly

Audit my installed MCP servers.

For each MCP in claude_desktop_config.json or settings.json:

1. **Last fire** — when did any of its tools last get invoked?
   (best estimate from session history)
2. **Tool surface** — how many tools does it expose vs how many
   I actually use?
3. **Permissions** — does it have credentials or scopes broader
   than the documented use case requires?
4. **Vendor trust** — official Anthropic-recommended? Reputable
   open source? Sketchy GitHub fork?

Output a table:
mcp | last-fire | tools-exposed | tools-used | permission-fit | trust-level | recommendation

Recommendations: KEEP, NARROW (toolFilter), UPDATE, DELETE.

Combines fire-frequency, scope-fit, and permission-fit into a single deletion-or-narrow recommendation.

Most operators’ first audit reveals 30-50% of their MCPs haven’t fired in 30 days. Delete those. The remaining ones often expose 10-30 tools but you only use 3-5 — narrow with toolFilter.

Annotated transcript — Supabase MCP setup

A real install: scope-decide, config-draft, restart, verify, audit-cadence. ~15 minutes end-to-end.

Installing Supabase MCP for trupath_tasks queries

Full lifecycle: pick scope, draft config with toolFilter and publishable-key, verify, plan the audit cadence.

operator
Want to add Supabase MCP so I can query trupath_tasks directly without copy-pasting SQL into PSQL. Walk me through it.
agent
20-minute setup. Three steps:
Step 1 — Decide on scope. Supabase MCP exposes ~30 tools (list_tables, execute_sql, get_logs, list_projects, etc.). Default install gives you all of them. For your use case (querying trupath_tasks), you probably want: list_tables, execute_sql, get_advisors. Maybe get_logs for debugging.
Step 2 — Add to claude_desktop_config.json or settings.json. I'll show the structure.
Step 3 — Restart Claude Code session. Verify with /help — the new tools should appear under MCP servers.
Want me to draft the config?
operator
Yes. Just the four tools I'll use. Draft the config.

agent

Adding to ~/.claude/settings.json under mcpServers:

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-supabase"],
      "env": {
        "SUPABASE_URL": "https://szafqxabhkkhzuvebkaj.supabase.co",
        "SUPABASE_PUBLISHABLE_KEY": "sb_publishable_5m6kA9SU13AXEoSpO1BT_Q_482XQiNE"
      },
      "toolFilter": ["list_tables", "execute_sql", "get_advisors", "get_logs"]
    }
  }
}

⚠️ Note: I'm using the publishable key (RLS-bound), not the service-role key. Service-role bypasses RLS and is a credential leak waiting to happen — never put it in an MCP config you'll check into git or share.

Restart your session after saving. Verify with /help.

operator
Restarted. /help shows 4 supabase tools. Test query: count rows in trupath_tasks.
agent
Calling supabase__execute_sql with: SELECT COUNT(*) FROM trupath_tasks;
Result: 47 rows. Breakdown by venture (running another query):
- QC: 22 rows
- MHG: 8 rows
- TruPath: 11 rows
- Parley: 6 rows
The MCP is wired correctly. From here you can run any RLS-allowed query without leaving Claude Code.
operator
Audit move: when should I revisit this MCP install?
agent
Three triggers:
1. Quarterly — list every MCP you have installed. For each, count tool fires in the last 30 days. Delete anything that fired <3 times.
2. On Supabase schema change — if you migrate trupath_tasks (add a column, change types), the MCP's tool descriptions are stale. Re-pull or update.
3. On suspected misuse — if the MCP starts firing on requests you didn't expect, audit. Sometimes a vendor update broadens tool surface in ways you didn't ask for.
Most operators install MCPs and never revisit. The audit catches drift, stale schema, and bloat.

Prompt kit

Three prompts: vendor audit, MCP-vs-script decision, narrow-existing-MCP.

The vendor-MCP audit

Audit my installed MCP servers.

For each MCP in claude_desktop_config.json or settings.json:

1. **Last fire** — when did any of its tools last get invoked?
   (best estimate from session history)
2. **Tool surface** — how many tools does it expose vs how many
   I actually use?
3. **Permissions** — does it have credentials or scopes broader
   than the documented use case requires?
4. **Vendor trust** — official Anthropic-recommended? Reputable
   open source? Sketchy GitHub fork?

Output a table:
mcp | last-fire | tools-exposed | tools-used | permission-fit | trust-level | recommendation

Recommendations: KEEP, NARROW (toolFilter), UPDATE, DELETE.

Decide: MCP vs custom tool vs script

I want to integrate <service / data source> with Claude.
Help me decide: MCP server, custom tool, or shell script.

Score each on:
- How often will I use this? (one-off / weekly / daily)
- How many tools does the integration need? (1 / 2-5 / 6+)
- Will other operators on the team use this?
- Is there an existing MCP I can reuse?

Output a recommendation with reasoning. If MCP is right, link
to the existing MCP package. If custom tool, sketch the shape.
If script, write the script.

Narrow an existing MCP install

My <name> MCP exposes <N> tools. I only use <M> of them
regularly. Walk through:

1. List all <N> tools with one-line descriptions
2. Mark which I actually use (best estimate)
3. Output a toolFilter array I should add to my MCP config to
   narrow to just the tools I use.

Don't apply the change — show me the diff to my settings.json
and I'll apply it.

Apply this — install one, audit the rest

20-minute exercise. Pick one MCP that pays back. Audit anything you have installed. Narrow with toolFilter where appropriate.

Set up your first MCP — and audit the rest

Each step takes 5 minutes. Progress saves automatically.

0/4

01List your currently installed MCP servers (~/.claude/settings.json or claude_desktop_config.json).Most operators have 3-8. Some have 30. Both extremes are usually wrong.
02Run the vendor-MCP audit. Identify any that fired <3 times in 30 days.Strong candidates for deletion. The audit pays for itself in latency.
03Pick one MCP to install or narrow. The Supabase example above is a good starter if you don't already have one.20-minute exercise. Setup + first useful query.
04Add toolFilter to any MCP that exposes more tools than you use.Cuts context bloat. Lower latency, lower cost, fewer wrong-tool fires.

Foundations tier · what's next

After this lesson

Foundations · № 16● live

Your first custom agent file

Build CIPHER (legal/IP) from scratch in one sitting.

15 min read · 45 min apply

Foundations · № 17● live

Tool permissions and you

Allow vs ask vs deny — the model that prevents 90% of "wait I didn't mean that" moments.

12 min read · 20 min apply