Skip to main content

Skills, plugins, and MCP

Discussions around extending AI coding assistants often treat skills, plugins, and the Model Context Protocol (MCP) as interchangeable ways of doing the same thing. In reality, they represent three fundamentally distinct architectural layers: prompt instructions, packaging, and external running processes. Distinguishing between them helps clarify how an agent acquires new context versus entirely new capabilities.

A skill is instructions

A is essentially a directory containing a structured Markdown document. It typically includes a unique name, a concise summary description, and a set of instructions guiding the model through a specific workflow. Typical examples include documenting your team's commit conventions, detailing pre-release validation steps, or describing the schema and access patterns of an internal reporting database.

Crucially, a skill contains no executable code managed by the harness. It is pure guidance injected into the model's prompt context whenever the agent deems it relevant to the task at hand.

The architecture scales cleanly across dozens or hundreds of skills through . Instead of injecting every detailed instruction into the prompt up front, the harness only keeps the skill's name and short description in the standing context window. This baseline overhead is minimal—usually around one hundred tokens per skill. A library of one hundred registered skills might consume around ten thousand tokens of passive context. When an incoming user request matches a skill's description, the harness dynamically pulls the full instruction body into active context. Auxiliary reference files and embedded scripts remain completely unloaded until explicitly referenced, and executing a helper script contributes only its runtime output to the conversation rather than its source code.

A skill does not grant the model new underlying capabilities. If an agent lacks network access to reach your project management tracker, writing a skill that explains your issue-tracking conventions will not allow it to query the API. What a skill changes is how the model exercises its existing abilities: which tools it prioritizes, the sequence of actions it takes, and the stylistic conventions it follows.

The primary trade-off is relying on the model's judgment to trigger them. Because skills load dynamically based on description matching, an overly vague description—such as "helps with documents"—tends to either trigger indiscriminately or get ignored entirely. Crafting a skill description requires the same precision as drafting a tool description: clearly articulating both what the skill accomplishes and the precise circumstances under which it should be invoked.

A plugin is a bundle

A is a versioned, distributable software artifact. Inspecting a plugin bundle reveals a cohesive collection of components: skills, , subagent configurations, deterministic , and MCP server connection settings, all coordinated through a manifest file.

Within this bundle, components serve different operational roles. A slash command gives users a way to explicitly trigger a skill by typing its name, bypassing model inference. A hook, by contrast, executes deterministically on the local machine when predefined harness events occur—such as immediately after saving a file edit or just before executing a tool call. Because hooks execute through the harness without model deliberation, they provide a reliable foundation for enforcing style formatters, linters, and security guardrails.

The primary advantage of a plugin is standardized distribution. Without packaged plugins, rolling out shared workflows across an engineering team requires every engineer to manually copy disparate scripts and configuration files into specific local paths—a fragile process that breaks as soon as an update is published. Packaging these assets as a plugin allows teams to install and update entire toolchains through package managers and centralized marketplaces with simple version increments.

The trade-off centers on security and trust. Because plugins can execute arbitrary local hook scripts and configure MCP servers with access tokens, installing a third-party plugin carries the same operational risk as running third-party packages from npm or PyPI. Organizations managing plugin ecosystems need clear governance, package review processes, and version pinning to mitigate supply chain risks.

MCP is a running process

The (MCP) is an open standard, and an MCP server is an independent operating system process implementing that specification. These servers run completely out of process: either locally as subprocesses managed by the harness over standard input and output (stdin/stdout), or remotely as standalone HTTP services over Server-Sent Events (SSE) or WebSockets. An MCP server exposes concrete tools the model can invoke, structured resources the harness can read, and prompt templates. The MCP guide explores this protocol in detail.

Unlike skills and plugins, MCP is the only mechanism that expands the model's fundamental capabilities. A skill cannot directly query a production database, and a plugin cannot do so on its own without bundling an active integration. An MCP server connects to live environments because it runs compiled code or scripts equipped with database drivers, network credentials, and socket access.

This expanded capability introduces concrete costs. The schema definitions for every connected server's exposed tools must reside in the context window across every interaction, meaning five connected servers exposing a dozen tools each will quickly establish a substantial baseline token overhead. Furthermore, every server is a long-running process requiring lifecycle management, health monitoring, and dependency maintenance. Remote servers introduce additional authentication complexity, necessitating OAuth handshakes, secure token storage, and fine-grained access policies.

Skills, plugins and MCP servers compared Three columns, one per mechanism, sharing five rows so the comparison reads across. A skill is made of markdown instructions plus optional scripts and reference files; it lives in the context window and launches nothing; it adds no new capability and only redirects abilities the model already has; it costs about 100 tokens each, always, with the body loaded only when it matches; reach for it when the model needs knowledge or a procedure to follow. A plugin is made of a manifest plus skills, slash commands, subagents, hooks and MCP configuration; its parts run wherever they would run anyway, with hooks running on your machine; on its own it adds no capability and simply ships whatever it contains; it costs whatever its contents cost and none of its own; reach for it when a team needs the same set-up, versioned. An MCP server is a program speaking the protocol, exposing tools, resources and prompts; it runs out of process, as a subprocess over stdio or an HTTP service somewhere else; it is the only one of the three that adds a new capability; it costs every tool definition on every call for as long as it stays connected; reach for it when the model needs code, credentials, or a network call. The MCP column is drawn with a heavier border and marked "adds capability" to set it apart. Made of Where it runs Adds a new capability? Costs in context Reach for it when Skill instructions Markdown instructions, plus optional scripts and reference files In the context window. Nothing is launched. No. It redirects abilities the model already has. About 100 tokens each, always. The body loads only when it matches. The model needs knowledge or a procedure to follow. Plugin packaging A manifest, plus skills, slash commands, subagents, hooks and MCP config Wherever its parts run. Hooks run on your machine. No, on its own. It ships whatever it contains. Whatever its contents cost. None of its own. A team needs the same set-up, versioned. MCP server a process, adds capability A program speaking the protocol, exposing tools, resources and prompts Out of process: a subprocess over stdio, or an HTTP service somewhere else. Yes. The only one of the three that adds one. Every tool definition, on every call, while it stays connected. The model needs code, credentials, or a network call. Only the third column gives the model something it could not do before.
Choose the abstraction that fits the requirement: behavioral instructions, distributable packaging, or external runtime capabilities.

Choosing the right abstraction

Deciding which mechanism to adopt depends on what the model needs to accomplish the task:

  • When the model needs domain knowledge or operational procedures, write a skill. Use skills for coding guidelines, architecture runbooks, schema descriptions, and team-specific review criteria. They replace oversized static system prompts and repetitive prompt-pasting.
  • When the model needs external access or runtime actions, implement an MCP server. Use MCP servers when querying internal microservices, executing database commands, or manipulating issue trackers. If the operation requires authentication secrets, network sockets, or execution environments, it belongs in an MCP server.
  • When distributing tools and configuration across a team, package a plugin. Plugins are not an alternative to skills or MCP servers; they are the packaging layer used to deliver both alongside hooks and commands in a single installable unit.
Choosing a mechanism

Ask what the model is missing.

  • The model lacks knowledge or a procedure: write a skill.
  • The model lacks access to a system: use an MCP server.
  • A team needs the same set-up: package it as a plugin.
  • Do not add an MCP server to supply instructions. Use a skill.
  • Do not add a skill to supply access. Use an MCP server.

In mature development environments, teams often converge on a common architecture: dozens of lightweight, inexpensive skills, a small handful of focused MCP servers, and an internally maintained plugin that packages both for the organization.

As organizations scale their tool ecosystems beyond a handful of servers, managing context overhead and authentication becomes its own challenge. See MCP gateways for architectural patterns that manage large-scale server deployments.

Terms introduced

  • Skill: a named set of instructions, packaged as markdown, that a harness loads into the context when it looks relevant.
  • Plugin: a distributable, versioned bundle of skills, slash commands, subagent definitions, hooks, and MCP server configuration.
  • Progressive disclosure: keeping only a name and a description in the context, and loading the body only when it is needed.
  • Slash command: an instruction the user invokes by name, rather than one the model chooses to load.
  • Hook: a script the harness runs when an event fires, with no model involvement in the decision.

How providers do it

All three vendors have converged on SKILL.md for instructions and on a bundle format for distribution. The names of the bundle, and where the files are looked for, are where they part.

ConceptAnthropicOpenAICursor
Skill formatSKILL.md, frontmatter name and descriptionSKILL.md, frontmatter name and descriptionSKILL.md, name must match the folder
Personal skills~/.claude/skills/$HOME/.agents/skills~/.cursor/skills/
Project skills.claude/skills/.agents/skills.cursor/skills/ or .agents/skills/
Standing context costAbout 100 tokens per skillAt most 2% of the context for the whole listNot published
Instruction layer besides skillsSkills onlyAGENTS.mdRules (.mdc), four inclusion modes, plus AGENTS.md
Bundle calledPluginPluginPlugin
Manifest.claude-plugin/plugin.jsonBundle metadata, plus agents/openai.yaml per skill.cursor-plugin/plugin.json
Bundle can holdSkills, commands, agents, hooks, MCP, LSP, monitors, binariesSkills, MCP servers, assets, optional UIRules, skills, agents, commands, hooks, MCP
DistributionMarketplaces, official and community, or a private repositoryFirst-party integrations plus a publish flowCursor Marketplace, team marketplaces, cursor.directory

Most rows are confirmed. Cursor's idle skill cost, OpenAI's config.toml key for MCP servers, and OpenAI's third-party plugin review process are all marked unconfirmed in the tabs below.

Skills travel between these three almost unchanged, so a well-written SKILL.md is portable. Plugins do not travel at all: three manifest formats, three marketplaces, and three sets of component directories.

What this maps to: Anthropic calls skills Agent Skills, and they are the origin of the SKILL.md convention several other vendors now follow. Claude Code adds plugins as the packaging layer, and both sit alongside MCP rather than replacing it.

QuestionAnswerStatus
What is the skill mechanism calledAgent Skillsconfirmed
What is the file formatA directory containing SKILL.md, with YAML frontmatter. name and description are the only required fieldsconfirmed
What are the field limitsname is 64 characters, lowercase letters, numbers and hyphens. description is 1024 characters and must say what the skill does and when to use itconfirmed
How does progressive disclosure workThree levels. Metadata is always loaded, at about 100 tokens per skill. The SKILL.md body loads when triggered, under 5k tokens. Bundled files and scripts cost nothing until read or runconfirmed
Do bundled scripts enter the contextNo. Claude runs them through bash and only the output costs tokensconfirmed
Where do skills live in Claude Code~/.claude/skills/ for personal, .claude/skills/ for a project, or inside a pluginconfirmed
Where do skills live on the APIUploaded through the Skills API at /v1/skills, referenced by skill_id in the container parameter, and requiring the code execution toolconfirmed
Do skills sync between surfacesNo. Claude Code, the API and claude.ai each hold their ownconfirmed
What is the plugin mechanism calledClaude Code plugins, with a manifest at .claude-plugin/plugin.json holding name, description and versionconfirmed
What can a plugin containskills/, commands/, agents/, hooks/hooks.json, .mcp.json, .lsp.json, monitors/, bin/, and a settings.jsonconfirmed
How is a plugin distributedThrough a marketplace. Anthropic runs a curated claude-plugins-official and a reviewed claude-community; teams can host a private one in their own repositoryconfirmed
Are plugin commands namespacedYes, as /plugin-name:skill-name, so two plugins can ship a skill with the same nameconfirmed
What does Anthropic say about trustUse skills only from sources you created or trust. A malicious skill can direct Claude to invoke tools or run code outside its stated purpose. Enterprise organisations can turn on skill content scanningconfirmed

Their vocabulary

Standard termTheir term
SkillAgent Skill, SKILL.md
Slash commandA skill invoked by name, or a file in commands/
HookHook, in hooks/hooks.json
Plugin manifest.claude-plugin/plugin.json
Plugin registryMarketplace

Where to look

/plugin lists what is installed and has an Errors tab that shows a plugin whose MCP or LSP server failed to start. /context shows what is currently occupying the window, including custom agents.

Last verified: 2026-09-09 against platform.claude.com/docs/en/agents-and-tools/agent-skills/overview and code.claude.com/docs/en/plugins.


Check your understanding

0 of 4 answered

  1. Why does installing a hundred skills cost almost nothing until they are used?
  2. A team writes a skill describing how to file a ticket in their internal tracker. The model still cannot file tickets. Why?
  3. A team wants the model to query their read replica for order history. Skill, plugin, or MCP server?
  4. A procedure should run only when a developer explicitly asks for it, never on the model's own judgement. Skill or slash command?