Tools — three shapes, one purpose

What you will learn What a tool is, why it arrives under three names — skill, plugin, MCP — why that distinction is not the user's problem, and the three real differences you do have to know anyway.

A tool is "something it can do"

You saw the structure in Tool use. A model only produces text, but hand it a list of actions it can call and it picks one and calls it.

That is all a tool is. An action with a name and a description attached, so the model can call it. Nothing more.

But there are three names

Go to add one and you meet three words. All three amount to "give the work more things it can do"; the packaging differs.

graph TD
  A["I want the work to be<br/>able to do more"] --> B["Skill<br/>write down the procedure"]
  A --> C["Plugin<br/>install a bundle"]
  A --> D["MCP server<br/>attach an outside program"]
  B --> E["Result: more callable actions"]
  C --> E
  D --> E

The distinction belongs to whoever built it

This is the point of the chapter. Which of the three something is was decided by its author; it is not a question the user should have to answer.

One thing carries three names at once. So "which kind was the one I'm looking for?" is usually a question with no answer.

Kind should be a badge, not a page.

The HyperTeams "Tools" screen works that way. It used to be three tabs — skills, plugins, MCP — and they were folded into one, because the user is trying to do one thing ("what should I let this work do?"), and standing tabs in front of that only adds a question they have to answer first.

Plenty of mature tools reached the same answer in the same place.

Which is why this part does not open with MCP. MCP is one of the three shapes, and it gets its own chapters further down.

But the handling is not the same

You can ignore the packaging right up until you touch it. Then the three differ. These are worth memorising.

Each row burns you once.

• "Cannot be turned off" and "is turned off" are different. A skill has no temporary off switch. Not wanting it means deleting it.
• Deleting a plugin removes it from the machine, not the folder. You just took away something other work was using.
• Not everything you can see is yours to delete. Only what was put into this folder; rows that came from the machine-wide install or from policy cannot be touched here.

Questions to ask of any one tool

The third is the easy one to skip. Folder-level is cheap to undo; machine-level is expensive. If you are only trying something out, start on the folder side.

Where you actually touch this

Check

1. Why not split skills, plugins, and MCP into tabs by kind?

2. Which of the three can be toggled off? What do you do with the others?

3. What is the particular hazard when deleting a plugin?

Whatever the shape, adding them leads to the same problem → When you have too many tools