Agent skills glossary: skill, tool, MCP, plugin, agent, prompt
Plain-language definitions for the AI agent vocabulary that gets used loosely everywhere: what's a skill, what's a tool, how MCP fits in, how plugins differ, and what an agent actually is.
On this page
The AI agent vocabulary is a mess. The same word means different things in different products, and adjacent terms (skill, tool, plugin, action, integration, MCP server) get used as synonyms even when they describe different layers. This page is the canonical definitions used across the rest of the site. Bookmark it; everything else links here.
Where two terms overlap in the wild, the entry below names the most common version and notes how this site uses it.
Skill
A markdown file that describes how an agent should solve a particular problem, step by step. It tells the agent what to do, when to ask for confirmation, what tools to call, and what to return. A skill is not code. It does not execute anything by itself. It is instructions, written in human language, that the agent reads and follows.
A skill file might say: “When the user asks for a code review, run gh pr diff to get the changes, read each modified file, check for missing error handling and missing tests, and produce a markdown report grouped by severity.” That whole recipe lives in one file you can copy, share, and version-control. See the skills library for real ones.
Skills compose. One skill can reference another. A “release prep” skill might invoke a “release notes” skill and a “commit message” skill. See skill composition for how that works.
Note: “skill” is this site’s framing for the markdown-recipe layer. It is not a documented product term in any of the major AI APIs (Anthropic, OpenAI, Google all describe their feature set in terms of system prompts, tools, and assistants). The skill concept is a useful construct for designing agent behavior; treat it as a pedagogical layer, not a vendor primitive.
Tool
A function the agent can call. Tools are the leaf operations: read_file, search_codebase, query_database, send_slack_message, gh pr view. A tool has a name, a description, a parameter schema, and a return shape. The agent sees the description, decides whether to call the tool, fills in the parameters, and acts on the result.
Tools have no opinions. A read_file tool reads a file. It doesn’t know whether reading the file is the right next step. That judgment lives in the skill (or in the LLM’s reasoning if no skill is in play).
The Anthropic, OpenAI, and Google APIs all support tools, with slightly different schemas. Anthropic’s tool_use mechanism, OpenAI’s function calling (and its successor, the Responses API), and Google’s function calling are the three you’ll most often encounter. They’re conceptually identical: name + description + JSON-schema parameters.
See how skills use tools and the cost of bad descriptions for how tool descriptions drive correct selection.
Skill vs tool: the recipe analogy
A skill is a recipe. A tool is a kitchen appliance. The recipe tells you what to do (preheat the oven, measure flour, mix wet ingredients separately, fold gently). The appliances let you actually do it (oven, mixer, scale). A recipe without appliances is just instructions on paper. Appliances without a recipe is a kitchen full of equipment and no plan.
If you find yourself trying to fix a bad agent by adding more tools, you probably need a better skill instead. If you find yourself encoding too much logic in your skill prose, you probably need a tool that does the boring part. See skills-vs-tools-vs-plugins-vs-integrations for the longer treatment.
MCP
The Model Context Protocol. An open protocol, originally developed by Anthropic, for letting agents discover and call tools that live in a separate process. Instead of hard-coding each tool into your agent’s code, you point the agent at an MCP server (which can be local or remote) and the agent learns the available tools at runtime through the protocol.
MCP servers can wrap anything: a database, a SaaS API, a filesystem, a Slack workspace. There are MCP servers for GitHub, for Postgres, for Slack, for Notion. Adding new capabilities to an agent becomes “install the right MCP server” instead of “rebuild your agent code.”
MCP is not the only way to expose tools. Direct tool definitions in an SDK call still work. OpenAPI specs work. Custom RPC schemes work. MCP is one standard among several, gaining adoption because it’s open and decoupled from any single vendor’s runtime.
For building skills with MCP-exposed tools, see building skills with MCP.
Plugin
A packaged unit that adds capabilities to a host AI product. The unit usually contains tools, sometimes prompt context, sometimes UI elements. Plugins exist at the product layer (a thing the product’s vendor curates and the user installs), not the protocol layer.
Examples: ChatGPT plugins (deprecated in 2024, replaced by GPTs and then Custom Actions), Claude desktop extensions, ChatGPT Custom Actions defined by OpenAPI specs. Each ecosystem has its own packaging format and its own marketplace.
A plugin can include tools (and often does), but a plugin is not the same thing as a tool. The plugin is the package; the tools are what’s inside. Plugins are also distinct from skills: a plugin ships from a vendor; a skill is something a user authors and copies into their own project.
Integration
A connection between an AI product and an external system. “We have a Slack integration” means the product can read and write Slack. The integration handles authentication, API calls, and any data shuttling.
The line between “integration” and “plugin” is fuzzy in practice. Often integration means the connection itself (the auth and the wiring) and plugin means the user-facing package that uses the integration. Sometimes products use the words interchangeably. When in doubt, treat “integration” as the deeper plumbing layer and “plugin” as the surface package built on top.
Agent
A system that combines a language model with the ability to take actions in the world. The model produces text that includes tool calls; the runtime executes the tool calls; the results come back to the model; the loop continues until the model decides it’s done.
“Agent” is used widely and loosely. Sometimes it means the whole system (model + tools + runtime). Sometimes it means a configured persona inside a product (a “code review agent”). Sometimes it means a planner that decides which sub-tasks to run. This site uses “agent” to mean the whole system unless it says otherwise.
For how agents work mechanically, see how agents actually work under the hood.
Prompt
The text input to a language model. A prompt can be a single user message (“Summarize this email”) or a long structured conversation including a system prompt, user messages, and prior model responses.
In casual usage, “prompt” sometimes means just the user’s typed message. In API usage, “prompt” means the entire input to the model, which is usually a structured object with role-tagged messages.
System prompt
A prompt that sets the model’s behavior for the whole session, separate from the user’s messages. System prompts are where you encode persona, constraints, and standing instructions: “You are a careful code reviewer. Always cite specific line numbers. Never modify files without confirmation.”
System prompts and skills overlap. A simple agent might encode all its instructions in the system prompt. A more complex agent might use a short system prompt and load specific skills based on what the user asks for. This site treats system prompts and skills as different layers because they have different lifecycles: the system prompt is set when the agent is configured; skills are loaded per-task.
Prompt engineering vs skill design
Prompt engineering is the art of getting one good response from one prompt. Skill design is the art of getting reliable behavior across many invocations.
The two overlap (skills are written in natural language, so writing a skill is partly prompt engineering), but they have different goals. Prompt engineering optimizes for a single output. Skill design optimizes for a repeatable, composable, testable recipe. See prompt engineering vs skill design for the longer take.
Skill library
A collection of reusable skill files that an agent has access to. The library can be project-local (.claude/skills/ in a repo), user-global (~/.claude/skills/), or vendored from somewhere else. The agent picks which skill to invoke based on the task and the skill descriptions, the same way it picks which tool to call.
Too few skills in the library means the agent has to invent every recipe from scratch. Too many means the agent struggles to pick the right one. There’s a sweet spot, and it depends on how you’ve named and described your skills. See skill design principles for how to keep a library navigable.
Function calling
The mechanism by which a language model can ask the runtime to invoke a function. OpenAI’s term. Synonymous in practice with tool use (Anthropic’s term) and function execution. They all describe the same loop: model outputs a structured request to call a function, runtime calls the function, result goes back to the model.
If you’ve heard “function calling” and “tool use” treated as different things, they’re not. They’re the same idea with different names from different vendors.
Action
In some products (notably ChatGPT Custom Actions), “action” is the vendor’s word for what the rest of the industry calls a tool. Same concept, different label. If you’re reading OpenAI documentation that talks about actions, mentally translate to tools.
Guardrails
Constraints applied to an agent’s behavior, separate from the skill’s own instructions. Guardrails might block certain outputs (no PII, no profanity), require approval for certain actions (no production database writes without human sign-off), or limit resource usage (no more than 30 LLM calls per task). They live at the runtime layer, between the model and the tools.
A skill can also encode guardrails as part of its instructions (“Never run remediation actions; only diagnose”), but those rely on the model following the instructions. Runtime guardrails enforce the same constraints even if the model would otherwise ignore them.
See security considerations for agent skills and human-in-the-loop patterns for how guardrails fit into a real system.
Tool description
The natural-language explanation of what a tool does, attached to the tool’s name and parameter schema. The agent reads tool descriptions to decide which tool to call. If the descriptions are vague, the agent picks the wrong tool. If the descriptions are precise and include “use this when X / don’t use this when Y,” the agent picks correctly.
Tool descriptions are the single most underrated part of agent design. See the cost of bad descriptions.
Skill description
The natural-language explanation of what a skill does, attached to the skill file’s frontmatter or top section. The agent reads skill descriptions to decide which skill to invoke for a task, the same way it reads tool descriptions to decide which tool to call. The distinction between skill descriptions and tool descriptions parallels the distinction between skills and tools: skills describe workflows, tools describe operations.
When to reach for which
| What you want | What to write |
|---|---|
| Repeatable workflow with multiple steps | A skill |
| A single capability the agent can call | A tool |
| Agent able to talk to an external service | A tool (or an MCP server if you want it shareable) |
| A package of tools and configuration shipped to users | A plugin |
| The connection plumbing between systems | An integration |
| Standing behavioral rules for an agent | A system prompt (or runtime guardrails for hard constraints) |
Why the vocabulary keeps drifting
Every vendor introduced their own term for these concepts before any of them stabilized. OpenAI shipped functions, then plugins, then GPTs, then Custom Actions. Anthropic shipped tool_use, then MCP. Google shipped function calling, then extensions. The industry never agreed on shared names because the products were competing for terminology as much as for features.
The drift is unlikely to resolve. The right move is to learn the underlying concepts and translate vendor terms when needed. A “Custom Action” in ChatGPT and a tool_use block in Claude are the same thing. A GPT and a Claude Project and a Gemini Gem are roughly the same thing (a packaged agent persona with optional tool access). Treat the names as labels on top of a smaller set of real concepts.
For the longer essay version of this with more examples, see skills vs tools vs plugins vs integrations.
Related articles
How agents actually work under the hood
The think-act-observe loop, tool calling, and context windows explained without the hype. What's really happening when an AI agent does something for you.
Prompt engineering vs skill design
They sound similar but they solve different problems. When to write a better prompt and when to build a skill instead.
What are agent skills and why they matter
A beginner-friendly introduction to AI agent skills: what they are, why they're transforming how we work with AI, and how to think about them.