# I Still Prefer MCP Over Skills

David Mohl's April 2026 post draws a clean line between two mechanisms for extending LLM capabilities — MCP (Model Context Protocol) and Skills (markdown-file-based instruction injection) — and argues the industry is using skills where MCP belongs.

The distinction he proposes is simple: skills are for *knowledge*, MCP is for *access*. A skill teaches the LLM how to use a tool that's already present — `git`, `curl`, `gcloud`, an internal CLI. It codifies workflow conventions, documents quirks, and prevents the model from re-discovering the same pitfalls every session. An MCP server gives the LLM a live connection to a service — calendar, browser, database, search index — through a typed tool interface with proper authentication.

## Why the distinction matters

When a skill's instructions start with "install this CLI first," Mohl argues, the skill is doing MCP's job poorly. The failure modes compound:

**Portability breaks down.** Skills that depend on local CLIs only work in compute environments — Claude Code, Codex, Perplexity Computer. Standard Claude, ChatGPT, and mobile clients can't execute them. A remote MCP server is just a URL; it works everywhere a client can make HTTP requests.

**Deployment fragments.** Each skill-as-service needs its own binary, its own install path (npm, brew, pip, go install), its own secret management (`.env` files, environment variables, ephemeral credentials). MCP centralizes this: the server handles authentication (OAuth for remote, process-level for local) and the client only knows the endpoint.

**Updates become manual.** Change a skill and every user needs to pull the new markdown. Change an MCP server and every connected client gets the update on the next call. Remote MCP's update semantics are the same as a web API's — which is the point.

**Context bloat.** A skill loads its full SKILL.md into the context window — instructions, examples, edge cases, everything, regardless of whether the model needs all of it right now. MCP exposes typed tool signatures (name, description, input schema) that the client can present selectively. The full documentation of how a tool behaves goes in the server, not in the model's context.

## Where skills still win

Skills are the right choice when there's nothing to connect to. Teaching the model that your team's deploy command is `just deploy staging` and that it requires a clean git state — that's knowledge, not a service. Documenting that a specific MCP server uses `YYYY-MM-DD` date formats and caps search results at 50 — also knowledge. Standardizing org jargon so the model doesn't confuse "release" (marketing event) with "release" (git tag) — knowledge.

Mohl's framing: skills are cheat sheets, not connectors. The cheat sheet can *annotate* an MCP by documenting its behavioral quirks, but it shouldn't *replace* the MCP by wrapping a CLI that does what a server should.

## The hybrid pattern

In practice, Mohl runs both. MCP servers handle live service control (DEVONthink via a local MCP, microfn and Kikuyo via remote MCPs, MCP Nest for tunneling local MCPs to remote clients). Skills document how those MCPs behave — parameter gotchas, format requirements, non-obvious tool names. The layering is clean: the MCP provides the capability, the skill teaches the model to use the capability well.

## How this maps to the wiki's agent tooling

This Second Brain uses Claude Code skills heavily — `/ingest`, `/query`, `/lint`, `/webfetch` are all skill files that inject instructions into the conversation. By Mohl's taxonomy, these are knowledge-layer skills (they teach the model a workflow using tools it already has — Read, Write, Glob, Grep, WebFetch). No CLI to install, no service to connect to. That's the correct use of skills.

The Telegram integration, by contrast, is an MCP server — it gives Claude a live connection to the Telegram Bot API through typed tools (`reply`, `react`, `edit_message`). Mohl would call this the correct use of MCP. If instead someone had built "a Telegram skill" that documented how to `curl` the Bot API, that would be skills doing MCP's job badly.

[[botctl]] has its own SKILL.md system with three-level hierarchical lookup and on-demand loading — structurally the same as Claude Code's skills, with the same knowledge-layer purpose. Mohl's context-bloat concern about loading full skill files is mitigated in botctl by the on-demand fetch (Claude asks for a skill when it needs it, rather than front-loading everything). Claude Code's skill system works the same way.

[[build-your-own-openclaw]] covers skill extension in Phase 1 (step 2) as the mechanism for teaching an agent new capabilities without code changes. Mohl would say that's correct for knowledge injection; for service access, the tutorial's Phase 2 (event architecture, multi-channel) is where MCP-like patterns should take over.

[[toolbox/cli-anything]] is the hybrid pattern shipped end-to-end: HKUDS's plugin generates *both* halves at once for any GUI app — a Python Click CLI that calls the real backend (capability layer) and a `SKILL.md` derived from the CLI's own Click decorators (knowledge layer). The constraint is that "service" is a local subprocess, so this only works for compute-equipped agent harnesses; it doesn't solve Mohl's portability argument for mobile or web clients, which would still need a remote MCP.

The terminology proposal — renaming skills to `LLM_MANUAL.md` and MCP to "Connectors" — hasn't gained traction, but the underlying distinction (manual vs connector, knowledge vs access) is sharp enough to be useful regardless of naming.