I still prefer MCP over skills

Original Article ↗ Hacker News Discussion ↗

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.