Know When to Build a CLI.
Some services already have great MCPs (Claude Desktop calls these connectors). Others need a custom CLI. This is the decision tree: when the MCP is fine, when a borrowed CLI fits, when to wrap a partial MCP, and when the right move is to scrape the API docs and build your own.
- A decision tree for every new service. Five branches, each with a clear verdict. No more guessing whether to spend the day building.
- Four criteria for spotting an MCP that's about to fail you: capability gap, multi-account need, auth ownership, and how often you actually run it.
- Three worked examples Slack, Google Workspace, and N8N. Each illustrates a different branch of the tree and why the pattern picks it.
Run the decision with Claude.
Name a service you're considering integrating, and have Claude walk the tree with you. The output is a verdict (use MCP, borrow, wrap, or build) and the reasoning behind it.
How this fits in the OS.
A service you want your agent to reach into (Slack, Notion, Google Workspace, a vertical SaaS tool you live in), and a rough sense of which workflows you actually run there.
Whatever the vendor ships (MCP, CLI, raw API), the AI Build Lab blueprints channel, and the public CLI shelf. No build required to make the decision itself.
The right next move for any new integration. A clear "yes, this is worth a day of build" or "no, the MCP is fine, write better skills on top of it" answer.
The frame.
Building a CLI is roughly a one-day job. The decision below is which day it's worth spending and which day it isn't. The mistake people make is treating "CLI vs. MCP" as a default-on or default-off rule. It's neither. There are five branches, and four signals decide which one fits.
The four signals
- Capability gap. Does the vendor's MCP actually cover what you need? Concrete operations, not theoretical ones. If you've hit a wall on a specific task, the gap is real. If you're worried about hypothetical future limits, it's not.
- Multi-account. Do you need to switch between two or more accounts on the same service? Personal and work Google. Two Slack workspaces. Three Notion teams. MCPs handle one account at a time. CLIs route per command.
- Auth ownership. Is the OAuth flow yours to handle, or is the vendor's MCP doing the painful part for you? If the auth is painful and the MCP handles it, the bar to replace the MCP gets higher.
- Frequency. Is this a workflow you run once a month or one you run daily? The CLI plus skills pattern compounds with use. Building infrastructure for a once-a-quarter task is over-engineering.
Hold those four in your head as you walk the branches below.
The decision tree.
Five branches, in the order you check them. Stop at the first one that fits.
The MCP covers everything you need. Use it.
The vendor ships an MCP. You looked at what it actually does. It handles every operation in your workflow. You aren't running multi-account. The auth flow is handled for you.
Don't build. Toggle the MCP on. Write skills on top of it for your specific workflows. The capability gap has to be real, not theoretical. If you can't name the specific thing the MCP can't do, the gap isn't real yet.
Verdict: Use the vendor MCP. Revisit only if you hit a concrete wall.
Someone already shipped the CLI. Borrow it.
The MCP has a gap, but the AI Build Lab team or the broader ecosystem already shipped a CLI for this service. Slack (Blueprint #10, 306 web API methods). N8N (Blueprint #8). Zoom (Blueprint #5). Google Workspace (26.5k stars on GitHub). Firecrawl. MacWhisper.
Install the existing CLI. Write your own skills on top for the workflows specific to you. The plumbing is solved. Your time goes to the workflow layer, not the API wrapper.
Verdict: Go to Borrow a Working CLI. Install one in under 10 minutes.
The MCP covers most of it. Wrap the gap with a thin CLI.
The vendor's MCP handles most of your workflow, but there's one or two operations it can't do that you need. The full API can do them. You don't want to throw out the MCP, you want to fill the gap.
Build a thin CLI that wraps only the missing operations. Leave the MCP on for everything it already handles. The CLI is a patch, not a replacement. You'll spend a few hours instead of a full day, and the MCP keeps doing the work it was doing well.
Verdict: Build a minimal CLI scoped to the gap. Keep the MCP as primary for the rest.
No MCP, no shipped CLI, or you need multi-account. Build it.
Any one of these is enough:
- The service has no vendor MCP at all.
- The MCP exists but covers a small slice of what the API can do, and the slice doesn't include your core workflow.
- You run two or more accounts on the service. MCPs are structurally one-account-at-a-time. The CLI fixes that.
- You need helper commands tuned to your conventions (your channel names, your sheet schema, your client routing). MCPs can't host that. CLIs can.
Build the CLI from the API docs. The four-phase pattern walks the whole thing. Scrape the docs, build the tool, write skills, cache the spec.
Verdict: Go to Build Your First CLI. Plan a day.
You don't actually need this integration. Skip it.
The workflow you'd run with this service is once a month. The docs are gated or paywalled and you can't scrape them. The auth flow is awful and the MCP isn't handling it for you. Or the task is something a human does in 90 seconds anyway.
Don't build the integration. Not every service deserves agent access. The cost of maintaining a bad integration outweighs the value of running it through your agent. Save the day for a service you'll actually use daily.
Verdict: Leave it manual. Revisit in three months if the frequency picks up.
MCP vs. CLI at a glance.
Side-by-side, in case the tree above leaves any ambiguity. Same row, two columns. The CLI wins on capability and structure; the MCP wins on setup speed and auth.
| Dimension | Vendor MCP | Custom CLI + Skills |
|---|---|---|
| Capability coverage | Subset of the API (vendor's choice) | Full API |
| Customization | None, take it or leave it | Tailored to your workflows |
| Multi-account | One at a time, reconnect to switch | Per-command credential routing |
| Context cost | Tool definitions loaded into context every session | Just the command and its output |
| Maintenance | Vendor updates, may lag or break | You own it, you maintain it |
| Speed to set up | Fast, toggle on | Slower, ~1 day to build |
| Agent understanding | Generic tool descriptions | Skills encode your conventions |
| Identity on writes | Posts as whoever connected the MCP | Posts as a named service identity (e.g., a bot user) |
The Google Workspace CLI at github.com/googleworkspace/cli has 26.5k stars. It exists because Google's own MCP doesn't cover enough. Thousands of teams chose the CLI route over the vendor MCP. The demand for full API coverage over vendor-gated MCPs is real and validated outside the AI Build Lab.
Three worked examples.
Each one illustrates a different branch of the tree, with the signal that decided it.
Slack: build (or borrow Blueprint #10)
Slack's official CLI is purely developer tooling for building Slack platform apps. It can't post messages, read channels, search, or manage users. The Slack MCP exists but posts as whoever connected it, so every automated message looks like it came from you personally. That's a structural problem for any workflow that runs unattended.
The fix: a custom CLI that posts as a named bot identity, wrapping all 306 Slack web API methods. The AI Build Lab team already shipped this as Blueprint #10 (PyPI: slack-toolkit). Borrow it.
Signal that decided it: capability gap (the MCP can't post as a bot) + the borrow option existed.
Google Workspace: borrow the public CLI
Google ships an official MCP. It works fine for one account. The moment you have two Google accounts (personal and work, or work and client), the MCP can only hold one at a time. Switching means disconnect and reconnect. There's no clean way to say "use the work account for this command, the personal one for that one."
The fix: the public Google Workspace CLI at github.com/googleworkspace/cli. It routes credentials per command (explicit flag, per-project default in your CLAUDE.md, per-recipient domain, or skill-level preset). 26.5k stars. Ships with its own skills. Install it, write your own skills on top.
Signal that decided it: multi-account need. A shipped CLI handled it cleanly.
N8N: borrow Blueprint #8 (no MCP needed)
N8N has no official MCP at the workflow-management layer. You can't list workflows, debug failed executions, search 543+ nodes, or migrate workflows between cloud and self-hosted instances without a CLI. The AI Build Lab team ships Blueprint #8 (PyPI: n8n-toolkit) precisely because that gap was structural.
The fix: install n8n-toolkit, write skills on top for your specific N8N workflows. The package handles auth via Infisical or 1Password, configures profiles for multiple instances, and ships 11 starter skills.
Signal that decided it: no MCP existed + a shipped CLI handled the whole surface.
The mistakes to avoid.
- Building a CLI before you've hit the wall. The capability gap has to be a real operation you've tried and failed to run, not a hypothetical future limit. Use the MCP. Find the wall. Then build.
- Skipping the borrow step. The first move on any new service is to check if someone already shipped a CLI. Blueprints channel. PyPI. GitHub. Borrowing saves a day. Building when a borrow exists is reinventing.
- Building for a service you barely use. The CLI plus skills pattern compounds with frequency. If the workflow runs once a month, the MCP is fine. Save the build day for daily-use services.
- Treating multi-account as a capability problem. It isn't. It's a structural one. You can't fix it with better skills on top of an MCP. The CLI is the fix because credential routing has to live in the tool, not the skill.
- Wrapping the entire MCP when only one operation is missing. Don't. Wrap only the missing operations as a thin CLI patch. Leave the MCP doing the work it does well. Branch 03 of the tree exists for exactly this reason.
Where to go next.
The framework gives you the verdict. The next move depends on which branch you landed on.