Skills vs MCP Tools: When to Use Which
An MCP tool is a single callable action, like creating an issue or sending a message. A Skill is a packaged procedure that tells an agent which tools to use, in what order, and under what constraints. Tools are the verbs; a Skill is the instruction that uses them. You need both, and they are not alternatives.
The confusion comes from both being described as "what an agent can do". One is a capability, the other is a procedure that uses capabilities.
What is an MCP tool?
A tool is one action a server exposes: a name, a description, and a typed input schema. create_issue takes a title and a body and creates an issue. It has no opinion about when it should be called or what should happen next.
Tools are the atoms. A model given twenty tools can combine them, but it will combine them slightly differently every time, because nothing tells it what your team's process actually is.
What is a Skill?
A Skill packages a procedure: the instructions for a job, plus the specific tools that job needs. "Triage an inbound bug report" is a Skill. It says which fields to check, which tools to call, when to escalate, and what to leave alone.
The important property is that it is shareable. One person writes the procedure once, and everyone who should have it gets the same behavior, rather than each person re-explaining the job to their own chat window.
When should you use a tool versus a Skill?
Use a tool when the action is atomic and the model can reasonably decide when to call it.
Use a Skill when the job has steps, when the order matters, when there are rules about what not to do, or when you need two people to get the same result. Consistency is the real signal: if it matters that everyone does it the same way, it is a Skill.
Why does the distinction matter for rollouts?
Because they fail differently.
Tool problems are access problems. Someone cannot reach the system, or the credentials are wrong, or nobody knows which agent did what. Those are solved by a gateway.
Skill problems are distribution problems. The procedure exists in one person's head or one person's chat history, and there is no way to hand it to the rest of the team. When Skills live in a code repository, non-engineers cannot contribute, which quietly caps AI adoption at the engineering department. We wrote about that in AI skills without GitHub.
How does Metorial handle both?
Metorial treats them as separate layers on purpose. Integrations supply the tools, with per-user OAuth and access control deciding who reaches what. Agent Skills sit above them, so a support lead can write a refund triage procedure in the morning and have the team using it that afternoon, without touching a repository. Tracing records both the Skill run and each underlying tool call.
Where this is not the right fit: if your Skills are authored exclusively by engineers who already live in Git and review each other's changes, a repository-based workflow gives you code review for free, and Metorial's advantage mostly disappears.
Frequently asked questions
Can a Skill work without MCP tools?
A Skill made only of instructions works, but it can only change how the model reasons or writes. To do anything in an external system it needs tools. In practice most useful Skills bundle instructions with the specific tools the procedure requires.
Do I need to write code to create a Skill?
Not with Metorial. A Skill is written as instructions plus a set of tools, so someone in support or operations can create one without a GitHub account or a pull request. That is the main difference from repository-based approaches.
How is a Skill different from a system prompt?
A system prompt applies to every request in a session. A Skill is scoped, shareable, and versioned: it applies to one procedure, carries its own tool access, and can be granted to a group rather than pasted between people.
Who should own Skills, engineering or the team using them?
The team doing the work, in most cases. They know the procedure, and a Skill they can edit stays current. Engineering usually owns the underlying tools and the access policy, which is a cleaner split than one team owning both.
What happens when a Skill needs a tool the user cannot access?
Access control still applies. A Skill does not widen permissions, so a user without access to a tool cannot reach it through a Skill. The Skill is a procedure, not an escalation path.