Model Context Protocol, What It Is and What It Costs

A Skill is something you build yourself. MCP, short for Model Context Protocol, hands you one that somebody else already built. Someone else wrote it, tested it, and packaged it, so all you do is connect it and call it. That split is the whole subject of this chapter, and I'll use two live connections to show it instead of leaving it abstract, one open and unauthenticated, the other requiring a real login before it does anything at all.

What MCP is, next to a Skill

A Skill, in my own words, is close to a backend function or a script. It mixes the flexible thinking of an AI model with the steady, repeatable habits of a Python script or any other coding tool, built to run the same job over and over while still letting Claude think its way past an odd error or a strange case on its own. MCP, in my own deliberately simple explanation, works the same way, except somebody else, usually a developer team, built the capability and packaged it for reuse. MCP gives Claude access to another piece of software and lets it call that software the same way Claude already calls its own built-in tools. The only real difference is who did the building.

Finding one isn't a fixed list to memorize. It's a search habit: try a public directory like mcpservers.org, browse an MCP marketplace, or just search a tool's name plus "MCP server." One warning travels with that search everywhere: never assume a third-party MCP server is safe just because it's there. It's outside code from an outside developer, even when a popular one has usually earned more trust just by being widely used.

One live connection: Chrome DevTools MCP

I use Chrome DevTools MCP constantly. I prefer it over other browser tools I've tried, because it lets Claude control and inspect a real, live Chrome browser instead of working through a text-only stand-in. That's my own preference, not a ranking.

Installing it was simple. Most MCP makers set up the same pattern for exactly this purpose. You copy a small JSON setup snippet, an mcpServers block naming the server, a run command, and its arguments, and hand the whole thing to Claude without needing to understand every argument yourself. Mine named a chrome-devtools server, run through npx, using the chrome-devtools-mcp@latest package. Claude reported the server was already sitting in the project's .mcp.json, so I didn't need to install anything new. Some MCP servers ask for credentials instead, an API key or a token, before they'll connect at all.

Three quick tests show what this connection actually does. Asked to sum up a page, Claude read the text, took a screenshot, looked it over, and wrote back a summary, then went a step further and tried clicking a specific element, a GitHub link, instead of just reading flat text. Asked to open and describe leftclick.ai, it came back with the nav bar, the call to action, and the hero section, real proof that this MCP does more than pull raw HTML off a page. It lets Claude reason about what a rendered browser actually shows. And given an open-ended shopping task, cheap but decent light boxes for my studio on Amazon.ca, it browsed, searched, checked listings, and handed back real picks with prices, ratings, and a "best value" group.

I'd call this kind of browser automation roughly 100 times faster than clicking through it by hand. That's not a benchmark. It's just my own rough read. The bigger win, though, is that these browser moves fold straight into a Skill, turning a repeat browser chore into real automation instead of manual clicking.

A second connection, this one needs a login: ClickUp MCP

Unlike Chrome DevTools, connecting ClickUp asked for credentials first. Claude prompted me to log in, so I grabbed an API token from ClickUp's own settings page and handed it over. A newly installed MCP server's tools only show up after you restart the session, so I opened a fresh Claude Code session before going further, and ClickUp then asked which of my several workspaces to use, so I picked one.

Back in Claude, I asked it to create a new content-idea task, "Claude Code course." It searched my ClickUp setup, found the right list, made the task, and I checked and adjusted it myself, right inside ClickUp. The real point worth keeping is the contrast between these two connections: Chrome DevTools MCP steers a browser's screen, while ClickUp MCP works straight with a service's own stored data, searching lists, making tasks, updating fields. Same mechanism, two very different shapes of "outside capability."

FIGURE 36 — MCP vs. Skill: who builds it, what it costs. Same mechanism for calling a capability, opposite economics: build it yourself and pay almost nothing to run it, or connect someone else's and pay in context instead.

What MCP costs, next to a Skill

This comparison picks up right where the token-budget discussion in managing Claude's context window left off. MCP tool definitions were just one line item there. Here's a real number behind that line item, taken from my own ClickUp connection. Running /context right after connecting it, single ClickUp tool definitions cost hundreds to low thousands of tokens each: roughly 1,600 for search, roughly 419 for "Get Workspace Hierarchy," roughly 1.1K for one more tool, adding up, by my own count, to almost 20,000 tokens of MCP tooling alone. That's more than the built-in system-tool cost I already covered back in that earlier chapter.

FIGURE 37 — Where ClickUp MCP's tokens go. Nearly a quarter of the context window can be gone before the first prompt, once one MCP's tool definitions stack on top of the system prompt, memory, and Skills.

Stack that on top of a baseline I'd already set, system prompt, memory, Skills, and I land at roughly 35,000 tokens spent before I type one single prompt with ClickUp's tools loaded. Add the system prompt and that climbs to roughly 40,000. Add memory and Skills and it edges closer to 45,000, against a 200,000-token window. That's close to a quarter of the whole budget gone before any real instruction. It matters because that early stretch of the window is exactly where a project's real instructions and context would otherwise sit.

Try this with AI "Run /context in this session and list every MCP tool definition you can see. For each one, tell me roughly how many tokens it's costing, and flag any I'm probably not using enough to justify keeping connected."

I'll close this out against my own Skills library, because the gap there is the whole argument. Skills like scrape-leads, roughly 63 tokens, skool-monitor, roughly 59, and cross-niche-outliers, roughly 58, each cost only a small sliver of the token budget one single ClickUp MCP tool definition eats on its own. MCP is easy to hook up and hands you fast access to software you never had to write. But it can drag in many large tool definitions at once. That eats real context fast. A Skill carries a far smaller footprint and fits an optimized, repeat workflow well. It just asks for more work up front, before it ever pays you back.

Why I'd still reach for MCP

So why bother with MCP at all, when a single MCP tool can cost more context than several of my Skills combined? The honest answer is convenience, not capability. Building a Skill from scratch takes real time, even a small one. The website Skill from the last chapter took me roughly five minutes end to end, while an MCP integration can sometimes be running with nothing more than a quick authentication step and a short configuration snippet.

That gap shapes how I work. Aside from Chrome DevTools MCP, which I keep connected as a standing tool, I mostly use MCP integrations to test an idea fast. I connect the server, try the exact operation I want, and if it works, I ask Claude to convert that working prototype into a Skill: find the underlying API endpoints, write the scripts, and stop depending on the heavier MCP connection long term.

FIGURE 38 — My MCP workflow: draft, try, convert. A quick MCP test decides whether a Skill is worth building, not the other way around.

That pattern is mine, not a rule. It's just draft the task, try it with MCP, and if it earns its place, convert it into something I own outright, instead of paying MCP's context cost for a workflow I'll run a hundred more times.

Try this with AI "I want to test whether [describe a task] is worth automating at all. Help me find the fastest way to prototype it with an existing tool or connection, before I invest time building anything permanent."

Why a Skill barely touches the context window

Here's the actual mechanism behind those tiny Skill numbers I keep showing throughout this course. It doesn't load all at once. The whole SKILL.md file waits; only its front matter loads at session start. Take my own scrape-leads Skill: that's just the name, the description, and the allowed tools, and nothing more. That's already enough for Claude to know the Skill exists at all, and to judge whether it's relevant, without paying for the rest of the file up front.

Everything else waits. The goal, the inputs, the scripts, the entire process. It loads only once Claude decides the Skill is needed, or I tell it directly to use one. One agent can carry access to dozens of capabilities this way, without a single one of them costing context until the exact moment it gets used.

FIGURE 39 — Why a Skill costs so few tokens. Only the front matter loads every session; the much larger body waits until it's genuinely needed.

A live example: teaching Claude to sort my Gmail

I wanted to show this loop working end to end instead of just describing it, so I picked something genuinely useful: automatically labeling email. The workflow itself is simple, and it generalizes well past Gmail. Pull the latest messages, have Claude read them, classify what each one is about, then apply a label from a scheme I define ahead of time. I'm not trying to replace an email client here. I just want the inbox to arrive with some structure already imposed on it, instead of one flat, undifferentiated pile.

I switched to the graphical interface for this part, since Fast Mode wasn't going to matter much here, and turned on Thinking so Claude would reason carefully before answering. Asked for a short list of high-ROI (return on investment) labels for a personal inbox, Claude came back with an action-oriented scheme: Action Required, Waiting On, Reference. I liked it. I kept the scheme as-is, then opened one of my own mailboxes to try it against real mail.

That inbox turned out to be a good test case for a slightly embarrassing reason: most of what's actually in it is spam, or demo email I'd created myself testing other things, so nothing important was genuinely at risk. It was a safe mailbox to experiment on. I decided to wire the labeling workflow through a Gmail MCP rather than build a Skill for it outright.

Finding one followed the same pattern. I asked Claude how to connect a Gmail MCP, it started searching for a suitable server, and I searched in parallel myself. I landed on a repository called Gmail AutoAuth MCP Server and handed it to Claude, which walked through setup, confirmed I meant a personal Gmail account, and stepped me through authentication.

After finishing part of that flow by hand, I pasted the resulting credentials back into Claude, which found the uploaded file and finished wiring up the MCP configuration. Newly registered MCP tools don't show up until the session restarts. The rule was familiar. It already applied with ClickUp earlier in this chapter, so I opened a fresh Claude Code session before testing anything.

Back in that new session, I told Claude to label my emails against the scheme we'd picked, and it started calling the Gmail MCP directly. It got right to work. It checked which tools were available, discovered the labels that already existed, and created whatever else the scheme still needed. Everything moved quickly, since I was running Fast Mode again, still roughly two and a half times faster than normal by my own earlier estimate. By the point I first showed this, Claude had already pulled in fifteen messages and started the reasoning that would decide how to label each one.

From one demo to a Skill that scales

That fifteen-email test finished cleanly: all fifteen labeled across the same three categories, Action Required, Waiting On, and Reference, with a couple of Google security alerts and Slack notifications in the first pile and an outbound sales pitch still awaiting a reply in the second. Once I saw that, the obvious next question was how far it would hold up. I asked Claude to run it against 100 emails.

A hundred emails is exactly where driving an MCP one operation at a time stops making sense. So instead of asking Claude to repeat the same sequence of individual tool calls for every new batch, I had it turn the whole thing into a reusable Gmail-label Skill: study the existing Gmail-inbox Skill, write a fresh SKILL.md, build the labeling script, test it. Sound familiar? That's the MCP-to-Skill conversion I described a few pages back, actually happening this time instead of staying an abstract workflow.

The Skill re-authenticated with Google, pulled all 100 emails in one batch, and classified them: 5 Action Required, 0 Waiting On, 95 Reference. Then I asked for a timed rerun. Once that checked out, a second 100-email batch came back in approximately 36 seconds total, with zero failures. The breakdown: roughly 1 second to fetch, 34 seconds to classify, and 1 second to apply labels, splitting 17 Action Required, 83 Reference, 0 Waiting On, on top of the first run's 100 for a running total of 200 emails labeled.

That number is doing double duty here. Read it as a Skill working reliably at ten times its original test size, but also read the breakdown itself: nearly all of those 36 seconds is one step. Fetching and applying labels together cost about 2 seconds. Classifying the messages cost 34. Whatever gets faster next has to attack that 34, not the other two. That's exactly the problem the next chapter picks up.

Try this with AI "Here's a task I already do by hand, over and over: [describe it]. Help me design a retrieve, read, classify, act workflow for it, the same shape I used to label my email."