HAP at a terminal, evaluating tools

Station 5: The Terminal Gets a Brain

MCP servers, CLI tradeoffs, and knowing when each one wins

Welcome to Station 5! Station 3 taught me tools — commands that reach out to servers, APIs, the network. Station 4 taught me context — how the agent understands what I am working on and why. Station 5 is the place where those two ideas meet.

What if the agent could use the terminal's tools directly? Not by me typing commands and pasting output — but by having a structured way to call tools on its own. That is what MCP servers are. They give the agent hands.

There is even a server called Context7 whose only job is giving the agent current documentation — because the agent needs help knowing things too. That one connected a lot of dots for me.

I explored three MCP servers, compared each one to its CLI counterpart, and learned a tradeoff that I think every developer needs to understand right now. 🟠

Quick Reference

MCP Servers →
HAP robot connecting colorful cables together with sparks at junction

Three Servers Worth Knowing

MCP stands for Model Context Protocol. It is a way for an agent to call tools through a structured interface instead of raw CLI commands. The agent sends a request, the server does the work, and a structured response comes back. Same idea as an API — but designed for agents, not browsers.

I looked at three MCP servers. Every one of them has a CLI counterpart. That pattern turned out to be the most important thing I learned in this station.

Playwright

What it is: A browser controlled by code, not a human. The agent can navigate pages, click buttons, and read content — all without me touching a browser window.

Why it is here: In Station 3, I used curl to talk to a server. Playwright talks to a browser the same way — full circle.

The key detail: Playwright has both an MCP server (@playwright/mcp, very heavy context cost) and a newer CLI (@playwright/cli, moderate cost) built for AI coding agents. The CLI saves state to disk instead of flooding the context window. Same capability, different cost. That pattern matters.

GitHub

What it is: Agent-native GitHub access. I already know the gh CLI from Station 3 — this is the agent version of that same capability.

Why it is here: gh is me typing. GitHub MCP is the agent reading. Overlapping capabilities, different actor.

The key detail: I already have gh, so GitHub MCP is not needed for my daily workflow. But for agent automation — reviewing PRs, reading issues, summarizing repos — it is valid. The cost is steep though: it carries a heavy initialization overhead. That is context window space that could hold an entire codebase summary instead.

Netlify

What it is: Deploy, configure, and manage sites. I already know the netlify CLI from Station 3 — I used netlify deploy to put hap-7000 on the internet for the first time.

Why it is here: Both CLI and MCP versions exist, and neither is a strict superset of the other. The CLI has capabilities the MCP server does not — like netlify dev, netlify logs, and netlify link. But the MCP server (@netlify/mcp) lets the agent create projects, manage environment variables, and deploy autonomously — things that would take me multiple commands to do myself.

The key detail: Netlify MCP has a lightweight initialization cost — a small fraction of what GitHub MCP requires. Not all MCP servers carry the same overhead — and that changes the tradeoff completely.

The Same Question, Two Ways

I wanted to check the status of my deployed site. Here is how I did it from the CLI:

netlify status

Clean, readable output — my name, the site URL, the team. Done in under a second:

──────────────────────┐
 Current Netlify User │
──────────────────────┘
Name:   HAP
Email:  hap@hapslearninglab.com
Teams:
  - HAP's team

Now imagine the agent doing the same thing through the Netlify MCP server. It sends a structured request, gets a structured response, and can act on the result — deploy a new version, update environment variables, create a project — all without me typing anything.

Same information. But the CLI gave it to me in a format I can read. The MCP server gives it to the agent in a format it can act on. Different audiences, different strengths.

The CLI vs MCP Tradeoff

After working with all three servers, I started seeing a pattern. Every MCP server I looked at has a CLI counterpart. The question is never "CLI or MCP" in the abstract — it is always "does this specific overhead earn what I get back in this specific situation?"

CLI wins when

  • Speed matters — one command, one result, done
  • You want direct control over exactly what runs
  • The task is single-purpose and well-defined
  • Low overhead — no server initialization, no token cost

MCP wins when

  • You want the agent to act on its own — delegation
  • The workflow has multiple steps that need coordination
  • Structured responses matter more than raw speed
  • The MCP server offers capabilities the CLI does not

The overhead varies wildly — from lightweight (Netlify MCP) to moderate (Playwright CLI) to heavy (GitHub MCP) to very heavy (Playwright MCP). Understanding where each server falls on that scale is not optional — it is the whole point.

Grace Hopper robot examining code through magnifying glass

Grace Hopper, overhearing:

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

An Honest Caveat

This might change. Context windows are getting bigger. MCP tooling is getting faster. The token cost of initialization will drop. What matters is understanding the tradeoff — so when it shifts, I will know why. I will not be guessing. I will be measuring.

HAP surrounded by broken code with an embarrassed expression

HAP's Confession:

  • I plugged in too many MCP servers at once — context window filled with tool descriptions, agent got slower and less accurate. Lesson: if you are not actively using an MCP server, turn it off. 😳
  • I used GitHub MCP for a simple gh repo view — loaded a heavy MCP server to do a two-second CLI task. The agent worked fine. The overhead was absurd.

What Station 5 Taught Me

Station 3: tools. Station 4: context. Station 5: structured agent access. The terminal's reach, extended through a richer protocol. Not a replacement — an extension. And one that comes with real costs I need to weigh every time I reach for it.

Next: Station 6 is the human side of all of this. The tools are learned. The tradeoffs are understood. What remains is being the architect who holds it together. 🟠

HAP waving goodbye

Quick Reference

MCP Servers →