Skills vs MCP vs workflows for AI agents

What is the difference between skills, MCP and workflows?

They answer three different questions. A skill answers "how do I do this kind of task?" MCP answers "what can I reach?" A workflow answers "what happens next, and where do we stop?" Comparing them as rivals is the root of most confusion. They sit at different layers, and the strongest setups use each for its own job.

The table compares them on the dimensions that matter when you choose. "Workflow" covers two different designs, because the word means two things today: a script that orchestrates agents inside one session, and a process an engine holds across sessions.

1. Skill: a folder with SKILL.md in a repo or home folder; sign-off only if the model asks
2. MCP server: a local process or remote URL exposing tools; sign-off through per-tool permission prompts
3. Scripted workflow: a script file such as .claude/workflows/, resumable within the session; no mid-run input
4. Engine-held workflow: stored outside the session, so any session resumes the run; approval gates hold it

What is an agent skill?

An agent skill is a packaged procedure the agent loads on demand. The Agent Skills format, originally developed by Anthropic and released as an open standard, defines a skill as a folder containing a SKILL.md file with a name, a description and instructions, optionally bundled with scripts, references and assets. It is supported by many agent products, including Claude Code, OpenAI Codex, Cursor, GitHub Copilot and OpenCode.

The key mechanism is progressive disclosure: at startup the agent loads only each skill's name and description; the full instructions load when a task matches, or when you invoke the skill directly. In Claude Code, project skills live in .claude/skills/<name>/SKILL.md and run with /skill-name. That makes skills cheap to keep on hand.

What a skill is not: an enforcement mechanism. The model decides whether a skill is relevant and follows its instructions as context. That is exactly right for know-how ("how we write release notes") and not enough for obligations ("nothing ships without sign-off").

---
name: release-notes
description: Write release notes. Use when a release is being prepared.
---

Lead with what users can do now.
Group changes by user impact, not by component.
No internal ticket numbers.

sourcesAgent Skills open formatClaude Code docs: skills

What is MCP?

The Model Context Protocol is "an open-source standard for connecting AI applications to external systems". Its own analogy is a USB-C port for AI applications: one way to plug data sources, tools and workflows into any compatible client. A server exposes tools the model can call, resources it can read and prompts it can use; clients such as Claude, ChatGPT, Cursor and VS Code connect to servers through configuration.

MCP is the reach layer (see the MCP definition). It is how an agent gets to your issue tracker, your database or your workflow engine without custom glue for every pair of client and system. Permission prompts and server-side checks control what each call may do.

What MCP is not: a plan. A server describes what is possible; it does not say in what order things should happen or where a person must decide. That belongs to the layer above.

Treat each server as access you grant. A server acts with the credentials you give it, local servers run as programs on your machine, and remote servers usually sign you in with OAuth. Prefer servers with narrow scopes, read what each tool can change before you approve it, and remove servers you no longer use, since every connected server adds tool descriptions to the context.

claude mcp add --transport http convops https://mcp.convops.app/

sourcesModel Context Protocol: introduction

What is a workflow for AI agents?

A workflow decides the order of work. Two designs share the name, and they solve different problems.

A scripted workflow moves the plan into code that runs inside a session. Claude Code's dynamic workflows are the clearest example: Claude writes a JavaScript script that orchestrates many subagents, a runtime executes it in the background, and saved scripts live in .claude/workflows/. Anthropic documents its limits plainly: no mid-run user input ("for sign-off between stages, run each stage as its own workflow"), resumable within the same session, and up to 1,000 agents per run. It is excellent for audits, migrations and cross-checked research.

An engine-held workflow keeps the process outside any session. The engine stores the steps and the cursor, hands the agent one step at a time, and evaluates gates before the run can move. Runs persist, so a different person or a different AI client can resume where the last one stopped. ConvOps is this kind of engine, reached over MCP. Steps inside one workflow run in order, never at the same time; parallel work is split into child tasks that start together while the parent waits.

The two designs answer different risks. A scripted workflow protects you from doing a large job by hand: it spreads the work across many agents and collects the results. An engine-held workflow protects you from doing a repeated job differently each time: it keeps the order, holds the run at the points where a person must decide, and records each step so the run can be picked up by someone else. A team that runs a nightly audit and a weekly release may reasonably use both, and the release workflow can even start a step that kicks off a scripted sweep.

sourcesClaude Code docs: dynamic workflows

When should you use a skill, MCP or a workflow?

Choose by the question you are trying to answer, then combine. A quick rule of thumb: reach for MCP when the data or the action lives in another system, a skill when the know-how stays the same from task to task, and a workflow when the order and the stopping points matter.

1. The agent keeps doing a task slightly differently each time: write a skill
2. The agent cannot reach a system it needs: connect an MCP server
3. One job needs dozens of agents in parallel, finished in one sitting: use a scripted workflow
4. Work must follow the same steps every time, across people, sessions or tools: use an engine-held workflow
5. A person must approve before something happens: put an approval gate in a workflow, not a sentence in a skill
6. A rule should reach the agent at the moment it applies: deliver it inside the step, and keep stops in gates

How do skills, MCP and workflows work together?

Take a release process. MCP connects the agent to the workflow engine and to your code host. The workflow holds the steps: prepare the changelog, run the checks, wait for approval, publish. The changelog step names a skill, so the agent loads the release-notes know-how exactly when it is needed. The approval step is a gate, so the run stops until a person passes it, whatever the model thinks.

Each layer does what it is good at. The skill keeps the craft in one file. MCP keeps access standard. The workflow keeps order and accountability. Remove any layer and you push its job into a place that handles it badly: process written into a skill, or know-how pasted into every step.

The layers also travel well. The Agent Skills format and MCP are both supported across many clients, and an engine reached over MCP serves the same steps to any of them. A teammate in Cursor and another in Claude Code can run the same release workflow, load the same skill and stop at the same gate.

{
  "id": "changelog",
  "instructions": "Draft the release notes with the release-notes skill.",
  "gate": { "require_context": true }
}
{
  "id": "approve",
  "gate": { "requires_approval": true }
}

What are the common mistakes?

Most failures come from asking one layer to do another layer's job. The fix is rarely a better prompt; it is moving the responsibility to the layer built for it.

Frequently asked questions