cursor

Cursor skill vs MCP tool: which one should a workflow be?

A Cursor skill is a folder with a SKILL.md file: written instructions, plus optional scripts, references, and assets, that the agent loads when it decides the skill is relevant or when you invoke it with /skill-name. An MCP tool is a function exposed by an MCP server; the agent calls it with structured arguments and the server runs code and returns a result. Make a workflow a skill when it's mostly procedure and judgment. Make it an MCP tool when it needs live data, credentials, or a system the agent can't reach, or when the result must be exact every time.

Who this is for

You have a repeatable workflow (a release routine, a review checklist, a lookup against an internal system) and you're deciding how to package it for Cursor. Both options make the agent "able to do the thing," but they work very differently.

How each one works

Skills. Cursor discovers skills at startup from `.cursor/skills/` or `.agents/skills/` in the project, or `~/.cursor/skills/` and `~/.agents/skills/` for your user. It also loads `.claude/skills/` and `.codex/skills/` for compatibility. The `SKILL.md` frontmatter needs a `name` (matching the folder) and a `description`, which the agent uses to decide relevance. Optional fields include `paths` to scope a skill to matching files and `disable-model-invocation: true` to make it run only when you type `/skill-name`. A skill can include a `scripts/` folder; the agent runs those with the tools it already has, such as the terminal. Agent Skills is an open standard, so the format isn't Cursor-only.

MCP tools. You configure MCP servers in `.cursor/mcp.json` (project) or `~/.cursor/mcp.json` (global), over `stdio`, SSE, or Streamable HTTP. In the MCP spec, tools are model-controlled: the client lists them with their input schemas and the model calls them through `tools/call`. Cursor asks for approval before using an MCP tool by default. Credentials go in the server config, ideally through `${env:NAME}` interpolation, so the agent never handles the key. If you're connecting a server that uses OAuth, see MCP OAuth in Cursor and Claude.

Decision table

QuestionSkillMCP tool
What is it?Instructions (+ optional scripts) the agent readsCode a server runs when called
Who executes?The agent, step by step, with its own toolsThe server, from one structured call
Needs a credential or private API?Awkward: the agent would handle the keyYes: keep the key in server config
Needs exact, repeatable output?Depends on the agent following stepsYes: same input, same code path
Mostly judgment and order of steps?YesOverkill
Where it lives`.cursor/skills/<name>/SKILL.md`A server entry in `mcp.json`
Other clientsAny client supporting the Agent Skills standardAny MCP client (protocol is shared)

Examples. "Before every release, bump the version, update the changelog, run tests, and summarize what changed" is a skill. "Look up a customer's plan in our billing system" is an MCP tool. "Triage a bug report using our labels, and pull the customer's plan" is a skill that tells the agent to call the billing MCP tool.

Pitfalls

  • Hiding an API key inside a skill script. If the workflow needs a secret, that part belongs behind an MCP server, where the key stays in config.
  • Building a server for a checklist. If every step is something the agent can already do, a skill is less to build and maintain.
  • Vague descriptions. The agent picks skills by `description`. "Helpers" won't trigger; "Use when cutting a release or bumping versions" will.
  • Assuming the skill can call MCP on its own. It can't. It tells the agent to, and the tool has to be connected and approved.

How to check it

  1. Open Customize → Skills and confirm the skill is listed. Then ask for the task in plain words and see whether the agent picks it up.
  2. For the MCP side, check that the tool appears in the agent's available tools, and look at the MCP Logs output panel if it doesn't.
  3. Run the workflow twice. If the skill version drifts where it shouldn't, move that step into a tool.

Where ShipKits fits

The Operator Pack ($47) is markdown seats + skills + install.sh — not a hosted app, not a chatbot. Seven named seats, three skills, an ops playbook and a token-cost playbook. Done means a file, PR, or URL. It's a starting point for the skill side of this decision; the MCP side is your own servers. Soft path: start at /free. Cheat Sheet for the skim checklist mindset.

Soft next step

Pick one workflow you repeat and write it as a `SKILL.md` first. Move only the step that needs a key or exact output into an MCP tool. Soft ladder: /free, then the Operator Pack ($47). Related: MCP OAuth in Cursor and Claude.

FAQ

What is the difference between a Cursor skill and an MCP tool?+

A skill is written instructions the agent reads and follows. An MCP tool is code a server runs when the agent calls it, returning a result.

When should a workflow be a skill?+

When it's mostly procedure and judgment the agent can carry out with tools it already has, like a review checklist or a release routine.

When should it be an MCP tool?+

When it needs code, credentials, or a system the agent can't reach directly, or when the result must be exact every time.

Can a skill call an MCP tool?+

A skill can tell the agent to use an MCP tool that's connected. The agent makes the call; the skill supplies when and how.

Which works across Cursor and Claude?+

MCP is a shared protocol, so one server can serve several clients. Skills follow the open Agent Skills standard, and Cursor also reads `.claude/skills/`, but check each client's docs for what it supports.

Can I start as a skill and move to MCP later?+

Yes, and it's often the right order. Prove the workflow as a skill, then move the parts that need code or exactness into an MCP tool.

Get the free starter

Value first, then a kit when you are ready. No fake urgency. Start with Harness Desk Starter at /free.