MCP and Skills: Two Complementary Layers of the AI Stack

There is a persistent confusion in the AI developer community about where MCP ends and Skills begin. Every week someone asks a variation of the same question: "Should I build an MCP server or a skill?" The answer is almost always: you might need both, because they solve fundamentally different problems.

Disclaimer: Some of the technical details in this analysis draw on CCLeaks material -- AI-generated content that reverse-engineers Claude Code internals. This content may contain errors, is not affiliated with Anthropic, and should be treated as signal reading rather than confirmed documentation. We reference it to illustrate architectural patterns, not to assert definitive product roadmaps.

Key Takeaways

• MCP (Model Context Protocol) is the connection layer -- it connects AI agents to external APIs, databases, and services via 6 transport types and 7 server scopes.
• Skills are the intelligence layer -- they encode domain expertise, workflows, and decision logic on top of MCP's raw capabilities.
• The best solutions combine both: MCP servers handle authentication and atomic operations, skills orchestrate them with domain intelligence, and hooks wire them together.
• Skills can execute inline (shared context) or forked (clean slate) -- choosing the right mode is a critical design decision.
• Build MCP when the problem is connectivity; build a skill when the problem is expertise. Most real-world problems need both.

Understanding the division between MCP and Skills is not an academic exercise. It determines how you architect extensibility, where you invest your development time, and how much value you capture. Get it wrong and you build plumbing when you needed intelligence, or vice versa.

MCP: The Connection Layer

Model Context Protocol is infrastructure. It solves the problem of connecting AI agents to the outside world -- APIs, databases, SaaS platforms, file systems, cloud services. The CCLeaks material suggests Claude Code's MCP implementation spans roughly 24 files and 500KB of client code. That is a substantial investment in a connection layer, and the scope tells you something about how seriously Anthropic treats external integration.

The transport layer alone reveals the ambition. The signals suggest support for stdio, Server-Sent Events, HTTP, WebSocket, SDK connections, and even a CloudAI proxy. Each transport handles a different deployment context. Stdio works for local tools. SSE and HTTP serve web-based integrations. WebSocket handles persistent connections. The CloudAI proxy hints at managed cloud services where Anthropic brokers the connection.

Server Scopes Define Trust Boundaries

One of the more interesting architectural details is how MCP servers are scoped. The signals point to at least seven scope levels: local, user, project, dynamic, enterprise, claudeai, and managed. This is not just organisational tidiness. Each scope carries different trust assumptions and permission boundaries.

A local MCP server runs on your machine with your credentials. A managed server runs in Anthropic's infrastructure with their security controls. An enterprise server might sit behind corporate firewalls with specific compliance requirements. The scope system means the same MCP protocol can serve wildly different deployment environments without changing the tool interface.

Tool Naming and Conflict Resolution

MCP tools follow a namespacing convention: mcp__{server}__{tool}. This prevents naming collisions when multiple MCP servers are active simultaneously. When conflicts do arise, the resolution order appears to be: built-in tools win first, then MCP tools, sorted for cache stability. That last detail -- cache stability -- reveals how performance-conscious the architecture is, as we explored in our analysis of Claude Code's 43-tool architecture. Consistent ordering means prompt caches stay valid longer.

Authentication Is the Hard Part

The authentication signals are telling. OAuth with callback ports, XAA (Cross-App Access), and token refresh mechanisms suggest MCP is designed for real-world enterprise authentication, not just toy API keys. XAA in particular is interesting -- cross-application access implies that an MCP server can authenticate against services on behalf of the user across application boundaries. That is the kind of plumbing that enterprise adoption requires.

Skills: The Intelligence Layer

While MCP asks "what can I connect to?", Skills ask "what do I know how to do?" Skills encode domain expertise, workflows, decision frameworks, and specialised knowledge. They are not about connecting to external services. They are about making the agent smarter in specific domains.

The signals suggest three types of skills in Claude Code: bundled (roughly 19 compiled into the binary), disk-based (stored in .claude/skills/), and MCP-based (skills that wrap MCP tools with higher-level logic). Each skill has a name, description, aliases, a whenToUse trigger, argument hints, allowed tools, and optionally a model override.

That last property -- model override -- is notable. It means a skill can specify that it should run on a different model than the default. A complex architectural planning skill might request a more capable model, while a simple formatting skill might use a lighter one. This is resource-aware intelligence routing, and it matters for cost optimisation at scale.

Execution Models: Inline vs Fork

Skills can execute in two modes: inline (same context) or fork (separate context). This distinction has profound implications for skill design.

Inline execution means the skill shares the conversation context. It can see everything the user has discussed, reference previous outputs, and build on existing work. The tradeoff is that it consumes context window space and competes with other content for the agent's attention.

Forked execution runs the skill in a separate context. The skill gets a clean slate, does its work, and returns results. It cannot see the broader conversation, but it also cannot be confused by irrelevant context. For deterministic workflows -- running tests, formatting code, generating boilerplate -- forking is often superior.

The best skill builders think carefully about which execution model fits their use case. A code review skill benefits from inline execution because it needs to understand the conversation about what the developer is trying to achieve. A database migration generator benefits from forked execution because it needs clean, deterministic output regardless of the surrounding conversation.

The Complementary Relationship

Here is where the confusion dissolves. MCP and Skills are not competing approaches. They are complementary layers in a stack.

MCP provides capabilities. It gives the agent the ability to read a database, call an API, write to a file system, interact with a SaaS platform. These are atomic operations -- individual tools that do one thing.

Skills provide intelligence. They tell the agent when to use those capabilities, in what order, with what parameters, and how to interpret the results. A skill might orchestrate five MCP tools in sequence, apply domain-specific logic between each step, and produce a synthesised output that no individual tool could generate.

Consider a practical example. An MCP server for Jira provides tools: create issue, update issue, search issues, add comment. These are useful but low-level. A "Sprint Planning" skill uses those Jira MCP tools but adds intelligence: it analyses the backlog, estimates velocity based on historical data, suggests sprint scope, identifies dependency risks, and produces a planning recommendation. The MCP server is the plumbing. The skill is the expert.

The Hooks Layer Connects Them

The signals suggest roughly 20 hook events covering the tool lifecycle, session events, and configuration changes. Hooks are the connective tissue between MCP and Skills. A hook can trigger a skill when an MCP tool produces certain output. A skill can register hooks that fire when specific conditions are met.

This three-layer architecture -- MCP for external connectivity, Skills for domain intelligence, Hooks for event-driven coordination -- is a complete extensibility platform. Each layer has a clear responsibility, and they compose naturally.

When to Build an MCP Server

Build an MCP server when:

• You are wrapping an external API or service. If the core value is connecting to something outside the agent, MCP is the right abstraction. Database access, SaaS integrations, cloud service management, hardware interfaces -- these are MCP territory.

• Multiple skills or agents need the same connection. MCP servers are shared infrastructure. If your Postgres connection will be used by a migration skill, a query optimisation skill, and an analytics skill, build it once as MCP.

• The operations are atomic and composable. MCP tools should do one thing well. search_issues, create_pr, read_file -- each is a self-contained operation that different consumers can compose differently.

• Authentication and connection management is the hard problem. If 80% of the engineering effort is getting OAuth tokens, managing connection pools, or handling rate limits, you are building infrastructure. That is MCP's job.

When to Build a Skill

Build a skill when:

• You are encoding expertise, not connectivity. If the value is in knowing what to do (not just how to connect), build a skill. Code review standards, architectural patterns, domain-specific workflows, compliance checklists -- these are knowledge, not plumbing.

• The workflow requires multi-step orchestration. If the task involves reading context, making decisions, calling multiple tools in sequence, and synthesising results, a skill wraps that intelligence. An MCP server cannot express "if the test coverage drops below 80%, check which files changed, generate missing tests, and open a PR."

• The output needs interpretation or formatting. Raw API responses are rarely what users want. Skills transform, filter, prioritise, and present information in ways that are useful for specific domains. A "Security Audit" skill does not just list CVEs -- it prioritises them by your tech stack, suggests fixes, and estimates effort.

• You want to control the execution context. Skills can specify whether they run inline or forked, which tools they are allowed to use, and even which model processes them. That level of control -- including how skills interact with Claude Code's permission model -- does not exist at the MCP layer.

Combining Both: The Power Pattern

The most effective solutions combine both layers. Here is the pattern:

1. MCP server handles authentication, connection management, and atomic operations for an external service.
2. Skill provides the domain intelligence, workflow logic, and user-facing interaction that orchestrates those MCP tools.
3. Hooks wire them together for event-driven automation.

A deployment pipeline might look like this: an MCP server for GitHub (PRs, checks, deployments), an MCP server for your cloud provider (infrastructure state, scaling), and a "Release Manager" skill that orchestrates both -- checking CI status via GitHub MCP, verifying infrastructure readiness via cloud MCP, making go/no-go decisions based on deployment policies, and executing the release sequence.

No single MCP server could encode that workflow. No skill could work without the MCP connections. Together, they are a complete solution.

What This Means for the Market

The complementary nature of MCP and Skills creates a layered marketplace opportunity. MCP servers are infrastructure -- they tend toward commoditisation because the value is in reliability and compatibility, not differentiation. The fifteenth Postgres MCP server adds little marginal value.

Skills are where differentiation lives. Two skills can use the same MCP servers but encode completely different expertise. A "Junior Developer Onboarding" skill and a "Staff Engineer Architecture Review" skill might both use GitHub and Jira MCP tools, but they deliver fundamentally different value.

For skill builders, the strategic move is to build on top of existing MCP infrastructure rather than reinventing connectivity. Let someone else maintain the Slack MCP server. Focus your energy on the intelligence layer -- the domain expertise that makes your skill worth installing.

The AI extensibility stack is settling into clear layers: models at the bottom, MCP for connectivity, Skills for intelligence, and marketplaces for distribution. Understanding which layer you are building in is the first strategic decision every AI developer needs to make.

MCP vs Skills: Comparison Table

Frequently Asked Questions

What is the difference between MCP and Skills?

MCP (Model Context Protocol) is the connection layer that gives AI agents access to external services like APIs, databases, and SaaS platforms. Skills are the intelligence layer that encodes domain expertise, workflows, and decision logic. MCP provides atomic capabilities; skills orchestrate them with context and judgment.

When should I build an MCP server instead of a skill?

Build an MCP server when the core challenge is connectivity -- wrapping an external API, managing authentication, or providing shared infrastructure that multiple skills will use. Build a skill when the value is in knowing what to do with that connectivity: multi-step workflows, domain-specific logic, or contextual decision-making.

Can a skill use MCP tools?

Yes, and this is the recommended "power pattern." A skill orchestrates MCP tools with domain intelligence. For example, a "Release Manager" skill might use a GitHub MCP server for PR checks and a cloud provider MCP server for infrastructure state, adding release policy logic that neither MCP server could provide alone.

What is Model Context Protocol?

Model Context Protocol (MCP) is a standard for connecting AI models and agents to external data sources and tools. It supports multiple transport types (stdio, SSE, HTTP, WebSocket) and provides a consistent interface for tool discovery, authentication, and execution across different deployment environments.

What execution modes do skills support?

Skills can execute inline (sharing the conversation context, able to reference previous discussion) or forked (running in a separate clean context for deterministic output). Inline is better for context-dependent tasks like code review; forked is better for deterministic workflows like code generation or test running.

---

Explore production-ready AI skills at aiskill.market/browse or submit your own skill to the marketplace.