Comment combiner MCP et Agent Skills pour vos agents ?

Associer MCP et Agent Skills relie l’infrastructure aux comportements : MCP assure les intégrations robustes, Skills définissent les instructions métiers activées à la demande. Je détaille quand utiliser l’un ou l’autre, comment les faire coopérer, et les choix d’architecture, sécurité et invocation.

Comment MCP résout-il le problème N×M

Voici comment MCP réduit la complexité N×M en centralisant les intégrations entre plusieurs agents et multiples backends, transformant N×M en N+M via un pont standardisé.

Le problème N×M signifie N agents × M systèmes et implique des intégrations point à point. Chaque couple agent-backend nécessite une interface, une authentification et une maintenance propres. Avec la croissance, cela devient ingérable : explosions du nombre de connexions, multiplication des secrets, hétérogénéité des APIs, et surfaces d’attaque accrues.

Le rôle d’un protocole client-serveur MCP (ici entendu comme Middleware Communication Protocol) est de jouer le point unique d’authentification, de routage et de normalisation des appels. MCP centralise :

• Gestion des identités et des tokens pour réduire la prolifération de secrets.
• Normalisation des schémas et des méthodes (une seule signature par action).
• Routage dynamique vers les backends et traduction des formats.

Un exemple chiffré simple illustre le gain. Avec 5 agents et 8 services :

Intégrations point à point = 5 × 8 = 40. Intégrations via MCP = 5 + 8 = 13. Gain immédiat sur la complexité d’intégration et la maintenance.

Schéma textuel des composants impliqués :

• Agents (5) → Clients envoyant des requêtes métier.
• MCP → Point central d’authentification, routage, logging, transformation.
• Backends (8) → Services distants (DB, API, ERP, etc.).

Exemple JSON-RPC (JSON Remote Procedure Call, protocole léger pour appeler des méthodes à distance) :

{
  "jsonrpc": "2.0",
  "method": "fetchInvoice",
  "params": {"invoiceId": 12345, "format": "pdf"},
  "id": 1
}

{
  "jsonrpc": "2.0",
  "result": {"status": "ok", "url": "https://mcp.internal/files/12345.pdf"},
  "id": 1
}

Critère	Intégrations directes	Via MCP
Maintenance	Élevée (multiples adaptateurs)	Réduite (centralisation des adaptateurs)
Sécurité	Multiplication des secrets, surfaces d’attaque	Point d’audit unique, gestion centralisée des tokens
Scalabilité	Difficile à automatiser	Facile (ajout d’agents ou backends sans N×M)
Latence	Moindre en théorie (moins d’étapes)	Légère surcharge possible, compensée par cache et optimisations

Quelle est la différence d’architecture entre MCP et Skills

MCP est un service/processus backend avec son propre runtime et cycle de vie, tandis que les Agent Skills sont des dossiers légers et des assets locaux qui codent le comportement.
MCP signifie « Middleware Control Plane » ici, c’est le service central qui expose des endpoints (par exemple JSON‑RPC, un protocole d’appel de procédures à distance basé sur JSON) pour orchestrer, authentifier et exécuter des tâches lourdes.
MCP tourne typiquement dans un conteneur (Docker/Kubernetes), peut être écrit en Go, Python ou Rust en fonction des besoins de performance, et gère le cycle de vie, la montée en charge, la sécurité et la persistance.
MCP doit intégrer la gestion des secrets (Vault, KMS), des logs structurés (JSON), des métriques (Prometheus) et du tracing distribué (OpenTelemetry) pour l’observabilité.
Un runtime représente l’environnement d’exécution du service (versions de langage, dépendances, workers) et impose des contraintes de déploiement et de scalabilité.

Les Skills sont des packages légers stockés localement dans l’agent ou publiés dans une registry de skills.
Une structure type pour un Skill :

• SKILL.md pour la documentation et les exemples d’usage.
• manifest.json pour le métadata (id, version, permissions requises).
• scripts/ avec les scripts d’exécution ou adaptateurs (Python/Node).
• examples/ pour démonstrations et fixtures.
• tests/ pour les tests unitaires et d’intégration.

Un manifest exemple :

{
  "id": "pdf-extract",
  "version": "1.2.0",
  "permissions": ["filesystem:read"]
}

Les Skills sont versionnés comme des artefacts (Git tags, registry) et déployés soit avec l’agent (embedded), soit récupérés au démarrage depuis une registry.

Impact CI/CD et packaging :

• MCP nécessite pipelines pour build d’image, tests d’intégration, déploiement blue/green et migrations de DB.
• Les Skills demandent pipelines légers : lint, tests unitaires et publication dans une registry ou packaging dans l’agent.

Exemple d’arborescence pour un Skill d’extraction PDF :

pdf-extract/
├─ SKILL.md
├─ manifest.json
├─ scripts/
│  └─ extract.py
├─ examples/
│  └─ sample.pdf
└─ tests/
   └─ test_extract.py

Interaction (texte) :

Agent → Skill local
Agent charge scripts locaux → extraction directe (faible latence)

Agent → MCP → Backend
Agent appelle MCP (JSON‑RPC) → MCP orchestre job, accès secrets, renvoie résultat

Aspect	MCP	Skills
Déploiement	Service conteneurisé, CI/CD d’image	Embeddé à l’agent ou via registry
Versioning	Image/version de service	Package/git tag/manifest.json
Observabilité	Métriques, logs centralisés, tracing	Logs locaux, moins de tracing centralisé
Maintenance	Opérations et scalabilité dédiées	Simple à mettre à jour, dépend de la distribution

Comment s’invoquent MCP et Agent Skills

MCP s’invoque via appels typés (JSON-RPC/HTTP) avec schémas et paramètres stricts, alors que les Skills s’invoquent souvent par exécution locale (shell, scripts, prompts) plus flexible.

MCP (protocole typé pour appels RPC/HTTP) apporte typage, validation et contrats clairs entre l’agent et l’outil, ce qui facilite le chaînage d’outils sans ambiguïté. Skills, exécutés localement, favorisent la rapidité d’itération et le prototypage mais exigent plus de garde-fous pour la robustesse.

Avantages et limites :

• Pour MCP : Contrats robustes et validation automatique, meilleur traçage des erreurs, mais coût d’implémentation et rigidité pour changements rapides.
• Pour Skills : Déploiement et itération rapides, accès natif aux ressources système, mais risques de non-typage, erreurs non standardisées et difficulté de composition.

Exemple de requête JSON-RPC complète (avec schémas simplifiés) :

{
  "jsonrpc": "2.0",
  "method": "fetchUserData",
  "params": {
    "userId": "1234"
  },
  "id": 1
}
/* Schéma params (JSON Schema) :
{
  "type":"object",
  "required":["userId"],
  "properties":{"userId":{"type":"string"}}
}
Résultat attendu :
{
  "jsonrpc":"2.0",
  "result":{"userId":"1234","name":"Alice","email":"a@ex.com"},
  "id":1
}
*/

Exemple de Skill (bash + Python) :

#!/bin/bash
# wrapper.sh - appelle le skill python
python3 skill.py "$1" "$2"

# skill.py
import sys, json
# Lit les arguments (userId, action)
userId = sys.argv[1] if len(sys.argv)>1 else ""
action = sys.argv[2] if len(sys.argv)>2 else "info"
# Traitement simple
output = {"userId": userId, "action": action, "ok": True}
print(json.dumps(output))

Chaînage MCP exemple : Authentification (mcp.auth.login → retourne token typé) → Fetch data (mcp.data.get avec token) → Write back (mcp.data.update avec id et payload).

Bonnes pratiques :

• Valider les schémas en entrée/sortie pour éviter les ambiguïtés.
• Définir des timeouts et retries explicites pour chaque appel.
• Logger de façon structurée (JSON) avec ids de corrélation.
• Sanitiser et limiter les droits des Skills locaux.

Patterns d’invocation recommandés selon cas d’usage :

• APIs critiques et composition d’outils : MCP typé (contrats, validation).
• Prototype et exploration locale : Skills (bash/python) pour itération rapide.
• Workflows mixtes : Auth via MCP, traitements locaux via Skills, retour via MCP.
• Opérations sensibles : MCP + audit logging + RBAC.

Où s’exécutent MCP et les Skills et quelles sont les implications sécurité

MCP tourne typiquement dans des conteneurs isolés ou un service backend avec contrôle centralisé des secrets, tandis que les Skills s’exécutent dans l’environnement local de l’agent, avec accès natif aux outils système. Cette séparation induit des choix de sécurité différents et complémentaires.
MCP (Model Coordination Plane : plan de coordination des modèles) centralise l’orchestration, l’authentification et la gestion des clés, ce qui en fait un bon point unique pour appliquer des politiques de sécurité. Isolation par conteneurs, pare-feu applicatif (WAF) et rotation centralisée des clés réduisent la surface d’attaque exposée. Skills locaux offrent des latences plus faibles et un accès direct aux fichiers, au réseau et aux périphériques, mais augmentent le risque d’escalade si l’exécution n’est pas confinée.

Principaux enjeux sécurité : isolation, surface d’attaque, gestion des secrets, audits et principe de moindre privilège. Isolation permet de réduire la blast radius (zone affectée lors d’une compromission). Gestion des secrets centralisée (ex. HashiCorp Vault) facilite la rotation et l’audit ; les logs centralisés permettent une corrélation et détection d’incidents (conformément aux bonnes pratiques NIST et OWASP). Skills locaux demandent sandboxing (ex. namespaces, seccomp, AppArmor), scan des dépendances (SCA : Software Composition Analysis) et politiques strictes d’exécution.

Mesures concrètes à appliquer :

• Isoler MCP : Déployer dans des namespaces/containers dédiés et exposer uniquement les APIs nécessaires.
• Moindre privilège : Utiliser run-as-nonroot, IAM roles pour services et permissions minimales.
• Gestion des secrets : Centraliser avec Vault, activer rotation automatique et audit des accès.
• Supply chain : Verrouiller dépendances avec lockfiles, builder immuable (esbuild/CI) et SCA (ex. Snyk, Dependabot).
• Sandbox Skills : Appliquer seccomp/AppArmor, limites CPU/mémoire, timeouts d’exécution et whitelisting d’APIs.
• Monitoring & WAF : Mettre en place IDS/IPS, WAF devant MCP et logs centralisés (ELK, Splunk).

Aspect	MCP	Skills locaux
Isolation	Fort (containers/services centralisés)	Variable (doit être forcée par sandbox)
Risque sur les secrets	Centralisé, plus facile à contrôler	Réparti, nécessite vault et tokens éphémères
Latence	Plus élevée (réseau)	Faible (accès natif)
Facilité debug	Meilleure traçabilité	Plus complexe, dépend des environnements

Recommandations pratiques de hardening : appliquer le principe de moindre privilège partout, centraliser les secrets et les rotations, imposer SCA et lockfiles dans la CI/CD, sandboxer strictement les Skills avec limites de ressources et audits réguliers, et enfin instrumenter MCP pour monitoring en temps réel et WAF. Sources et standards utiles : OWASP Top 10, NIST SP 800-53, HashiCorp Vault, guides CIS pour containers.

Comment choisir et combiner MCP et Skills pour votre infra

La meilleure approche est hybride — MCP pour intégrations fréquentes et critiques à l’infrastructure, Skills pour comportements légers, expérimentations et instructions métiers.
La notion de MCP (Managed Connector Provider) correspond ici à un service centralisé et sécurisé qui expose API stables vers GitHub, bases Postgres, ou passerelles de paiement.
La notion de Skill désigne des modules légers attachés à l’agent, faciles à itérer et déployer, sans accès direct à ressources sensibles.

Voici les critères à considérer avant de choisir ou combiner, avec une phrase d’explication suivie des éléments :

• Fréquence d’appel : Prendre en compte le volume de requêtes quotidien attendu.
• Criticité des données : Considérer la sensibilité (PII, paiements, secrets) et le besoin d’audit.
• Besoin de schémas : Vérifier si des contrats/JSON Schema sont nécessaires pour validation.
• Vitesse d’itération : Évaluer la rapidité souhaitée pour tester et déployer des comportements.
• Maintenance : Estimer l’effort pour versionner, monitorer et corriger les composants.
• Coût opérationnel : Estimer coûts de compute, latence et facturation d’API externes.

Règles concrètes :

• Si appels > 1000/j ou données sensibles : Privilégier MCP pour centraliser sécurité, audit et scalabilité.
• Si besoin d’itérer vite et faible criticité : Favoriser Skill pour prototypage et déploiement rapide.
• Pour cas mixtes : Utiliser Skill pour orchestration locale et MCP pour accès aux ressources critiques.

Architecture cible (diagramme textuel) :

Agent Local
  ├─ Skills (intent handlers, transformations)
  └─ Appels → MCP (authentifié)
MCP (central)
  ├─ /github/* → GitHub API (tokens rotatifs)
  ├─ /db/* → Postgres proxied (RBAC + audit)
  └─ /payments/* → Payment gateway (HSM/secure vault)

Exemples :

# Manifest simplifié pour registre de Skills (YAML)
name: quick-search
version: 0.1.0
scope: agent-local
entry: handlers/search.js
permissions: [local-files]

Exemples d’endpoints MCP et policy-flow pour auth :

• GET /mcp/github/repos — Proxy vers GitHub avec token rotatif.
• POST /mcp/db/query — Proxy SQL, validé par JSON Schema et logs d’audit.
• Policy-flow : Présentation d’un jeton client → Vérification RBAC → Injection de scope minimal → Journalisation de l’appel.

Cas d’usage	Solution recommandée
Accès à GitHub pour CI/CD, fort trafic	MCP
Prototypage d’une action métier non sensible	Skill
Lecture de base Postgres contenant PII	MCP
Orchestration locale et enrichment de prompts	Hybride

Prêt à déployer une architecture hybride MCP plus Skills pour vos agents ?

MCP et Agent Skills ne s’opposent pas : MCP industrialise et sécurise les intégrations, les Skills codifient les comportements métiers et accélèrent l’itération. En combinant les deux on obtient un agent scalable (systèmes) et adaptable (cerveau). Pour vous, cela signifie réduction des coûts d’intégration, meilleure sécurité des secrets et une capacité d’évolution rapide des comportements — bénéfices directs pour la fiabilité opérationnelle et la rapidité de mise sur le marché.

FAQ

• Qu’est-ce que MCP ?
  MCP est un protocole client-serveur standardisé qui sert de pont entre agents et systèmes externes, offrant des appels typés, gestion centralisée des secrets et des règles d’authentification.
• Que sont les Agent Skills ?
  Les Skills sont des packages locaux (fichiers, scripts, manifests, exemples) qui codent des instructions métiers et des playbooks déclenchés à la demande par l’agent.
• Quand choisir MCP plutôt qu’un Skill ?
  Privilégiez MCP pour les intégrations à haute fréquence, critiques ou nécessitant des schémas stricts et un contrôle centralisé des secrets. Utilisez un Skill pour des tâches légères, prototypes ou instructions métiers rapides.
• Quels sont les risques sécurité quand on utilise des Skills locaux ?
  Les risques incluent fuite de secrets, exécution de dépendances non vérifiées et élévation de privilèges. Mitigez-les par sandboxing, scans SCA, policies d’exécution et quotas.
• Peut-on migrer des intégrations point à point vers MCP sans tout réécrire ?
  Oui : planifiez une migration progressive en exposant d’abord des adapters compatibles JSON-RPC, documentez les schémas et refactorez ensuite les clients pour consommer le MCP. Priorisez les intégrations les plus critiques ou les plus coûteuses à maintenir.

 

 

A propos de l’auteur

Franck Scandolera — expert & formateur en Tracking avancé server-side, Analytics Engineering, Automatisation No/Low Code (n8n), intégration de l’IA en entreprise et SEO/GEO. Responsable de l’agence webAnalyste et de l’organisme de formation Formations Analytics. Références clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez moi.