One of the MCP servers my team has open-sourced exposes 29 tools to an AI assistant, and not one of those tools will send an email by itself. Every single send waits for a person to look at a preview and approve it.
That reads like a missing feature. I think it is the most important decision in the whole product, and it is the reason I want to explain MCP servers, skills and plugins together rather than one at a time. The model is the cheap part now. The wiring around the model decides whether AI automation survives contact with a real business, and these three things are that wiring.
So this explanation is written for the person who approves the budget and then lives with the result, not for the developer reading the specification.
Why one job ended up with three names
For a long time an AI assistant could write beautifully about your business and touch absolutely nothing in it. It could draft the email. You still had to copy it, paste it, and send it yourself. Every useful action sat behind a wall of manual steps.
Three different answers grew out of that gap, which is why the vocabulary confuses people.
The first answer was a connection. According to the Model Context Protocol documentation, MCP is an open-source standard for connecting AI applications to external systems, and the site uses a comparison I have quoted in client meetings more than once: think of MCP like a USB-C port for AI applications. One plug shape, many devices. The documentation names three participants. The host is the AI application that coordinates one or more clients, and Claude Code, Claude Desktop and Visual Studio Code are all named as hosts. A client is the component that holds one connection open. The server is the program that provides context to that client.
Underneath, the architecture documentation splits the work into a data layer built on JSON-RPC 2.0 and a transport layer with two options: stdio for a program running on your own machine, and Streamable HTTP for a remote service, where the documentation recommends OAuth for authentication tokens. You do not need to remember any of that to make a good decision. You need to remember that it is a published standard with a version number, currently 2026-07-28, and not a vendor trick.
The second answer was a procedure. A connection lets an assistant act, and says nothing about how your company wants the work done. That is what skills solve.
The third answer was distribution. Once one person has a good procedure, the next problem is getting it to forty people without anyone copying folders by hand.
What is an MCP server, an AI skill and a plugin?
An MCP server is a program that provides tools, resources and prompts to an AI application over a standard protocol, so the assistant can perform real actions. An AI skill is a SKILL.md file of written instructions the assistant loads when the work matches. A plugin is a self-contained directory that packages skills, servers, agents and hooks so a team can install all of it at once.
An MCP server gives the assistant hands
The server side of MCP has exactly three primitives, and the short list is the most useful thing I know about the standard. Tools are executable functions the AI application can invoke to perform actions. Resources are data sources that provide context. Prompts are reusable templates. That is the entire surface. Methods follow an equally boring pattern of list, get and call.
There is one primitive on the other side worth knowing about, because it is where safety lives. Elicitation lets a server ask the user for more information or ask for confirmation of an action. Sampling and logging were deprecated in protocol version 2026-07-28, which tells you the standard is being pruned rather than padded.
Our own example is byline, an MIT-licensed MCP server and CLI that turns an idea into a finished, published article in a chosen voice. It publishes straight into Ghost, WordPress and LinkedIn feed posts, and hands off a folder for Medium, Substack and LinkedIn articles. Its governing rule is one I would put on a wall: nothing fails silently, and every tool returns either a result or an error naming the API and its HTTP status. A tool that quietly swallows a failure is worse than no tool.
A skill gives the assistant a procedure
A skill is a folder with a SKILL.md file in it. YAML frontmatter on top carries a name and a description, then the body is ordinary markdown instructions. The Claude Code skills documentation puts it simply: create the file, and the assistant adds it to its toolkit, using it when relevant or when you invoke it directly by name.
Where the file sits decides who gets it. A personal skill lives under your own home directory. A project skill lives in the repository and, as the documentation says, you commit it to share with your team. There are enterprise managed settings above both. Custom commands have now been merged into skills, so a team that already wrote command files is further along than it thinks.
Here is the line from those docs that changes how you should think about the cost: unlike always-loaded project instructions, a skill body loads only when it is used, so long reference material costs almost nothing until you need it. That single property is why I would rather write a twelve-page checklist as a skill than a tidy paragraph in a config file.
This article went through one of those checklists. Byline ships a write-series skill and a humanizer skill in its repository, and the publishing sequence is not something I remember correctly at ten at night, so the skill remembers it for me: build a brief, write to it, score the draft, generate the images, then schedule. The mechanical scorer then told me my em dash density was too high and that two paragraphs in a row opened with the same word, which is exactly the feedback I never give myself. A written procedure beat my memory, and that is the whole argument for skills in one paragraph.
A plugin gives your team a box
The Claude Code plugins documentation describes plugins as self-contained directories holding skills, agents, hooks, or a .claude-plugin/plugin.json manifest, and recommends them for sharing with teammates, distributing to a community, versioned releases, and reuse across projects. A loose local setup is fine for personal experiments. A plugin is what you reach for when other people depend on the thing.
One plugin can carry skills, commands, agents, a hooks file, an .mcp.json with MCP server configurations, a settings file and executables. Read that list again, because it settles the question I get asked most often: a plugin can contain the configuration for an MCP server, which means the three ideas are layered rather than competing. Public marketplaces exist as well, including one curated by Anthropic and one community marketplace that reviews third-party submissions, and any team can host its own marketplace in a private repository.
Ours is public. The IndiaNIC plugin marketplace currently ships a single plugin, create-design-system, which extracts a full nine-section design system from any public website and generates a four-file DESIGN.md folder with light and dark interactive previews. One plugin, not twenty. I would rather publish one thing a designer uses every week than a catalogue nobody installs.
The three layers, side by side
When I explain this to a founder, I draw three rows. Hands, procedure, box. Most arguments about which technology to adopt dissolve once the rows are on paper, because the honest answer is usually that you need a different row than the one you were asking about.
Notice that the examples in the last column are all small. None of them tries to be a platform.
A connection without a procedure produces confident nonsense at speed. A procedure without a connection produces advice nobody acts on.
How the three fit together on one ordinary task
Take the task of publishing this series. Ten articles, one voice, one blog, and a schedule that must not slip.
The MCP server does everything that touches the outside world. It reads the persona file, builds the brief, grades the draft mechanically, generates and uploads the images, and schedules the post against the blog's own clock. A persona in byline carries writing style, tone, sentence rhythm, risk tolerance and constraints, plus a ledger that stops a series from repeating the same article shape ten times. The scorer is deliberately unglamorous. It counts em dashes, participle riders after a comma, stacked hedges, repeated sentence openers, decorative bold and headings echoed by their own first line, and only three of its checks can block a publish at all.
The skill decides the order of operations and the house rules. The plugin would be how I hand all of it to a marketing team who should never have to read a tool schema.
Now the uncomfortable part, and here I will disagree with most of the advice being published right now. I think teams reach for an MCP server far too early. Writing a server is the expensive path, and a large share of what people want from AI automation is a procedure problem rather than a capability problem. If your assistant already has the access it needs and the output is simply wrong or inconsistent, a server will not save you. Write the skill. Live with it for two weeks. Build the server only when the thing you need genuinely cannot be done from the tools already on the table.
My own estimate, from using byline most weeks rather than from any measurement, is that the whole loop saves me somewhere between two and four hours per article compared with writing, scoring and scheduling by hand. I offer that as an estimate and nothing stronger. We have not instrumented it, and I would not want anybody to put my number in a business case as though it were measured.
| Approval is a design decision, not a setting. Design the human confirmation step into the server itself rather than hoping a prompt will hold the line, which is why our messaging tools use a draft, preview and confirm sequence and publish no raw send tool at all. A tool that cannot act without approval is safe even when the model is wrong. |
That pattern shows up across everything we have published. MailMan exposes 29 tools for Gmail and nothing leaves the outbox until you approve it, with campaigns refusing to draft when recipients lack the required name placeholders, a rate limit near 20 messages per minute, and an abort once about 25% of a campaign's sends fail. WhatsAppMan is send-only by design across its 12 tools, caps bulk sends at 100 recipients, and trips a circuit breaker after three consecutive failures. When the work moves from one laptop to a shared box, our self-hosted control room for remote AI sessions is the piece that handles access without opening a single inbound port.
Where would I start this week?
Start with the dullest task on your team's list that already has a written procedure somewhere, even if that somewhere is a colleague's head. Write it as a skill, commit it to the repository, and see whether the assistant follows it for a week. Cost of being wrong: one markdown file.
If the blocker turns out to be access rather than instructions, install an existing MCP server before writing one. The reference server collection at the Model Context Protocol organisation on GitHub covers a surprising amount of ordinary work, and the standard is supported by Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam, so nothing you learn is locked to one vendor.
Package it as a plugin only when a second team asks for it. That is the signal. Until then a plugin is overhead with a manifest.
The next question worth putting to your team is narrower and more useful than any of this: which single task would we trust an assistant to finish end to end, and what confirmation step would make us comfortable watching it happen? Answer that honestly, and the three layers stop being vocabulary and start being an architecture. Our tools are MIT-licensed and public, so take them apart before you build your own.
Frequently asked questions
Do I need an MCP server, a skill or a plugin first?
Start with a skill. A skill is a single SKILL.md file of instructions, it costs one markdown file to try, and the Claude Code documentation notes its body loads only when used. Add an MCP server when the assistant genuinely lacks access to a system. Package a plugin once a second team wants the same setup.
What is the difference between an MCP server and a plugin?
An MCP server is a running program that provides tools, resources and prompts to an AI application over JSON-RPC 2.0. A plugin is a distribution package: a directory with a plugin.json manifest that can bundle skills, commands, agents, hooks and an .mcp.json file, which means a plugin can carry the configuration for an MCP server inside it.
Is MCP tied to one AI company?
No. The Model Context Protocol documentation describes MCP as an open-source standard with a published protocol version, currently 2026-07-28, and names Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam among supported clients. The documentation is explicit that MCP covers context exchange only and does not dictate how an application uses its model.
