Agent skills vs plugins vs MCP vs kits
Skills teach a technique, plugins package it for a client, MCP connects your systems, and kits are workers that run without you. Where each boundary sits.
Four words get used as if they were rivals: skill, plugin, MCP, kit. They are not rivals. They sit at four layers of the same stack, and most of the confusion comes from comparing a file format to a product.
Here is the whole answer in one table, then the reasoning.
| What it is | Who drives it | Own credentials | Starts itself | |
|---|---|---|---|---|
| Agent Skill | Instructions that teach a technique | You | No | No |
| AI plugin | A bundle installed into a client | You | No | No |
| MCP | A protocol for reaching systems | Whatever calls it | No | No |
| Kit | A configured worker for one job | Nobody | Yes | Yes |
The last two columns are the story. Three of these extend a session a person is sitting in. One does a job while nobody is watching.
Skills teach a technique
A skill is a folder with a SKILL.md at its root: YAML frontmatter carrying a name and a description, then markdown instructions. Those two fields are the only required ones.
The clever part is not the format, it is the loading model. Agents read skills by progressive disclosure, in three stages:
- At startup, only each skill's name and description are loaded. A hundred skills cost a line of text each.
- When a task matches a description, the full
SKILL.mdis read into context. - Referenced files and bundled scripts load only if the work needs them.
That is what lets a skill library grow without drowning the context window, and it is why "put it all in the system prompt" is not the same thing.
What a skill gives you is consistency. "How we write release notes" stops being re-explained every session. What it does not give you is autonomy: no credentials, no schedule, no way to start. Close the session and nothing happens.
Plugins package and distribute
A plugin is a container. In Claude Code one plugin can bundle skills and slash commands, subagents, hooks, and MCP server configuration, and install all of it in one step.
The sentence worth keeping: **plugins are a distribution format, not a capability.** A plugin does nothing a skill or an MCP server could not do. It solves packaging, versioning and installation, which matters enormously once other people use your work and not at all while it is just you.
So "should I write a skill or a plugin?" is usually the wrong question. Write the skill. Reach for a plugin when several pieces travel together, or when you need to hand them to someone else.
MCP is the wiring
MCP answers one question: how does a model reach something outside its context?
Before a common protocol, every client-to-tool pairing needed bespoke glue. Five clients and twenty tools meant a hundred integrations. MCP makes that a standard interface: expose a server once, and any client that speaks the protocol can use it.
MCP connects. It deliberately does not decide and does not restrain. The protocol has no opinion about which of a server's twelve tools a given agent may call, which contacts it may email, or whether a draft may be sent rather than saved. That is policy, and policy lives above the protocol. It also has no schedule: a server sits there until something calls it.
Kits are the job, done
Notice what all three share: something else has to be driving. The value arrives when you show up.
A worker kit is the other thing. It is a ready-made AI worker packaged with everything one job needs: the instruction, the app permissions per level, the memories, the schedule or trigger, and per-model grades marked measured or declared.
Taking a kit mints a worker in your account, with its own key and only the access you granted. It then works whether or not you open anything.
The same job, four ways
Take one concrete task: make sure pull requests needing review do not rot.
| Approach | What you get | What it needs |
|---|---|---|
| Skill | The agent reviews in your house style when asked | You, opening the editor |
| Plugin | That skill plus a GitHub MCP server, installed for the team | Each teammate, opening the editor |
| MCP alone | The agent can reach GitHub | Something to tell it what to do |
| Kit | Engineering Pulse delivers a morning digest of PRs needing review, stale branches and failing workflows | A GitHub connection |
The first three improve the review you write. The fourth makes sure you knew there was one waiting. That is not a better version of the same thing, it is a different thing.
Three more pairings of the same shape:
| A skill could teach | A kit that does the unattended half |
|---|---|
| How to write a follow-up in your voice | Follow-Up Tracker tracks every thread you are waiting on and drafts the nudge |
| How to qualify a lead against your ICP | Inbound Lead Qualifier qualifies leads on arrival, files them in the CRM and drafts the reply |
| How to summarise a meeting properly | Meeting Action Item Collector reads your notes each evening and files every action item |
The pattern: the skill is about quality, the kit is about **it happening at all**.
What changes the moment nobody is driving
Three problems appear that do not exist for a skill or a plugin, and they are most of the engineering.
It needs somewhere to run. A worker that only runs while your laptop is open is a script with extra steps. A hosted runtime executes the run so a schedule fires with no machine of yours left on. That means holding credentials, enforcing caps, recovering from a provider outage, and writing a record. Running a worker on your own infrastructure is coming later.
It needs to be restrainable. An agent acting in a real inbox at 3am cannot be governed by a politely worded instruction. The distinction that matters:
| An instruction | A control | |
|---|---|---|
| Where it lives | In the prompt | In the platform |
| Enforced by | The model's judgement | Code the model cannot reach |
| Under pressure | Can be argued past | Cannot |
| Example | "Never email the exec team" | Contact rules refuse the recipient |
WorkerKit's safety layer is three composing controls: the app firewall granting Off, Read or Write per app, contact rules filtering reads and refusing blocked recipients, and redaction stripping values outside the model's reach. All three ship on every plan including Free, because the controls that make autonomy safe cannot be the paid tier.
It needs to be inspectable. Every run leaves a receipt: what it read, what it did, what it cost, what it skipped and why. A skipped run is recorded rather than swallowed, which is the difference between a system you can leave running and one you quietly stop trusting.
What about the model?
A kit brings the instructions, not the model. Claude, ChatGPT, Gemini and Grok all drive the same kits, you pick at deploy time, and you can send a single run to a different model to compare them on the same job with the same inputs.
That is only credible because of how tokens are billed: at the **provider list price with no markup**, from a prepaid wallet or your own key. A platform taking a cut of tokens earns more when you pick the bigger model, and "switch any time" would be in tension with its own revenue. With no markup there is nothing to steer.
The reasonable objection
"This is a category invented to make a product sound novel. A skill, plus a cron job, plus an MCP server, plus a scoped token is a kit. You have bundled four existing things and named the bundle."
That is the strongest version of the argument and it is substantially correct about the components. Nothing here is a new primitive, and anyone saying otherwise is overselling.
Where it stops being correct is in treating assembly as the trivial part. The four pieces do not compose into an unattended worker by themselves; you have to add the properties none of them carry:
| You still have to build | Because |
|---|---|
| An identity per job | A shared token means one job's mistake reaches every job's data |
| Revocable per-app levels | A scope granted at token-creation time is all-or-nothing later |
| Graceful degradation | Otherwise a revoked permission is a crash, so nobody revokes anything |
| A record per run | "What did it do at 3am" needs an answer that is not a log grep |
| Budget reserved before running | Or a run dies halfway through a mailbox |
| Hard caps | Or a loop is an invoice you find at month end |
That list is the actual product, and it is a fair fight to say you could build it. Plenty of teams should: if you already run infrastructure, have somewhere to put secrets, and have people who carry a pager, assembling this yourself is a legitimate call and you will get something better fitted than any platform.
The honest framing is that "kit" names a **package with those properties already**, not a new idea. The category claim is about what you have to operate, not about having invented something.
When a kit is the wrong tool
Worth saying plainly, because a page that only sells is not trusted.
- The job is not repeatable. One-off research does not need a schedule, a key or a receipt. Open an assistant.
- The judgement cannot be written down. If you cannot express the job as an instruction that holds on the four hundredth run, it is not ready to be unattended.
- You need it on your own hardware today. WorkerKit hosts every run; own infrastructure is coming later.
- The task is genuinely interactive. Pair programming is not a job to hand off, it is a conversation.
Use all four
They compose:
- MCP to connect your systems.
- Skills to encode how your team does things.
- Plugins to distribute those skills.
- Kits for the jobs that should happen whether or not anyone opens an editor.
The dividing line is whether a human is in the loop. If the value shows up when you sit down, you want the first three. If it should show up at 7am on a Tuesday while you are asleep, you want the fourth.
FAQ
What is the difference between a skill and a worker kit?
A skill is markdown instructions that teach an agent a technique, loaded while you are driving that agent. It has no credentials, no schedule and no way to start itself. A worker kit mints a worker in your own account with its own key, per-app permissions, memories and a schedule, and that worker runs unattended and leaves a receipt for every run.
Are plugins and kits competing formats?
No. A plugin installs capability into an AI client that a person uses, solving packaging and distribution. A kit installs a configured worker into your account that runs on its own. A team can reasonably use plugins in their editors and kits for the jobs that must happen overnight.
Does MCP replace the need for kits?
No. MCP is the protocol for reaching a system; it has no permission model deciding which agent may call which tool, no contact policy, and no schedule. A kit uses connections like these to do its job, and adds the instruction, the access levels and the trigger on top.
Do I need to write skills or prompts to use WorkerKit?
No. A kit ships with its instruction, app permissions and schedule already written and tested by its publisher, so there is no prompt engineering and no glue code. You connect the accounts it asks for and run it, in about a minute.
Can I build and publish my own kit?
Yes. The Kit Creator Studio is a no-code builder: describe the job, pin the apps and the access each gets, write the instruction, validate and publish. A published kit gets a permanent address for life, and kits can also stay private on every plan including Free.
Which is cheaper, a skill or a kit?
They are metered differently. A skill costs whatever your client charges for tokens in your session. A WorkerKit worker costs your plan (Free is $0 with 5 workers and 500 tool calls a day) plus model tokens at provider list price with no markup. See /pricing.