MCP, tools, skills : le bras d’un agent expliqué simplement
MCP, tools et skills ne sont pas trois noms pour la même chose. Protocole, actions, savoir-faire : ce qu’une PME branche, et ce qu’elle laisse fermé.
Dans cet article
On vous vend « on a mis MCP ». Trois minutes plus tard, c’est un chat avec un bouton. Ou vingt connecteurs, dont trois peuvent écrire dans le CRM. Les mots se ressemblent. Les jobs, non.
La différence chat / agent est déjà posée. Trop de skills aussi. Ici on range le troisième tiroir, celui du bras : ce que l’agent a le droit de faire, comment il le sait, et par quelle prise ça arrive.
En une phrase
Un tool est une action.
Une skill est un savoir-faire chargé quand la tâche le demande.
MCP est un protocole pour brancher, chez quelqu’un d’autre, des tools (et parfois des données en lecture).
Le modèle reste le cerveau. Le bras, on le câble.
Trois meubles, un seul marketing
Faits lus le 6 septembre 2026 dans la spécification MCP 2026-07-28, le billet de sortie, agentskills.io et la doc Hermes, sauf mention contraire.
Tools. Dans MCP, un serveur peut exposer des fonctions que le modèle appelle : tools/list, tools/call. La spec le dit : un tool est piloté par le modèle. Elle ajoute qu’il devrait rester un humain capable de refuser. Côté Hermes, les tools natifs (recherche, terminal, fichiers) et les tools MCP se présentent de la même façon à l’agent une fois découverts.
Skills. agentskills.io : une skill est un dossier avec un SKILL.md, éventuellement des scripts et des références. L’agent ne charge d’abord que le nom et la description. Le reste vient si la tâche colle. Hermes le dit pareil : progressive disclosure, compatible avec ce format. Ce n’est pas un bouton. C’est une procédure.
MCP. Protocole JSON-RPC. Trois rôles : host (l’app), client (le connecteur dans l’app), server (ce qui fournit le contexte). Un serveur peut offrir resources (données), prompts (modèles de messages) et tools (actions). La version du 28 juillet 2026 passe le cœur en sans session : chaque requête se suffit, un équilibreur simple peut répartir. Ce n’est pas « l’IA magique ». C’est une prise standard.
Un workflow n8n n’est pas MCP. Un chat n’est pas un tool. Une skill n’est pas un droit d’écriture sur le dossier client.
Ce que ça change pour une PME
Vous pouvez brancher un logiciel qui existe déjà, sans réécrire un connecteur maison. Hermes le formule ainsi : si le tool vit ailleurs (GitHub, fichiers, API interne), MCP est souvent le chemin le plus propre. Local (stdio) ou distant (HTTP), même config.
Vous pouvez, et devez, filtrer. Après installation, Hermes sonde le serveur et propose une checklist. Seuls les tools cochés restent visibles. Un exemple de la doc : un catalogue Cloudflare d’environ 3 300 tools OpenAPI. Tout laisser allumé n’est pas de la prudence. C’est du bruit, et du risque.
Le protocole a durci l’auth. La spec 2026-07-28 ajoute la validation d’émetteur (RFC 9207), lie les identifiants au serveur qui les a émis, et déprécie l’enregistrement dynamique de clients au profit de documents de métadonnées. Ça concerne surtout qui déploie un serveur. Pour une PME qui consomme, ça veut dire : ne pas coller un token « qui marche partout ».
Skills over MCP n’est pas encore le cœur. Un groupe de travail pousse une extension (SEP-2640, en revue). Aujourd’hui, dans le protocole de base, une skill reste un dossier SKILL.md. MCP transporte surtout des tools.
Ce que ça ne change pas
Brancher un MCP n’élargit pas ce que la nLPD vous autorise à coller. Un tool read_invoice sur un serveur distant est un traitement. Le protocole le rappelle : consentement, contrôle, descriptions de tools à traiter comme non fiables si le serveur n’est pas de confiance.
Un catalogue « revu par Nous » n’est pas une garantie métier. Hermes écrit que les manifests passent par une PR, et qu’il faut quand même lire la source, les commandes d’install et ce que le serveur exécute.
Une skill bien écrite ne remplace pas un premier agent utile. On part du travail répétitif, des données autorisées, de la personne qui relit, puis de l’outil.
Self-host d’un LLM et MCP ne sont pas le même fil. MCP peut parler à un serveur local. Ça ne décide pas où tourne le modèle.
Un exemple, clairement marqué comme exemple
Imaginez un cabinet de cinq personnes à Lausanne. Le besoin réel : relire les devis du mois, pas « avoir de l’IA ».
- Skill : une page qui dit comment on nomme un devis, qui relit, ce qu’on ne copie jamais dans un chat.
- Tools natifs : lire un PDF déjà exporté dans un dossier prévu, rédiger un brouillon.
- MCP : éventuellement un serveur fichiers borné à ce dossier, lecture seule. Pas le partage complet, pas le CRM en écriture.
Si le devis est encore dans le logiciel métier avec des noms de clients, on n’ouvre pas le MCP « pour voir ». On exporte ce qui est autorisé, ou on ne fait pas.
Ce n’est pas un mandat Kervia. C’est une scène pour coller les trois mots sur un geste.
Ce que Kervia en fait
On ne pose pas MCP « parce que c’est sorti ». On pose : quelle action, sur quelles données, avec quelle relecture.
Un agent Hermes peut déjà beaucoup sans MCP. On ajoute un serveur quand un tool manque et qu’il existe ailleurs, puis on coupe ce qui écrit, supprime ou exfiltre.
Les skills, on les garde minces. Trop, et l’agent se noie : c’est le sujet de l’autre article. MCP n’annule pas cette règle. Il peut l’aggraver, si chaque serveur déverse cinquante tools.
Limites de cet article
- La spec MCP du 28 juillet 2026 est longue. On n’en tire que ce qui change un usage PME (prise, tools, auth, absence de session).
- « Skills over MCP » est un travail en cours, pas une primitive livrée.
- Les exemples de catalogues (n8n, Linear, Cloudflare) viennent de la doc Hermes. Ce ne sont pas des tests Kervia.
- Cet article n’est pas un avis d’avocat.
Les mots techniques, en clair
| Terme | En clair |
|---|---|
| Tool | Une action nommée, avec des paramètres, que le modèle peut demander. |
| Skill | Un dossier de consignes chargé à la demande (SKILL.md). |
| MCP | Un protocole pour que l’app parle à un serveur de tools / données. |
| Resource | Une donnée exposée en lecture, pas forcément une action. |
| Host / client / server | L’app, le connecteur dans l’app, le service au bout du câble. |
| stdio / HTTP | Serveur local lancé comme un processus, ou serveur distant. |
Sources
Consultées le 6 septembre 2026.
- Spécification MCP 2026-07-28
- Tools, spec MCP
- Annonce spec 2026-07-28
- Agent Skills
- Skills over MCP (charte du groupe)
- Hermes, MCP
- Hermes, skills
- Hermes, tools
Voir aussi : chat ou agent · trop de skills · premier agent utile · données clients · agent, chatbot ou n8n.
QUESTIONS FRÉQUENTES
Pour aller à l’essentiel.
MCP est-il un agent IA ?
Non. La spécification MCP du 28 juillet 2026 le décrit comme un protocole ouvert pour relier une application LLM à des sources de contexte et à des tools. L’agent, s’il y en a un, reste le logiciel qui choisit quoi appeler. MCP est la prise, pas le métier.
Une skill est-elle un tool MCP ?
Pas dans le cœur du protocole. agentskills.io définit une skill comme un dossier avec un SKILL.md (consignes, parfois scripts). MCP expose surtout tools, resources et prompts. Un groupe de travail MCP travaille à une extension « Skills over MCP » (SEP-2640, en revue). Ce n’est pas encore une primitive de base.
Faut-il brancher tous les MCP du catalogue ?
Non. La doc Hermes le dit clairement : le catalogue est désactivé par défaut, on installe ce qu’on veut, et on peut filtrer les tools un par un. Un serveur Cloudflare cité comme exemple y affiche des milliers de tools. Trop d’actions visibles brouille le choix, comme trop de skills.
