Claude Skills vs MCP Servers

There are two ways to make Claude better at something, and people mix them up constantly. Getting the difference clear saves a lot of wasted effort.

The difference, in one line

A skill teaches Claude how you want something done.

An MCP server gives Claude something it cannot otherwise see.

Think of a new colleague. Teaching them your team’s rules is a skill. Giving them a key to the filing cabinet is a server. Both help, but they fix different problems, and neither one fixes the other.

So what is MCP?

MCP stands for Model Context Protocol. That sounds heavier than it is.

A protocol is just an agreed way for two things to talk. A plug and a socket agree on a shape, so any plug fits any socket. MCP is that idea for software: it is an agreed shape for connecting an assistant to an outside service.

The useful part is that you build the connection once. Because everyone agrees on the shape, that one connection then works with any assistant that speaks MCP, instead of you building a separate one for each.

Which one do you need?

Ask yourself one question: is Claude doing it badly, or is it unable to do it at all?

If Claude can do the job but keeps doing it the wrong way, that is a teaching problem. Write a skill. Your writing style, your naming rules, your checklist.

If Claude cannot do the job because the information lives somewhere it cannot reach, that is an access problem. You need a server. Your sales figures, your support tickets, today’s prices, live search rankings.

This is the mistake worth avoiding: writing a skill that says “check our current search rankings” does absolutely nothing. There is nothing there for Claude to check. No amount of instruction creates information.

Building one

Anthropic publishes a guide for this as a skill of its own, called mcp-builder. It covers building servers in Python or in JavaScript.

What you are building is a small list of actions Claude is allowed to take. Each action has a name, some inputs, and a description. Claude reads that list and picks one.

The part people get wrong

The instinct is to expose every possible action. That produces something Claude uses badly, because it has no manual to consult and nobody to ask.

Things that genuinely help:

• Name each action after the job. find_customer_by_email is obvious. get_users with six optional settings is not.
• Explain every input as if to someone who cannot see any documentation, because that is exactly the situation.
• Send back less. An answer with 400 pieces of information buries the four that mattered.
• Make errors helpful. “Not found. Try searching by partial name instead” beats a bare error code.
• Keep anything that deletes things separate, and name it so it cannot be triggered by accident.

One safety point worth understanding

Your server runs with whatever permissions you give it, and Claude decides when to use it. Those two facts together deserve some thought.

Give it the least access that still works. If reading is enough, do not allow writing.

There is also a trick worth knowing about. If your server hands Claude text from somewhere you do not control, such as a web page or a message someone else wrote, that text could contain instructions aimed at Claude. Models are not reliably able to tell the difference between “here is some information” and “here is an order”. So treat anything coming from outside as information only, and design as though it might be hostile.

Where to start

First, check whether someone has already built a server for the service you want. Many companies now publish one, so you may not need to build anything.

If you do build, start with three or four actions covering the thing you actually do. A small, clearly described server gets used correctly. A huge one gets used badly.