A skill is written know-how an AI loads when a task calls for it, a tool is a function it can ask software to run, and a connector such as MCP is how that software reaches your apps.
- Skills give a model habits. A skill is a folder of instructions, reference files and sometimes scripts, so the agent can follow the same method each time the task comes up.
- Tools are requests, not actions. The model asks for a function to be run, the surrounding software runs it, and the result comes back for the model to read.
- MCP is a shared socket. An app exposes an MCP server, and any compatible assistant can plug in and use its tools.
- Loading a skill is just reading. Its instructions are placed in the model's context, so a skill is only as good as its writing.
- The main risk is prompt injection. A model cannot fully tell instructions from content, so sensible setups sandbox tools, ask a human before consequential actions and vet third-party skills.
Agents now come with "skills," assistants "use tools," and everything "connects." Here is what those words mechanically mean — no magic, mostly folders and permission slips.
1 · The problem skills solve
Models are brilliant improvisers with no habits. Ask twice, get two methods. For real work you want the same good method every time — your company's document format, the correct steps for a deploy, the house style. A skill is that method written down and packaged: a folder containing instructions (typically a structured document the model reads), reference files, and sometimes executable scripts. When the task matches, the agent loads the skill and follows it. Think: laminated recipe cards for a chef with infinite talent and no memory.
2 · Tools: the hands
A tool is a function the model is allowed to call — search the web, query a database, send an email, run code. The model does not "do" these things; it emits a structured request ("call search with query X"), the surrounding software executes it, and the result is handed back for the model to read. This loop — request, execute, return — is the entire mechanism behind every "AI that takes actions." The craft is in the tool descriptions: a well-written one says what the tool does and when not to use it.
An AI that "takes actions" is asking software to act on its behalf. How well that goes depends heavily on how clearly each tool is described, including when not to use it.
3 · Connectors: the sockets
For a model to touch your calendar, docs, or codebase, something must translate between "model wants a thing" and each app's API. The Model Context Protocol (MCP), an open standard, standardizes that translation: an app exposes an MCP server; any compatible assistant can plug in and use its tools. Think of it as USB for AI capabilities: one plug shape, many devices.
4 · How loading actually works
Nothing mystical: the skill's instructions are placed into the model's context — the same window your chat occupies — usually on demand rather than all at once, because context is finite and expensive. The model reads the instructions like any other text and, being trained to follow instructions, follows them. The quality of a skill is therefore the quality of its writing: precise, ordered, with worked examples. Skills are prompt engineering that got a filing cabinet.
5 · The honest risks
Skills and tools inherit the model's central vulnerability: it cannot fully distinguish instructions from content. A malicious document can whisper "ignore your rules" — prompt injection — and a tool-equipped agent has real hands to misuse. Sane deployments therefore sandbox tools, require human confirmation for consequential actions, and treat third-party skills like third-party code: check the source before you install. The glossary holds the vocabulary; the caution holds everywhere.
Treat a third-party skill like third-party code and check its source before installing it. Once an agent has tools, keep a human confirmation step on anything consequential it can do.
6 · Why this matters to non-builders
Because this is the shape of the next few years of work: not "an AI," but an AI plus a stack of skills your team wrote, holding your standards. The people who can write a clear procedure — teachers, ops leads, senior anyone — turn out to be exactly the people who can author good skills. The bottleneck is not code. It is knowing how the work should be done, and writing it down well.
If you can write a clear procedure for how a job should be done, you already have the main ability that skill authoring needs. Start with the writing, not the code.
Part of the Stay Human record. Continue: the tools atlas → · back to repos