MCPs, CLIs, and skills: when to use what?

MCPs, CLIs, and skills: when to use what? | jngiam MCPs, CLIs, and skills: when to use what? 12 Mar, 2026 If someone tells you "MCPs are dead" or "CLIs are overhyped," they're missing bigger picture. I use Skills, CLIs, and MCPs, and the mix is completely different between my personal and work setups. My personal and work AI setups use the same three primitives: skills, CLIs, and MCPs, but the mix is completely different. Personal: 12 skills, a handful of CLIs, direct API integrations, 4 MCP servers. Work: 16 skills, 10+ MCP servers, Slack integrations on every agent, OS-level sandboxes, and very few CLIs. Same person (me!), different toolset, completely different production configurations. I had this exact conversation with a friend recently who was trying to rank these: "use CLI first, then skills, then MCP." They're not ordered substitutes though, they solve fundamentally different problems, and the "which one is best?" question stopped making sense… it's not a competition! Skills: your team's know-how, codified Skills are documentation for processes: how a team does a specific thing, written so Claude can follow it. And the key thing about skills is that they're deeply company-specific and deeply personal, which means they can't come unmodified from a vendor. They have to be tuned by the people doing the work (though you may want to look at published Skills for inspiration, or as starting points). It's like onboarding a new employee: I'd walk them through how our team handles code review, show them how we write front-end code, explain the quirks of our sales methodology. Then I'd watch them do it and give feedback. Skills encode all of that: the instructions, the gotchas, the validation (with scripts). My writing skill is probably my most-used. It encodes my tone, phrasing patterns, sentence structures I prefer, things to avoid. Without it, every draft reads like generic AI output. I also have a sales qualification skill that walks through MEDDPICC (economic buyer identification, champion building, decision criteria) and a call analysis skill based on Gong's best practices that breaks down talk percentage, objections surfaced, deal health signals, and next steps. Front-end at Vercel is different from front-end at Netlify; a sales methodology depends on the market; code review standards depend on the codebase, and this nuance is exactly what skills can uniquely capture. On the personal side, I have skills for generating PDFs with LaTeX, parsing Apple Health data, syncing electrical/water utility data, generating home energy reports, and more. On the work side: deal pipeline reports, order form generation, procurement ticket tracking, website analytics, LinkedIn engagement tracking. Every one of these captures domain knowledge I'd otherwise keep re-explaining session after session. The underrated part is the scripts inside skills. Anthropic's own PDF, HTML, and Excel skills are a good example: the most important code is the validation that ensures nothing exceeds page boundaries and output conforms to spec, not the generation logic. The skill tells Claude how to do the work (generation), then the script verifies it was done right (validation). Non-engineers actually find skills quite accessible, since a skill is just instructions in a file: there's nothing to install, no terminal required. For mixed teams, skills bridge the gap between technical and non-technical users in ways that CLIs can't. CLIs: composable, hackable, developer-native When I'm in build and hacking mode, CLIs are the natural interface. Bash, grep, and jq are small tools that pipe into each other, GitHub CLI handles PRs and issues, Cloudflare Wrangler handles deployments, and npm run dev / npm test are second nature. Almost every dev tool I use ships a CLI, and they compose well together. The composability advantage is real. Claude can curl | jq | grep | awk in ways that would be awkward to express as sequential MCP tool calls. And some tools are honestly just better as CLIs: I use the Playwright CLI to convert HTML pages to PDF, which works better than routing that through a Playwright MCP in the browser, because I can pipe the output directly into further processing. My personal setup leans heavily on CLIs and direct API integrations. I have GitHub Actions workflows syncing data from Strava, air quality monitors, Sense energy monitors, Rachio irrigation, even my HVAC system. Scripts call these APIs directly; no MCP layer needed, because I'm the only user, I manage the credentials, and I'm comfortable in the terminal. For a single developer hacking on their own setup, this is honestly hard to beat, and where I think a lot of the "CLI is all you need" talk comes from. But CLIs have real limitations beyond the developer bubble. There's no consistent interface across them: credential management, flag conventions, error handling all work differently from one CLI to the next (something David Cramer has pointed out ). I recently tried walking some non-technical teammates through installing the GitHub CLI on Windows via PowerShell, and it was genuinely painful. They couldn't even get started. The other hard limit is session-level access control. Say I want an agent to use the GitHub CLI but not run destructive operations. There's no consistent way to enforce that across CLI tools; I'd have to wrap each one differently, and since there's no consistency across CLIs, every wrapper would work differently. MCPs: authenticated SaaS access with guardrails When I look at my work setup, the mix shifts almost entirely to MCPs. We run 10+ background agents on schedules (heartbeat every 10 minutes during business hours for some), and each one gets a scoped virtual MCP with exactly the tools it needs. There's Max the deal agent who gets Attio CRM + LinkedIn + Outlook email, Charlie for call analysis who gets Attio meetings and call transcripts, and Dan who does engineering with Claude and Codex access. Each agent sees only what it should see. This is where MCPs really shine: background agents running unsupervised. When an agent runs on a cron schedule without a human watching, access control stops being a nice-to-have. I need to know that Charlie can read call transcripts but can't send emails, Max can create notes and draft emails only, and that Dan can make PRs but not commit to the repo without approval. With MCPs, that's defined once in the server configuration. With raw CLIs running in a background job, enforcing those boundaries is close to impossible. OAuth is built into the MCP spec, so authentication is a natural fit for SaaS products. Connecting and disconnecting an MCP server is a single click in a web UI, versus running terminal commands to reset tokens or delete JSON state files. For non-developers, this is the only viable path. MCP servers expose a consistent list_tools / run_tool interface, which means Claude can discover and invoke tools the same way regardless of the underlying service. Because the interface is uniform, I can scope access per session: Claude's allowed_tools parameter specifies exactly which tools are available. This matters more than people realize. However, most developers using Claude Code with the Linear or GitHub MCP don't disable dangerous tools (like delete functions) because disabling a single tool inside an MCP is tedious. Nobody does it. Emerging MCP gateways take this further into enterprise territory: fine-grained permissions, audit trails, control planes across all deployed agents. There's no equivalent concept for CLIs. MCPs do have current limitations. Sending large inputs (e.g., uploading a JPEG via a remote MCP server) is awkward because the protocol was designed for control-plane operations, not bulk data transfer. Receiving large outputs is partially solved since agent harnesses now write MCP tool results to disk so CLI tools can process them, but piping between MCP tools still isn't native the way | chains CLI output. When to reach for which Skills CLIs MCPs What it is Process know-how Dev toolchains Authenticated SaaS access Best for Everyone (personal or team) Developers in build mode Enterprise, non-developers, background agents Auth model N/A On-device tokens OAuth built-in Access control N/A Hard to scope per session allowed_tools per session or MCP gateways Composability N/A Native piping Output-to-disk workaround Large inputs N/A Natural Awkward today Credential UX N/A Terminal commands Single-click UIs In build mode on my local machine, I reach for CLIs because the composability advantage is hard to beat when piping outputs between tools. I layer skills on top to encode the domain judgment: how I write, how I review code, how I qualify deals. When the setup involves a team, non-developers, or background agents that need authenticated SaaS access, I reach for MCPs. The auth story and credential UX make the difference between "connected in one click" and "stuck on step 3 of a PowerShell tutorial." For company-specific process and judgment: skills, always. CLIs and MCPs give Claude tools; skills give Claude the context to use them well. Why "X is dead" takes are always wrong here Go into developer/hacker communities and the instinct is "just use CLIs," but go into enterprise and non-developer communities and people are actively figuring out how to connect Claude or ChatGPT to every SaaS tool they use via MCP. Both groups are describing real experiences; the confusion comes from treating one answer as universal. There's also a convergence happening. Experimental projects exist that take an MCP server and expose it as a CLI tool, and vice versa. The boundaries are blurring, but the underlying paradigms will persist because they serve different primary audiences. But none of these limitations are fundamental; there are known patterns (code execution, tool disclosure) that clients have already started to make. My setup keeps evolving as the tools mature, and the mix looks completely different between personal and work contexts. That's probably the most useful thing I can share: I stopped trying to pick a winner and started letting the context decide. Once I did, everything got a lot more productive. #agents #claude-code #cli #enterprise #mcp #skills