Claude Code MCP: when you need a server — and when a CLI beats it

MCP — the Model Context Protocol — is Anthropic's open standard for connecting agents to external tools, and Claude Code supports it natively: one claude mcp add command registers a server, and its tools show up in your next session. That's the short answer to what Claude Code MCP is. The longer answer, which the tutorials mostly skip, is that for a CLI-native agent an MCP server is often the second-best integration — because Claude Code already speaks a universal tool protocol: the shell. This post covers what MCP actually solves, runs one real data workflow through both shapes, and ends with the cases where a server genuinely earns its place.

What Claude Code MCP actually is

MCP standardizes the conversation between an agent host and a tool. A server exposes tools (typed functions described by JSON schemas), resources (data the host can read in), and prompts, over stdio or HTTP. The host connects, lists what's available, and the model invokes tools with structured arguments. The point of the protocol is fan-out: before MCP, every host-and-tool pair was a bespoke integration; with it, a tool author writes one server and any MCP host — Claude Desktop, Claude Code, IDE plugins, other vendors' agents — can drive it.

Wiring a server into Claude Code really is a one-liner — claude mcp add, pointed at a command to spawn or a URL to reach — and the official docs cover transports, scopes and auth, so no tutorial rehash here. The more useful question is what the protocol is for. MCP earns its complexity in three situations:

• The host has no shell. Claude Desktop, Cowork, browser and mobile agents can't execute a process. A protocol connection is the only way to hand them a tool.
• You want typed, inspectable calls. Schemas let a host validate arguments, render approval UI, and audit exactly which tool ran with which parameters.
• You need a live channel. Resources and subscriptions let a server push updates to the host; a one-shot command can only be pulled.

Notice what's missing from that list: "the agent runs on a machine with a shell, and the tool ships a CLI." That case is Claude Code's home turf — and it's where the calculus flips.

A CLI-native agent already ships a tool protocol

Claude Code's core loop is: run a command, read what came back, decide what to run next. That loop is tool use. Which means every well-behaved CLI on your PATH is already integrated, with properties an MCP server has to spend machinery to reproduce:

• Zero configuration. Install the binary; done. No registration step, no transport choice, no wondering whether the server started this session.
• Output is already context. stdout is text, and text is what a transcript is made of. Nothing sits between the tool's answer and the model's eyes.
• Composition comes free. Flags, pipes, exit codes, files. The agent chains your tool with grep and jq exactly the way you would.
• Skills carry the judgment. A skill in ~/.claude/skills teaches the agent which command fits which intent — not just the signature, but when to reach for it and how to read what comes back. A JSON schema can't say "cross-channel questions go to the unified table"; a skill can. (We unpack this pattern in Claude Code marketing skills.)
• The cost scales with use. Every registered server adds standing surface to a session — definitions to load, a process to keep alive — while a CLI costs nothing until the moment the agent actually runs it.
• Debugging is symmetric. When the agent hits something weird, you paste the same command into your own terminal and see exactly what it saw.

MCP's machinery — schema negotiation, a server lifecycle, a transport — exists to deliver a subset of these properties to hosts that can't exec. Putting a server between Claude Code and a tool it could already run doesn't add capability. It adds a layer.

One job, both shapes: cross-channel ROAS into a live dashboard

Protocol arguments are cheap in the abstract, so here's a concrete job: "ROAS by platform for the last 28 days, and a dashboard I can share." This is what TableBI exists for — a data backend for your Claude Code, built around three moves: Pipe sources in, Ask in read-only SQL, Pin the result. (The full marketing workflow lives in Claude Code for marketing; the broader measurement angle in Claude Code analytics.)

Setup, in its entirety — note that nothing MCP-shaped happens:

# default install: CLI + skill, no MCP server registered
npm i -g @tablebi/cli && tablebi install

tablebi install plants a skill into ~/.claude/skills and deliberately does not register an MCP server. Piping sources in is one OAuth round-trip each; flat files come in as CSV:

# live sources: browser opens for OAuth, then data syncs in
tablebi connect gsc --site sc-domain:example.com
tablebi connect ga4
tablebi connect meta_ads
tablebi connect google_ads

# flat files normalize into the same definitions
tablebi connect csv --file f.csv --platform tiktok_ads

From here you stop typing SQL yourself. You ask Claude Code the question in plain language; the skill tells it which command to run and which altitude to aim at. Cross-channel questions go to facts, the unified table where spend means the same thing on every platform and the shared dimensions — date, platform, account, campaign, ad_group, ad, channel, country — make one GROUP BY work across every source. Per-platform forensics drop to the <platform>_raw tables underneath. For our job, the agent runs:

# ROAS by platform, last 28 days — one query across Meta + Google Ads
tablebi ask "SELECT platform, roas(SUM(conversion_value), SUM(cost)) AS roas,
             SUM(cost) AS spend
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY platform ORDER BY spend DESC"

Three details in that query are doing quiet work. roas(…) is a definition macro — the engine owns the arithmetic (ctr, cpc, cpm, cpa and cvr ship too), so the agent can't re-derive a ratio wrong. The window anchors to MAX(date) instead of current_date, so a source that syncs on a lag doesn't silently shrink it. And the answer arrives with a trust block — per-source freshness, caveats, lineage — as plain text in the transcript. The agent reads it the way it reads everything else; there's no second tool call to fetch metadata.

Keeping the result is one more command:

tablebi pin --title "Cross-channel ROAS" \
  --widget "ROAS by platform (28d)::line=SELECT platform, roas(…) FROM facts …"
✓ published → https://dk.tablebi.com/d/dsh_…  (public, read-only, self-refreshing)

That URL is public, read-only, and refreshes itself as sources sync — here's a live one pinned exactly this way.

Now run the same job through the MCP shape. Register the server (tablebi install --mcp), let the host spawn it each session, and the agent calls a query tool with the SQL escaped into a JSON string argument. The engine is deterministic either way, so the numbers come back identical — this is not a correctness argument. What changed is the plumbing: a server process to manage, schemas riding along in the session, SQL living inside a JSON field, one more config surface that can drift. Same destination, more moving parts — and none of them made the agent more capable.

When the MCP server is the right call

None of this makes MCP a mistake. It makes it fit-for-purpose, with a narrower purpose than the ecosystem hype suggests. Reach for the server when:

• The host can't run commands. Claude Desktop, Cowork, web and mobile agents have no shell — MCP is the only door in. Same backend, different entrance.
• Policy forbids process execution. Some environments lock agents to an allow-list of MCP servers precisely because schema'd calls are easier to audit and approve than arbitrary shell. If that's your security model, MCP is the point, not a workaround.
• You need server push. Resource subscriptions and notifications have no CLI equivalent; a command can only pull.
• The host builds UI from schemas. Approval dialogs, generated forms, structured tool catalogs — schema-driven hosts get real value from typed definitions.

For TableBI, all of that folds into one flag:

# only if your host can't run the CLI
tablebi install --mcp

The default install never touches MCP; the flag exists for the rare setup that needs it. The decision rule we'd offer for any tool, not just ours: does the agent have a shell, and can the tool behave as a command? Then ship a CLI and a skill. If either half fails, that's what MCP is for.

Before you go shopping for MCP servers

A lot of Claude Code MCP searches end at a directory of servers, so here's the evaluation rule this post implies: before adding a server for tool X, check whether X ships a CLI your agent can already run. If it does, you probably need a skill, not a server — and the integration is one npm i -g away instead of one more entry in your MCP config. Save the server slots for tools that genuinely need a live channel, and for hosts that genuinely can't exec. For a CLI-native agent, a shorter list of MCP servers usually isn't a weaker setup. It's a stronger one. The same rule applies in reverse if you build tools for agents: ship the CLI first, and add the server for the hosts that need it.

FAQ

npm i -g @tablebi/cli && tablebi install