· 5 min read ·

The Protocol Bet: Why MCP Compounds Better Than Claude Code Skills

Source: hackernews

The conversation around MCP and Claude Code skills keeps coming up in developer circles, and David’s post captures the preference clearly: even knowing what skills offer, MCP is still the better choice for serious tool integration. I’ve been living in this space building Discord bots and connecting them to external systems, and the preference reflects something deeper than a feature checklist. It reflects how tool ecosystems compound over time.

What each thing actually is

MCP, the Model Context Protocol, is an open standard Anthropic published in November 2024. At its core, it is a JSON-RPC 2.0 protocol that any server can implement to expose tools to any MCP-compatible client. The handshake is straightforward: a client calls tools/list to discover what the server offers, then tools/call to invoke a specific tool with typed arguments. Each tool definition includes a name, a description the model reads to decide when to use it, and an inputSchema expressed as a JSON Schema object.

{
  "name": "search_issues",
  "description": "Search GitHub issues by keyword and state",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "state": { "type": "string", "enum": ["open", "closed", "all"] }
    },
    "required": ["query"]
  }
}

MCP servers communicate over two transports: stdio for local processes, and HTTP with Server-Sent Events for remote services. Claude Code, Cursor, Windsurf, Continue, and a growing list of other tools all speak this protocol.

Claude Code skills are a different mechanism entirely. They are markdown files stored in .claude/commands/. You invoke them with a /command-name syntax. A skill file can contain system instructions and an $ARGUMENTS placeholder, and it can embed shell commands with a !command prefix that run before the model receives the result.

# fix-pr

Review the PR at $ARGUMENTS. Focus on:
- Security issues
- Performance regressions
- Missing error handling

!gh pr view $ARGUMENTS --json body,files

Skills are lightweight. There is no server, no protocol, no schema. You write markdown, drop it in a directory, and it works. That simplicity has real value for personal use.

The portability gap

The practical problem with skills is that they are private to Claude Code. An MCP server you write today works in Cursor tomorrow without modification. It works in any IDE or agent runtime that implements the protocol. When Anthropic ships a new Claude Code release months from now, your MCP tools continue working as long as the protocol is stable. Your skills work only if the slash-command format stays the same, and only inside Claude Code.

For teams where some developers use Cursor and others use Claude Code, MCP lets you write the integration once. Skills require you to either standardize on one tool or maintain parallel implementations.

The ecosystem is already building around MCP in ways that have no equivalent for skills. There is a growing list of community MCP servers covering filesystem access, database queries, browser automation, and API integrations. Each of those servers is portable to any MCP-compatible client. None of them could be a skill in any meaningful sense, because skills cannot execute arbitrary code at inference time.

The execution model difference

This is where the comparison becomes structural rather than cosmetic. A skill is a prompt template. When you invoke one, the model reads enhanced instructions and responds. You can embed shell commands, but those run before the model sees the result. There is no back-and-forth; the model cannot call a tool that has not already been pre-scripted into the template.

An MCP tool is something the model calls at inference time, after reasoning about whether and how to use it. The model reads a tool’s schema, decides to invoke it, sends structured arguments, receives structured output, and continues reasoning. The loop works like this:

  1. Model receives context and decides to use a tool
  2. Client calls tools/call on the MCP server
  3. Server executes real code and returns structured output
  4. Model receives that output and continues reasoning

That distinction matters when your tool needs to branch on intermediate results. A skill that fetches a GitHub PR and summarizes it is a one-shot template. An MCP tool that fetches a PR, notices a failing check, then queries the CI logs to explain the failure is something the model reasons through dynamically, chaining real tool calls in sequence based on what it finds.

For bot development, the MCP model maps cleanly onto what bots do. A bot that manages GitHub issues, monitors CI, and answers deployment questions needs tools that execute real logic against live systems. Prompt templates do not compose with runtime state.

Schema validation is not ceremony

A common objection to MCP is that defining JSON Schema for every input feels like unnecessary overhead compared to the informality of a skill’s $ARGUMENTS. The schema definition is not overhead in practice, though. It is what makes the model reliable.

When the model calls an MCP tool, the client validates the arguments against the schema before the call reaches the server. The model learns to pass correct arguments because the schema describes what correct looks like. Bad invocations fail clearly rather than producing silent wrong output. When you are building tools that interact with real systems, creating branches, posting messages, running scripts, predictable call behavior matters a great deal.

Skills accept whatever text ends up in $ARGUMENTS. If the model passes malformed input to a shell command embedded in a skill, the failure mode is whatever the shell does with bad arguments. That is a wide blast radius for something a typed schema would have caught at the call site.

Where skills remain useful

Skills are a sensible fit for personal prompt templates used interactively. If you have a consistent way you like to ask Claude to review commit messages, or a recurring template for generating changelog entries, a skill is less friction than an MCP server. The cost-to-value ratio favors the simpler approach when the tool does not need to execute real code, does not need to be portable, and will not serve as shared infrastructure.

The error is reaching for skills when building anything that will outlast a single session or serve more than one person. As soon as you need persistence, real API calls, state between invocations, or compatibility with more than one AI client, skills do not match the problem.

The ecosystem trajectory

Even where skills and MCP overlap on simple use cases, the trajectory of each approach differs substantially. MCP has a published specification, versioned releases, and active development. Third-party tooling is appearing for testing MCP servers and mocking clients in CI. The MCP inspector lets you interactively exercise a server before connecting it to any AI client. None of that infrastructure exists for skills, because skills were never designed to be infrastructure.

Building on an open protocol means improvements to MCP clients benefit your servers automatically. If Claude Code improves how it presents tool results to the model, your MCP servers get that for free. If another AI coding tool adds MCP support, your existing investment transfers there too.

David’s post is correct in a way that extends past personal preference. Choosing MCP over skills is choosing the mechanism built to grow rather than the one built to be immediately convenient. Skills serve a real purpose at the personal productivity layer, and MCP is what you reach for when the work is load-bearing.

Was this interesting?