Map

I Still Prefer MCP Over Skills

Sources ↳ show in map Markdown

I Still Prefer MCP Over Skills

Author: David Mohl Date: April 2, 2026 Source: https://david.coffee/i-still-prefer-mcp-over-skills/ Word count: ~1,850

Summary

David Mohl argues that despite momentum behind "Skills" (markdown-file-based capability injection) as the standard for LLM tool extension, MCP remains the architecturally correct choice for service integration. Skills are for knowledge — teaching an LLM how to use tools that already exist on the host. MCP is for access — giving an LLM a live connection to a service.

MCP advantages for services

  • Zero-install remote usage: point client at a URL, no local binary needed
  • Seamless updates: remote server update propagates to all clients automatically
  • OAuth authentication: no .env files or plaintext secrets
  • True portability: remote MCPs work on Mac, mobile, web — no CLI dependency
  • Natural sandboxing: the LLM interacts through a controlled interface, not raw execution
  • Smart discovery: clients load only needed tool signatures, not entire markdown manuals
  • Auto-updates: local MCPs can use npx -y or uv for transparent versioning

Skill advantages for knowledge

  • Teaching existing CLIs: curl, git, gh, gcloud — the tools are already installed
  • Standardizing workflows: org jargon, naming conventions, deployment patterns
  • Explaining specialized handling: PDF manipulation, date format quirks, parameter limits
  • Documenting secret management patterns: where creds live, how to rotate them

The hybrid pattern

Mohl runs both simultaneously. MCPs handle live service control (DEVONthink, calendar, browser, Notion). Skills document how those MCPs behave — date formats, search parameter limits, non-obvious tool names. The skill is a "cheat sheet" that prevents the LLM from re-discovering the same pitfalls every session. The skill never replaces the protocol layer; it annotates it.

Problems with skills-only

  • ChatGPT, Perplexity, standard Claude can't execute CLIs — only compute environments (Claude Code, Codex) support skill-based approaches
  • Complex deployment: binaries, npm, package managers per skill
  • Fragmented secret management across .env files
  • Context bloat from loading full SKILL.md files vs MCP's typed tool signatures
  • "If a Skill's instructions start with 'install this CLI first,' you've just added an unnecessary abstraction layer"

Terminology proposal

Rename Skills → LLM_MANUAL.md (emphasizes knowledge role), MCPs → "Connectors" (emphasizes integration role).

Personal examples

  • mcp-server-devonthink: local MCP for DEVONthink
  • microfn: remote MCP at mcp.microfn.dev
  • Kikuyo: remote MCP at mcp.kikuyo.dev
  • MCP Nest: cloud tunneling to expose local MCPs remotely