In short
- A skill is know-how: a folder of instructions, scripts and resources that the AI agent opens when the task calls for it.
- MCP (Model Context Protocol) is a socket: an open standard for plugging an AI assistant into a tool or a data source.
- The two combine. To link an agent to an SME's software, I prefer to write and review each connector myself. It is not a dogma: an MCP server published by the software's vendor can be a good choice.
By Maxime Desbonnet, managing director of Kendu Intelligence.
You have probably come across two words: “skills” and “MCP”. An AI agent is a program that relies on an AI model (the engine that reads and writes) to prepare or carry out tasks in your software. Skills and MCP both help make it useful. But they do not do the same thing.
A skill: know-how the agent opens at the right moment
Anthropic, the maker of the Claude AI model, launched Agent Skills in October 2025. Its definition: folders that contain “instructions, scripts, and resources” that Claude can load when it needs them.
The folder contains a main page: what the skill does, when to use it, how to proceed. You can add templates, reference notes or small programs.
The agent reads these folders in stages. At start-up, it only knows the name and short description of each skill. It opens the full instructions only when a request matches, and the extra files only if it needs them. You can therefore give it many without cluttering it.
Anthropic compares writing a skill to preparing an onboarding guide for a new joiner. Take an “unpaid invoice reminder” skill: the tone to use, the deadlines, the customers never to chase, the email template. It says how to do it. It gives access to no software.
Since December 2025, this format has been an open standard, and AI tools other than Anthropic's have adopted it.
MCP: a socket to plug the AI into your tools
MCP, or Model Context Protocol, is a protocol: a common rule so that two programs can talk to each other. Anthropic published it as open source in November 2024, then handed it in December 2025 to the Agentic AI Foundation, a foundation created within the Linux Foundation.
Its official website presents it as a standard for connecting AI applications to external systems, and compares it to a USB-C port: one socket, whatever the device.
On one side, the AI application; on the other, an “MCP server”: a program that gives access to a tool or to data, for example reading files, querying a database or checking a calendar. The same server can serve several assistants: Claude, ChatGPT and several development tools support MCP.
The difference in one picture
Imagine a new accountant arriving. They need the month-end closing procedure: that is the skill. They also need access to the accounting software: that is MCP.
| Skill | MCP | |
|---|---|---|
| What it is | Know-how, a procedure | A socket to a tool or to data |
| What it brings | The way of doing things | The access |
| Example | The company's reminder rules | Reading invoices in the invoicing software |
One without the other is not enough, and the two combine. Anthropic says so itself: skills can complement MCP servers by teaching agents more complex sequences that involve external tools.
Why I prefer to do everything in-house
“In-house” means this: the skills and connectors (the bridges between the agent and your software) of the agents I build, I write them myself, with Claude, and I review them. It is a preference, not a dogma. Here are my reasons.
Knowing exactly what each connector does. The MCP specification says it plainly: the tools exposed by a server represent arbitrary code execution and must be treated with caution. Their descriptions cannot be trusted unless they come from a trusted server. Anthropic, for its part, encourages writing your own MCP servers or using those of trusted providers, and states that it performs no security audit of MCP servers. The same caution applies to skills: Anthropic's documentation advises using only those you created yourself or obtained from Anthropic, because a malicious skill can lead to a data leak.
Connecting directly to the official interfaces. When software publishes an API (the official front door provided for other programs), I prefer to connect to it directly rather than stack servers written by third parties.
Fewer intermediaries. Every server added is one more program to watch, and one more place your data and access pass through. The MCP security guide stresses it: overly broad rights granted from the outset make the damage worse if access is stolen. I give each connector the strict minimum: if it has to read invoices, it cannot modify them.
Keeping control of what comes in. “Prompt injection” is booby-trapped text, in an email or a web page, that tries to hijack the agent. Anthropic's documentation warns that servers that fetch external content can expose you to this risk. A connector I write passes the model only what is intended.
Keeping data on servers under control. The connectors will run wherever you choose: on your servers, in your cloud account in a European region, or on a server I administer, hosted in the European Union at OVH. The AI model, for its part, may be called at a provider, in a European region: the Data and security page details this point.
Testing and reviewing everything before use. Each connector will go through automatic tests and a review before touching your data, then be frozen in a version.
Reversibility. The code written for you and your agents' instructions will be handed over to you. What exactly comes to you will be written in the contract, before set-up.
What MCP does very well
I am not rejecting MCP. It is an open standard. According to its official website, it reduces development time and complexity. And a connector written once serves several assistants: that is the strength of its ecosystem.
Besides, “in-house” does not mean “without MCP”. A connector I write can very well take the form of an MCP server. What matters to me is knowing who wrote it and what it does.
An official MCP server can also be a good choice. Some software vendors publish their own. I consider it when it is published and maintained by the vendor itself, when it asks only for the access that is useful, when its documentation says where the data goes, and when that place suits you. I then review it before connecting it, freeze its version and limit its rights.
In short
The skill brings the know-how, MCP brings the access. Both are useful. My preference: write, test and review the connections to your software myself, and only add a third-party server if it comes from the vendor and I have checked it.
Do you have a process to hand to an agent, or a question about these choices? Write to me.
Going further
- Data and security: where the agents run and where your data goes.
- The method: from the audit to going live.
- n8n, Make, Zapier or custom agent: which to choose?
- Request an audit.