Should I use skills or MCP?

Usually both. Use MCP when the agent needs to reach a system it cannot otherwise access, such as GitHub, a database or a SaaS tool. Use a skill when the agent needs to know how to do a task well, such as your team's review process or a document format. A skill often uses MCP tools to do its work.

Can a skill replace an MCP server?

Only if the task needs no external access, or the access is available through the shell or a CLI already on the machine. A skill can wrap a CLI in a script. For anything that needs authentication to a remote system, an MCP server is the cleaner and safer option.

Which is more secure, skills or MCP?

They have different risks. MCP servers hold credentials and can act on systems, so their risk is over-permission and injection through results. Skills run scripts and shape the model's behaviour, so their risk is supply chain: an untrusted skill can instruct the agent to do harmful things. Both need review and an allowlist in a team setting.

Do skills use more tokens than MCP?

A skill costs nothing until it is loaded, then costs the length of its SKILL.md. An MCP server costs its tool descriptions on every session. A server with 40 tools can be more expensive per session than several skills.

Claude skills vs MCP: what each one does and when to use which

Two features arrived a year apart and get confused constantly. MCP, the Model Context Protocol, launched in November 2024. Skills launched in October 2025. Both extend what an agent can do, and both live in folders and config files, so it is natural to ask which one to use.

The short answer: MCP is about access, skills are about know-how. The rest of this page makes that precise.

One sentence each

An MCP server gives the agent tools it did not have: search GitHub, query a database, post to Slack, drive a browser. It is a program running somewhere, exposing functions through a standard protocol. Read our MCP guide for the full picture.

A skill gives the agent instructions it did not have: how to write release notes the way your team does, how to produce a valid Excel file, how to run your incident checklist. It is a folder with a SKILL.md and optional scripts. Read our skills guide for the details.

Side by side

	MCP server	Skill
What it adds	Tools, resources, prompts from an external system	Instructions, examples, scripts for a task
Where it runs	A separate process, local or remote	Inside the agent's context; scripts run in the sandbox or shell
Needs credentials	Usually (OAuth, API keys)	Rarely; uses whatever tools are already available
Loaded when	Every session (tool descriptions)	Only when a task matches its description
Token cost	Per session, proportional to number of tools	Zero until used, then the file length
Portable to other agents	Yes, any MCP client	Yes, via the open Agent Skills spec
Main risk	Over-permission, prompt injection via results	Untrusted instructions and scripts
Owned by	Usually the vendor of the system	Usually your team

The question that decides it

Ask: does the agent lack access, or lack knowledge?

If the agent cannot do the task because it cannot reach something (the ticket system, the data warehouse, the deployment pipeline), that is an access problem. You need an MCP server, or a CLI the agent can call.

If the agent can reach everything but does the task badly (wrong format, wrong order, forgets a step, ignores a convention), that is a knowledge problem. You need a skill.

Most real tasks are both. "Prepare the release" needs access to GitHub and the deployment system (MCP) and the knowledge of what your release procedure is (skill).

How they work together

Here is a typical workflow with both.

A developer types "cut release 2.5". The agent matches the request to a release skill and loads it. The skill says:

Confirm the main branch is green using the CI tool.
List merged PRs since the last tag using the GitHub tool, excluding chore.
Draft release notes in the house format (example in examples/).
Create the tag and the GitHub release using the GitHub tool.
Post the notes to #releases using the Slack tool, then stop. Do not deploy.

Steps 1, 2, 4 and 5 call MCP tools. Steps 3 and the overall order come from the skill. Neither alone gets you a release done your way.

When a skill is enough

Skills can carry scripts, and scripts can call CLIs. If gh, aws or kubectl are already installed and authenticated on the machine, a skill can use them through the shell without any MCP server. For personal use that is often simpler.

It stops being enough when:

the agent runs somewhere without those CLIs (Claude.ai, the API, a CI runner);
you need per-user authorization rather than whatever the laptop's credentials allow;
you want the access to be discoverable and governable across a team.

At that point the access belongs in an MCP server.

When MCP is enough

If the task is genuinely "do the obvious thing with this tool" ("find open bugs assigned to me", "what changed in this file"), tool descriptions carry enough guidance and no skill is needed. Skills earn their place when there is a procedure, a format or a convention the model would not guess.

Governance: they meet at the gateway

For a team, both need an approved list. Skills are code and instructions from somewhere; MCP servers are code with credentials. A reviewed, versioned catalogue of each is the minimum.

But there is an asymmetry worth understanding. A skill describes a procedure; it cannot enforce who may run it. An MCP tool actually performs the action; it can be gated per user. So the enforcement point for "only the release manager may tag a release" is not the release skill but the policy on the GitHub server's create_release tool.

That is why, in a company deployment, both end up behind the same gateway: skills and servers are distributed through one client, tool policy is enforced per user, and the log shows which skill drove which tool call. Walma AI Hub does exactly that, inside the customer's own EU region. Book a walkthrough if you are working out how to standardise both across a team.