Skills vs MCPs: Choosing the Right Fit for CCDV-F

Two different kinds of customization

You have already weighed built-in tools versus custom tools. Skills and MCPs are the next pair to distinguish, and they are easy to confuse because both are ways to extend what Claude can do. But they extend it in fundamentally different directions, and the Claude Certified Developer - Foundations (CCDV-F) exam tests whether you can tell which direction a given need points. Because this is an apply-level knowledge point, you must choose the right one for a scenario, not just define both.

The one-line contrast: a Skill packages know-how, and an MCP provides connected capability. Skills shape how Claude does something; MCPs give Claude something live to connect to.

Skills: packaged know-how

A Skill packages a reusable procedure or body of knowledge that shapes how Claude performs a task. Think of it as encapsulated expertise: a way of doing something, a set of conventions, a procedure that you want Claude to apply consistently whenever the task comes up. A Skill teaches Claude how to approach a class of work, and it is reusable across the situations where that work recurs.

Crucially, a Skill is about know-how, not about a live connection. It carries the procedure and the knowledge, but it does not itself stand up a running service that reaches out to an external database or API at runtime. This is exactly where the first exam trap lives: using a Skill where live external data access is required. If the task genuinely needs to pull current data from an external system or take an action against one, a Skill alone cannot do it, because a Skill packages procedure, not connectivity. That need calls for a tool or an MCP.

MCPs: connected capability at runtime

An MCP server exposes live tools and data that an application connects to at runtime. Where a Skill is know-how, an MCP is a live connection: it is the thing your application reaches out to in order to query a database, call an API, or otherwise touch an external system while the conversation is happening. As covered in MCP server authoring and deployment, an MCP server is authored, deployed, and connected to, and that runtime connection is precisely its value.

The mirror-image trap is standing up an MCP server for what is really a reusable procedure best packaged as a Skill. MCP servers are powerful, but they carry the weight of authoring, deploying, and maintaining a running service. If the need is actually just a consistent way of doing a task, with no live external data or action involved, an MCP is heavy machinery for a job a Skill does more simply. Reaching for an MCP when a Skill fits over-engineers the solution.

The deciding question: is live connectivity needed?

The clean test is to ask whether the task needs a live connection to external data or actions at runtime. If yes, because the work requires current data from a system or an action against one, you need an MCP (or a tool). If no, because the work is really a reusable way of doing something that Claude can carry out with packaged know-how, a Skill fits and is simpler.

That single question resolves most scenarios. A procedure for formatting reports in your house style, a consistent method for reviewing a document, a body of domain conventions: these are know-how, so they are Skills. Querying the live orders database, calling the payments API, reading current inventory: these need connectivity, so they are MCPs. When both are present, the answer is often to use both, which is exactly the combined thinking of selecting the right agentic customization approach.

The traps the exam sets

The two traps are mirror images, and both come from ignoring the connectivity question. The first is using a Skill where live external data access is required. The tell is a design that packages a procedure but then needs current data from an external system the Skill cannot reach. The correction is an MCP or a tool for the live connection.

The second is standing up an MCP server for what is really a reusable procedure best packaged as a Skill. The tell is heavy service infrastructure built for something that involves no live external data or action, just a consistent way of doing a task. The correction is to package it as a Skill.

Common misreadings to avoid

How this is tested on the exam

Domain 8 questions on this knowledge point describe a need and ask whether a Skill or an MCP fits, or show a design that mismatched the two and ask what is wrong. The correct answers come back to the deciding question: does the task require live external data or actions at runtime? If yes, MCP; if no, Skill. Because this is an apply-level knowledge point, you must read the scenario for the presence or absence of live connectivity and choose accordingly, recognising too that many real designs use both. That combined view is where selecting the right agentic customization approach takes this next.