I still prefer MCP over skills

Original Article ↗ Hacker News Discussion ↗

Developers are debating whether Large Language Model agents should rely more on CLI-based tools with Skills files or on the Model Context Protocol (MCP), a standardized way to expose APIs and services to models. Proponents of CLIs and Skills argue they’re simpler, cheaper in tokens, highly composable, and reuse existing tooling and documentation, while MCP advocates emphasize better portability, auth and permission control, suitability for restricted or cloud-hosted environments, and not exposing raw credentials to the model. Many conclude that the two approaches serve different layers — Skills as human- and model-readable “manuals” and workflows, MCP as a tool and data connector — and will likely coexist, with trade-offs around security, context bloat, and operational complexity depending on use case.

Overall framing

  • Most commenters see Skills and MCP as complementary, not mutually exclusive.
  • Underlying divide: local/CLI-centric agents vs. hosted/cloud agents with no shell access.
  • A second, deeper debate: MCP vs “just use APIs/CLIs + skills/markdown”.

When to use Skills vs MCP

  • Skills:
    • Best for encoding static or slowly changing knowledge, workflows, institutional context, and “how to use tool X”.
    • Good for local, developer-controlled environments where CLIs are already installed.
    • Progressive disclosure (hierarchical skills, short front-matter) helps control context use.
  • MCP:
    • Best for giving agents stable, app-owned access to services and data, especially when you don’t control the runtime (web/mobile/chatbots).
    • Useful for persistent, cross-session integrations (e.g., calendar, Jira, Notion, internal systems).
    • Often treated as an “API for agents” or API-discovery layer.

CLI vs MCP vs API

  • Many solo builders strongly favor CLI + Skills:
    • Reuses existing tools, easy to debug and script, naturally composable via shell.
    • Models are well trained on terminal usage and can discover CLIs via --help etc.
    • Avoids running extra servers; often cheaper in tokens and faster.
  • MCP advocates counter:
    • CLIs aren’t available in many hosted/locked-down environments.
    • By the time you wrap CLIs with daemons, proxies, and auth, you’ve reinvented something MCP-like.
    • MCP can sit on top of any API/daemon; it’s “just RPC/HTTP+JSON” with agent-friendly metadata.

Auth, security, and governance

  • Pro-MCP points:
    • Secrets can live in the MCP server, not the agent sandbox; agents never see tokens.
    • Easier to enforce least-privilege, per-user scopes, and audit; good fit for enterprise chatbots.
    • Remote MCP can act as a controlled “data firewall” between agents and sensitive systems.
  • Skeptical views:
    • Similar separation can be achieved with CLIs calling daemons or API gateways.
    • Some existing MCPs expose full user privileges with weak scoping; real-world security is uneven.

Context, composability, and tooling quality

  • Context bloat concerns for both MCP and Skills; mitigations:
    • MCP tool search and dynamic tool updates, sub-agents, and summarization.
    • Skills’ lazy loading and hierarchical design.
  • Strong criticism that MCP tools don’t compose as naturally as CLIs; agents must shuttle data via context instead of Unix-like pipes—though some report success using subagents, caches, or MCP-CLI bridges.
  • Multiple reports of flaky or poorly implemented MCP servers (e.g., Jira, timeouts, partial spec support), which colors perceptions.
  • Broad expectation that both patterns will persist; choice is highly use-case and environment dependent.