# MCP, skills and plugins: how are they different?

Author: Rajat
Published: 2026-09-23
Canonical URL: https://www.thebuildercourse.com/blog/mcp-skills-plugins
Publisher: The Builder Course

A shopping example to explain what MCP, skills, and plugins add to an agent, and when you might need them.

The questions that prompted this article came from a student: what is MCP, what is a skill, and what is a plugin? They wanted to know whether these were different things or different names for the same thing.

I find the distinction easier to explain through a job we already understand. If I ask someone to buy milk, they need my preferences and a way to find out what the shop has. An AI assistant needs those too. The example below lets you give it each piece separately.

## Can it choose my milk yet?

Give it one piece, then the other. Watch what it can answer. You can remove them too.

An interactive illustration with sample data and written responses. No account is connected and no AI model is running.

### Try the shopping task

Help me choose milk for breakfast.

My saved preferences: I want one litre of oat milk. Ask me before choosing something else.

The shop’s sample stock: Oat milk, 1 L: available. Dairy milk, 1 L: available.

This illustration uses a saved skill for the preferences and an already authorised MCP connection for the stock lookup. Nothing is bought.

### It needs a little more to go on.

What kind of milk do you want? And what does the shop have?

Try giving it your preferences, or letting it check the shop. You can start with either.

### It knows what I like.

You want one litre of oat milk. I still need to find out whether the shop has it.

The notes tell it how to choose. They do not tell it what is on the shelf today.

### It can see what is available.

The shop has oat milk and dairy milk in one-litre cartons. Which would you prefer?

It has the stock information, but I have not given it my preferences.

### It can put the two together.

The shop has one litre of oat milk. That matches your preferences, so I would suggest that.

Try removing either piece. Knowing what I like and checking what is available solve different problems.

## Now we can put names to those pieces.

In this example, the **skill** contains my instructions for choosing milk and deciding when to ask me. I can reuse those instructions the next time I shop. A more involved skill can also include reference files or small programs. [About skills](https://agentskills.io/home)

The shop connection in this example uses **MCP**. It is a shared way for an AI app to talk to other software. Through that connection, the assistant can check what the shop has. It still needs permission to access the shop. Other ways of connecting exist too; MCP is one common approach. [About MCP](https://modelcontextprotocol.io/docs/learn/architecture)

When someone says ‘add an MCP’, they usually mean connecting to a service that uses MCP. MCP names the communication standard. The connection in our example lets the assistant check stock.

## What if I install those pieces together?

Suppose I want to share this setup with you. I could put the shopping instructions and the connection setup into one package you can install. In Codex, that package can be a **plugin**. Open this one and look for the two pieces you just used.

An interactive illustration with sample data and written responses. No account is connected and no AI model is running.

### Breakfast helper

Skill: my saved shopping preferences. I want one litre of oat milk. Ask me before choosing something else.

MCP connection setup: lets the app connect to the example shop to check stock, once access is authorised.

This plugin packages the saved shopping instructions and the setup for an MCP connection. They still do the same two jobs.

### Shopping preferences

Skill: my saved shopping preferences. I want one litre of oat milk. Ask me before choosing something else.

This is also a possible plugin: it contains the shopping skill, without a shop connection. You could give it a stock list yourself.

### Shop connection

MCP connection setup: lets the app connect to the example shop to check stock, once access is authorised.

This plugin contains the setup for an MCP connection, without shopping instructions. You could tell the assistant what you want in the chat.

One installation can give you a plugin containing both a skill and an MCP connection. That overlap can make the names confusing: the plugin is the package, while the skill and connection are its contents.

A plugin can contain just a skill, just a connection, or other supported additions. The word means an add-on for a particular app, much like a browser extension. The contents tell me what it can do. [Codex plugins](https://developers.openai.com/plugins/concepts/plugins)

## They answer different questions.

| The question | In our shopping example |
| --- | --- |
| How should it do this job? | The skill supplies my saved shopping instructions. |
| How can it check the shop? | The connection uses MCP to let the app ask for stock information. |
| What am I installing? | The plugin packages one or both of those pieces. |

A skill and an MCP connection do different jobs. A plugin can package them together, so a single setup may use all three.

## Use the pieces your task needs.

If I paste in a shopping list and want it organised my usual way, a skill could help without connecting to a shop. If I only want to check whether oat milk is available, a connection and a plain request may be enough. A plugin is useful when I want a convenient way to install or share a setup.

The same idea works for email. My reply-writing instructions could be a skill. A connection for reading Gmail could use MCP. A plugin might package those together. If I paste the email into the chat myself, the writing skill can work with that instead.

The meaning of ‘plugin’ depends on the app. Codex and Claude Code have their own packaging rules; DeepSeek Harness uses the word more broadly. I have kept that comparison in [the plugin article](https://www.thebuildercourse.com/blog/what-is-an-agent-plugin), so we can look at it separately.

## Why use MCP if I can write my own tool?

Suppose I am building a restaurant assistant. I write a small function called `check_menu` that reads the restaurant’s dishes, allowed changes and current stock. I describe it to the agent so it can request that action. That is my **custom tool**: code I built for a particular job.

I now have a separate choice: how should my app reach that code? I can wire the function straight into my app, or expose it through MCP. Follow the arrows below. The kitchen and the work my code does stay the same.

An interactive illustration with sample data and written responses. No account is connected and no AI model is running.

### Call my tool directly

I register the tool in my app and write the code that runs when the agent requests it. That code talks to the kitchen’s system. I can build this without MCP.

My restaurant app: Makes the check_menu tool available to its agent. → App calls my function → My custom tool: Code I write to read the kitchen’s menu and stock. → Kitchen data.

For another agent app to use this directly, it needs its own integration with my function or service.

Both examples return the same menu and stock. A custom tool can also be an MCP tool: custom describes who built it; MCP describes how it is exposed.

### Expose my tool through MCP

I expose my tool from an MCP server, a program that accepts MCP requests. Its code still has to read the kitchen’s system. MCP supplies the communication rules; it does not write the restaurant integration for me.

My restaurant app: Uses an MCP client to discover and call check_menu. → App sends an MCP request → My MCP server: Offers the same custom tool through a standard interface. → Kitchen data.

Another compatible agent app can connect to this server too, with the right setup and permission. It uses the shared MCP interface.

Both examples return the same menu and stock. A custom tool can also be an MCP tool: custom describes who built it; MCP describes how it is exposed.

So ‘custom tool’ and ‘MCP tool’ can describe the very same thing. **Custom tells me who built it. MCP tells me how an app can discover and call it.** Someone still implements the tool, whether that is me, the restaurant’s software provider, or another developer. [How MCP exposes tools](https://modelcontextprotocol.io/docs/learn/server-concepts)

| If this is my situation… | I would consider… |
| --- | --- |
| One product, and I already control its connection to the kitchen | A direct tool. I can register my function in the app without adding an MCP server. |
| Several compatible agent apps need the kitchen tools | An MCP server, so those apps can use a shared interface. Each still needs setup and permission. |
| A maintained MCP server already offers exactly what I need | Trying that integration before writing another one. I still check its actions, access, reliability and fit. |

MCP adds an interface to build or configure and maintain. Direct tools also need maintenance. I would choose based on the apps I need to support and the integrations I already have; neither route automatically makes the restaurant logic more reliable.

## Which pieces would a restaurant assistant need?

Here is the product I want: a customer asks for pasta, the assistant checks whether their changes are allowed, checks availability, then asks them to confirm the price before sending the order. A request for chicken should get a question back because this restaurant does not offer it.

Before agents, I might have built this as an order form with a menu lookup and a Submit button. Those jobs still exist. The agent lets the customer ask in their own words; the software still needs to check and record a valid order.

Try changing the customer’s order or the kitchen’s stock below. Then disconnect the kitchen. Notice which checks can still happen using the supplied menu, and which need a working tool.

An interactive illustration with sample data and written responses. No account is connected and no AI model is running.

### Build a restaurant order

Fictional menu: mushroom pasta $12; extra mushrooms $2; chicken add-on unavailable. Prices are sample dollars.

Check the dish and requested changes.

Check current availability with the kitchen.

Show the price and ask the customer to confirm.

The same procedure can be supplied by the app or loaded from a skill. Switching where it lives does not change the order rules.

### Mushroom pasta

One mushroom pasta, please.

That is $12. Shall I send this order to the kitchen?

### Pasta + extra mushrooms

One mushroom pasta with extra mushrooms.

That is $14. Shall I send this order to the kitchen?

### Pasta + chicken

One mushroom pasta, and add chicken.

We do not offer a chicken add-on. Would you like the mushroom pasta as listed?

### Disconnect the kitchen

That is on the menu, but I cannot check the kitchen right now. I have not sent an order.

The supplied menu still helps check allowed changes, but cannot confirm current availability.

### Mark pasta sold out

Mushroom pasta is sold out. Would you like to choose another dish?

### Confirm a valid sample order

Confirmation sends the fictional order to the simulated kitchen, which checks the item, change, availability and price again. The ticket then reads Accepted by the sample kitchen. Changes to any input start a fresh draft. No real order is placed.

The ordering procedure can live in my app’s instructions, or in a skill that my product’s agent loads. Switch between those above: the rules stay the same. A skill gives me a reusable place to keep the procedure; it does not add a kitchen connection.

The tools do the outside work: one looks up the kitchen’s current data, another submits the confirmed order. I can supply them directly or through MCP, as in the diagram. The order system must check allowed items, changes, availability and price again when it accepts an order. A skill saying ‘check the price’ cannot enforce that on its own.

For an early prototype, I can paste a menu into the conversation and test sample requests with no skill, MCP or plugin. For this working product, I need instructions and tools. Whether I save those instructions as a skill and expose those tools through MCP are separate decisions.

Where does the plugin fit? If I want someone to install this procedure and connection in a compatible app, I might package them as a plugin. Building my own restaurant website does not automatically mean I need one.

## The questions that come up when I start building.

These questions came up in a course discussion. Open whichever is closest to what you are wondering.

### Are skills just for my own workflow, or can my product use them?

Both are possible. A skill in my coding assistant can help me build the restaurant app. Installing it there does not automatically give the finished app that skill.

For customers to benefit from it, the agent running inside my product must be able to find and load the skill, with its supporting files and tools available. If my app does not support skills, I can still put the procedure into the instructions it supplies to the model. [Adding skills support to an agent](https://agentskills.io/client-implementation/adding-skills-support)

### How do I know I have added enough tools?

For the restaurant, I want to check an ordinary order, an unavailable dish, an unsupported change, and a failed kitchen connection. Writing down the expected responses first gives me a way to judge whether the product can do its job.

A failed test helps locate the gap. If the agent cannot check stock, a lookup tool may be missing. If it checks stock but ignores the result, I need to inspect its instructions and how the app uses that result before adding another tool.

### Should I use an existing MCP server or build my own connection?

I would look for a maintained integration that supports the exact actions I need, then try it on a small example. Can it read the current menu? Can it submit an order? Who runs it, what access does it need, and what happens when it fails? An MCP label does not answer those questions.

If it fits my app, reusing it can save work. If my app already talks directly to the restaurant’s system, I may keep that route. MCP becomes useful when a shared interface helps compatible agents use the same capabilities. [Follow the different connection routes](https://www.thebuildercourse.com/blog/how-mcp-works)

### If MCP gives me the tools, why would I make a plugin?

An MCP connection may be enough for access. A plugin is useful when I want people using a particular app to install a setup conveniently, perhaps including a skill that explains how to use those tools. It can also package just the connection.

Adding scripts or reference files to a skill does not automatically make it a plugin. The app has its own rules for an installable plugin package. [Open a plugin and compare apps](https://www.thebuildercourse.com/blog/what-is-an-agent-plugin)

### How do I spot what needs checking before I build?

I start with the customer’s path: ask for a dish, check the menu, confirm the order, and send it to the kitchen. Each step needs an explanation of how the software will carry it out.

That exposes assumptions. For example, I may not know whether the kitchen system accepts orders from another app. A small test of that connection can answer the question before I spend time polishing the conversation.

Before adding a component, I want to be able to name the problem it solves in my product. The restaurant examples give me specific cases to check: missing stock information, instructions the agent did not follow, or a setup I need to share.

Tool details checked against linked documentation on 23 September 2026. Product conventions can change; check the source for your application.

## Read next

- [Agent skills: saving a repeatable way of working](https://www.thebuildercourse.com/blog/what-is-an-agent-skill): See how everyday judgment becomes a saved procedure.
- [Your repo is your AI’s memory. Give it a decent one.](https://www.thebuildercourse.com/blog/repo-readiness): Put the wider context for your agent into a project folder.