The first time my team wanted our assistant to follow our own publishing checklist, we opened an editor and started sketching an MCP server. That is how most people meet the skills vs plugins vs MCP question, and it is the wrong end of it to pick up.
Nobody objected. A server felt like the serious answer, and we had already written a few of them. Then one of us read the design back out loud. It had no API to call, no credential to hold, and no outside system to reach. Its entire job was to repeat our own checklist to the model.
What we needed was a text file. The checklist became a SKILL.md, it loaded when the assistant reached for it, and the server quietly stopped existing. That was the realisation which still governs these decisions for us. The three layers are not three sizes of the same thing.
Why do teams reach for an MCP server first?
A server is the layer almost everybody has heard of, so it becomes the default answer even for jobs that need no server at all. According to the Model Context Protocol documentation, MCP is an open-source standard for connecting AI applications to external systems, and the site compares it to a USB-C port for AI applications. The framing is accurate. It also quietly suggests that every new capability needs a port.
Most new capabilities do not. An MCP server, in the protocol's own words, is a program that provides context to MCP clients. It runs as a process, it holds the credentials, it exposes the tools the model is allowed to call, and somebody on your team owns keeping it alive. For the business version of that picture rather than the developer one, I wrote a plain-English guide to MCP servers earlier in this series.
A skill carries none of that machinery. The Claude Code skills documentation puts it plainly: create a SKILL.md file with instructions, and Claude adds it to its toolkit. One file. Frontmatter with a name and a description, markdown underneath, living in ~/.claude/skills/ for yourself or .claude/skills/ for the repository.
The running cost is where the two layers separate hardest. That same documentation notes that a skill's body loads only when it is used, so long reference material costs almost nothing until the moment you need it. Meanwhile the protocol keeps moving underneath the server layer. The documented version in 2026 is 2026-07-28, and Sampling and Logging are both deprecated in it, which is the sort of detail that turns into maintenance work for whoever owns your server.
Where the usual advice about skills, plugins and MCP breaks down
Three slogans do most of the explaining online. Skills for prompts, plugins for teams, servers for integrations. The wider map of how the three connect is in my guide to how MCP servers, AI skills and plugins actually work together, so what I want to do here is narrower: show the two places that tidy version fails, because I have watched both happen.
The first is enforcement. A skill is used when relevant, which means the model decides. Advice the model may or may not reach for is not a control. If a rule has to hold every single time, a markdown file is the wrong home for it, and no amount of capital letters in that file changes the answer.
The second is packaging too early. The Claude Code plugins documentation is refreshingly blunt about which option wins where. Standalone .claude/ is best for personal workflows, project-specific customisations and quick experiments. Plugins are best for sharing with teammates, distributing to the community, versioned releases and reuse across projects. Plenty of teams skip the first column entirely and open a manifest on day one.
For a long time I treated this as a tooling problem. I was wrong, and I will say so plainly: it is a sequencing problem. The popular instinct to design the plugin first, so that it is ready to share, produces versioned releases of workflows nobody has used even once.
There is one wrinkle worth knowing before you audit your own setup. The skills documentation states that custom commands have been merged into skills, so a .claude/commands/deploy.md and a skill both produce /deploy. If you are carrying old command files around, you are already running skills and may not have noticed.
A three-question test for skills vs plugins vs MCP servers
Ask these in order and stop at the first yes.
- Does the assistant already have every ability this job needs, and lack only the procedure? Write a skill.
- Does the job require touching a system outside the assistant, such as a mailbox, a CMS, a database or a device? Build an MCP server.
- Is somebody other than you going to install this, on a machine you do not control? Package it as a plugin.
The order matters because the answers stack rather than compete. A plugin is the box the other two travel in, which is why the third question is about people and not about technology at all.
| The expensive mistake. A skill cannot enforce anything, because the model chooses when to load it. If a rule must hold on every run, put it in code inside an MCP server or in a plugin hook, never in a markdown file. |
Should I start with a standalone skill or a plugin?
Begin inside your own .claude/ directory every time. The Claude Code plugins documentation reserves plugins for sharing with teammates, distributing to the community, versioned releases and reuse across projects, and recommends plain .claude/ for personal workflows and quick experiments. Convert when a second person asks for your workflow. Test the converted directory locally with claude --plugin-dir ./my-plugin, and check it with claude plugin validate before anyone installs it.
How we use all three layers at IndiaNIC
Our own split is the most useful example I can offer, because every piece of it is public and MIT licensed, so you can disagree with my reasoning by reading the code.
mailman is an MCP server for the simplest possible reason: Gmail is a system the assistant cannot otherwise touch. It exposes 29 tools, among them draft_email, confirm_send, search_messages and schedule_send, and nothing leaves your outbox until you approve it. It throttles at roughly 20 messages per minute and aborts a campaign at about a 25% failure rate.
whatsappman makes the point by what it leaves out. There is no raw send tool. We left out the obvious function on purpose, so an assistant can never send an unpreviewed message, and all 12 tools run through draft, preview and confirm. It links your own machine as a WhatsApp Web device through the Baileys library, which is not the official Cloud or Business API, and it caps bulk sends at 100 recipients with a circuit breaker that trips after three consecutive failures.
That missing tool is the decision I would defend hardest, and it explains the whole framework. We could have written a careful instruction saying never send without approval. Instructions get skipped. A tool that does not exist cannot be called.
byline lives in the same layer, publishing finished articles to Ghost and WordPress as both an MCP server and a CLI. Its score_draft tool grades a draft mechanically, with three blocking checks on platform HTML, structure and the summary block, plus advisory ones for habits like em dash density and stacked hedges. Those checks sit in code for the same reason whatsappman has no send tool.
The plugin layer is deliberately thin. claude-plugins is our marketplace and it carries one plugin today, create-design-system, which extracts a nine-section design system from any public website and generates a four-file DESIGN.md folder with light and dark interactive previews. Two lines install it. We packaged that one because people outside our own team kept asking for the workflow, and when we put this tooling under MIT, an easier call to sign off when you run the company, the test we applied was whether a stranger could install it with nobody from IndiaNIC in the room.
The skill layer is the part we do not open-source, and that is exactly right. Which persona byline writes as, which checks must pass before a post is scheduled, how a draft gets handed to a reviewer: those are instructions, and instructions belong in a SKILL.md inside the repository that needs them, where a colleague reviews them as a diff. My estimate, from daily use rather than any measurement, is that moving a repeated instruction out of a pasted paragraph and into a skill saves minutes per use rather than hours. Consistency is the real return, not speed.
A skill changes how the assistant works. The server layer changes what it can reach. Packaging changes who else gets either one.
Frequently asked questions
What is the difference between a skill and an MCP server?
A skill is a SKILL.md file of instructions that the assistant loads when relevant, so it changes how the assistant works. An MCP server is a running program exposing tools, resources and prompts over the Model Context Protocol, so it changes what the assistant can reach.
Can one plugin include an MCP server?
Yes. The Claude Code plugins documentation says a plugin directory can bundle skills, commands, agents, hooks.json, a .mcp.json holding MCP server configurations, .lsp.json, monitors, bin and settings.json. Shipping a server together with the skills explaining how to use it turns several setup steps into one install for a teammate.
Do I need a plugin to share a skill with my team?
No. The skills documentation says a project skill at .claude/skills/name/SKILL.md can simply be committed to share with your team. A plugin earns its place when distribution goes wider than one repository, because that is where namespaced invocation, versioned releases and a marketplace start to matter.
Pick the layer by what is actually missing, and most of these arguments dissolve. Before tomorrow ends, open the last week of your assistant history and find one instruction you typed more than once. Put it in ~/.claude/skills/ as a SKILL.md with a name and a description, and use it tomorrow morning. Write no manifest. Build no server. If that file is still earning its keep next week and a colleague asks you for it, that is the day to package it, and not one day earlier.
