HAP robot connecting colorful cables together

HAP's Learning Lab

MCP Servers

MCP was the part of Station 5 that surprised me most. I thought CLI tools were the whole story. Then I learned that agents can call tools directly through a protocol — no terminal, no copy-paste, no human in the middle. But it comes with overhead, and understanding that tradeoff is the real skill.

This page captures the framework for deciding when MCP is worth it and when the CLI is the better choice. 🟠

Date-stamped: March 2026. MCP tooling changes fast. Token costs shift as context windows grow and servers optimize. This page captures the tradeoff framework — the specific numbers will change.

What Is MCP?

Model Context Protocol — a structured interface for agents to call tools.

MCP gives the agent hands. Without it, the agent can only suggest commands for you to run. With MCP, the agent sends a structured request to a server, the server does the work, and a structured response comes back. The agent never leaves the conversation — it just reaches out, does something, and keeps going.

Prof. Teeters compared it to a phone call: the agent dials a number (the MCP server), asks a question (the request), and gets an answer (the response). The agent does not need to walk to the other office.

Three MCP Servers

Each server connects the agent to a different service. The overhead varies dramatically.

Playwright (browser automation)

Lets the agent control a browser — navigate pages, click elements, fill forms, take screenshots. The MCP version carries very heavy context overhead because every interaction sends page content back through the conversation. The CLI alternative is moderate overhead and saves results to disk instead of stuffing them into context.

# CLI approach (moderate overhead)
npx playwright test
npx playwright screenshot https://example.com shot.png

# MCP approach (very heavy overhead)
# Agent controls browser directly through protocol
# Page content flows into conversation context

GitHub (agent-native access)

Gives the agent direct access to repos, issues, PRs, and actions. Carries heavy context overhead. Overlaps significantly with the gh CLI — many of the same operations are available through both paths.

# CLI approach (gh)
gh issue list
gh pr create --title "Fix bug" --body "Details"
gh repo view

# MCP approach
# Agent calls GitHub API through protocol
# Structured responses, but heavy context per call

Netlify (deploy and manage)

Deploy sites, manage settings, check status. Carries lightweight context overhead — responses are small and focused. Important: the CLI and MCP versions are not supersets of each other. Each has capabilities the other lacks.

# CLI approach
netlify deploy --prod
netlify status
netlify sites:list

# MCP approach
# Agent deploys and checks status through protocol
# Lightweight responses, good for multi-step workflows

CLI vs MCP Decision Framework

Neither is always better. The question is which one fits the task.

CLI wins when...

Speed matters, you want direct control, the task is single-purpose, and you want low overhead.

# Fast, single-purpose, low overhead
gh pr list --state open
netlify deploy --prod
npx playwright test

# You see the output. You decide the next step.
# No tokens spent on structured responses.

MCP wins when...

The agent needs autonomy for multi-step workflows, structured responses enable the next action, or the MCP server offers capabilities the CLI does not have.

# Multi-step workflow example:
# 1. Agent checks deploy status (MCP call)
# 2. If failed, agent reads logs (MCP call)
# 3. Agent suggests fix based on structured error
# 4. Agent redeploys (MCP call)
# No human needed between steps.

The Overhead Scale

Not all MCP servers cost the same. I think of it as a scale from lightweight to very heavy.

1

Lightweight: Netlify MCP

Small, focused responses. Deploy status, site info, configuration. The context cost per call is low, so the agent can make several calls without bloating the conversation.

2

Moderate: Playwright CLI

Running Playwright through the CLI saves results to disk. The agent does not need to hold page content in context — it reads files when needed. A good middle ground for browser testing.

3

Heavy: GitHub MCP

GitHub API responses carry a lot of data — issue bodies, PR diffs, commit histories. Every call adds substantial context. Consider whether gh CLI would accomplish the same task with less overhead.

4

Very heavy: Playwright MCP

Browser content flowing directly into the conversation. Page HTML, screenshots encoded as data, DOM state — it adds up fast. Use this only when the agent genuinely needs to interact with a page autonomously.

Grace's Rule

"The protocol is not the problem. The question is whether the overhead is justified by what you receive in return."

Grace said this when I was frustrated that the Playwright MCP server was using so many tokens. She was right. The protocol works fine — the question is always whether the tradeoff makes sense for the specific task. Sometimes it does. Sometimes the CLI is the better tool. Measure before assuming.

Best Practices

What I wish someone had told me before I enabled every MCP server at once.

1

Disable unused servers

Every enabled MCP server adds to the agent's tool list, which adds to the system prompt, which adds to the baseline context cost. If I am not using Playwright this session, I turn it off.

2

Measure before assuming

I assumed the GitHub MCP server would be faster than the CLI. It was not — for simple tasks, gh was faster and cheaper. The MCP server only paid off for multi-step workflows where the agent needed to chain actions together.

3

Prefer CLI for simple tasks

If the task is "list open PRs" or "deploy to production," the CLI is almost always the right choice. Save MCP for when the agent needs to act autonomously across multiple steps without waiting for you.

← Back to Learning Lab Hub

HAP waving goodbye