Créer un serveur MCP en 30 minutes : le guide étape par étape

Créer un serveur MCP, c'est écrire un petit service qui met des outils, des ressources et des prompts à la disposition de clients IA comme Claude via le Model Context Protocol. Tu choisis un SDK (Python ou TypeScript), tu définis au moins un outil, tu choisis le transport (stdio ou Streamable HTTP) et tu enregistres le serveur dans le client. Le protocole repose sur JSON-RPC 2.0 et le SDK prend en charge à ta place tout l'échange de messages. Tu écris seulement ta logique métier.

Trois réponses rapides pour commencer :

• Pour un premier serveur fonctionnel, il suffit d'un SDK, d'un environnement d'exécution (Python ou Node.js) et d'un seul outil. C'est faisable en 30 minutes environ.
• En local, tu développes avec le transport stdio (pas de port, pas d'authentification) ; pour les serveurs distants, tu utilises Streamable HTTP avec OAuth 2.1.
• MCP relie les agents aux outils et aux données. La collaboration entre agents autonomes relève d'A2A, pas de MCP.

Ce qu'est vraiment un serveur MCP

Anthropic a lancé le Model Context Protocol le 25 novembre 2024 comme standard ouvert pour connecter les applications d'IA à des systèmes externes : systèmes de fichiers, bases de données, logiciels de gestion, outils de développement. Ses auteurs sont David Soria Parra et Justin Spahr-Summers. Techniquement, MCP est un protocole JSON-RPC 2.0 qui s'appuie sur des transports interchangeables. Au lieu d'inventer un format propre pour chaque intégration d'outil, client et serveur parlent la même langue.

Un serveur MCP met trois primitives à la disposition du client :

• Outils : des fonctions que le modèle peut appeler activement (par exemple « consulter la météo », « écrire un enregistrement »). C'est la brique la plus importante et la plus courante.
• Ressources : des sources de données lisibles que le client peut charger dans le contexte (fichiers, contenus de bases de données, configurations).
• Prompts : des modèles prédéfinis et paramétrables que l'utilisateur peut appeler depuis le client.

Pour débuter, tu te concentres uniquement sur un outil. Les ressources et les prompts viendront plus tard.

Étape 1 : choisir le transport (stdio ou HTTP)

La première décision d'architecture concerne le transport. MCP prend en charge plusieurs variantes, mais en pratique, deux seulement comptent.

Recommandation : commence par stdio. Le client lance ton serveur comme processus local et communique via l'entrée et la sortie standard. Pas de port, pas de configuration TLS, pas d'authentification à régler. Dès que ton serveur doit tourner à distance, servir plusieurs clients ou être placé derrière un contrôle d'accès, tu migres vers Streamable HTTP.

État de la spécification : Streamable HTTP est arrivé avec la révision de la spécification du 26 mars 2025 et a remplacé l'ancien transport HTTP+SSE. Cette même révision a introduit l'autorisation OAuth 2.1, les annotations d'outils et le batching JSON-RPC. La révision du 18 juin 2025 a de nouveau supprimé le batching. La révision du 25 novembre 2025 a notamment ajouté des tâches expérimentales pour les opérations asynchrones, l'élicitation par URL et les Client ID Metadata Documents pour l'enregistrement des clients. Le fonctionnement sans état, sans handshake d'initialisation, et l'appel server/discover, par lequel un serveur indique ses versions, ses capacités et son identité, ne sont arrivés qu'avec la révision du 28 juillet 2026.

Étape 2 : choisir le SDK (Python ou TypeScript)

Il existe des SDK officiels pour tous les grands langages de programmation ; les deux plus utilisés sont Python et TypeScript (plus de 97 millions de téléchargements mensuels à eux deux, chiffres 2026). Le choix suit tout simplement ta stack existante :

• Python : idéal pour les équipes orientées data/ML et le prototypage rapide.
• TypeScript : idéal pour les équipes orientées Node.js/Next.js et les stacks web.

Les deux SDK prennent en charge la gestion de JSON-RPC, la négociation des capacités et la connexion au transport. Tu déclares un outil avec un nom, une description et un schéma de paramètres, puis tu écris la fonction elle-même.

Étape 3 : serveur minimal avec un outil (pseudocode)

L'exemple en pseudocode ci-dessous montre un serveur doté d'un seul outil, qui convertit un montant d'une devise à une autre. La logique est volontairement triviale : c'est la structure qui compte.

```

Pseudocode (inspiré du style du SDK Python)

server = MCPServer(name="fx-tools")

@server.tool(
name="convert_currency",
description="Convertit un montant d'une devise vers une autre. "
"Attend montant (nombre), source (code ISO), cible (code ISO).",
input_schema={
"type": "object",
"properties": {
"montant": {"type": "number"},
"source": {"type": "string"},
"cible": {"type": "string"}
},
"required": ["montant", "source", "cible"]
}
)
def convert_currency(montant, source, cible):
taux = lookup_rate(source, cible) # logique métier propre
resultat = round(montant * taux, 2)
return {"resultat": resultat, "taux": taux}

IMPORTANT : logs UNIQUEMENT sur stderr, jamais sur stdout (casse JSON-RPC)

log_to_stderr("Démarrage du serveur")

server.run(transport="stdio")
```

Trois points sont décisifs ici et souvent négligés :

1. La description n'a rien de décoratif. Le modèle décide uniquement d'après le nom et la description s'il appelle l'outil et comment. Des descriptions vagues entraînent des appels erronés, voire aucun appel.
2. L'input_schema (JSON Schema) définit les paramètres de façon contraignante. Sans schéma correct, le client ne peut pas valider les arguments.
3. Avec le transport stdio, stdout est réservé au protocole. Tous les logs doivent aller sur stderr, sinon le flux JSON-RPC se casse.

Étape 4 : enregistrer et tester le serveur dans le client

Avec stdio, tu enregistres le serveur en indiquant au client sa commande de démarrage. Dans des clients comme Claude Desktop, cela passe par un fichier de configuration qui ressemble à peu près à ceci :

```
{
"mcpServers": {
"fx-tools": {
"command": "python",
"args": ["chemin/vers/server.py"]
}
}
}
```

Après un redémarrage du client, ton outil apparaît. Teste-le dans cet ordre :

1. Vérifier la découverte : convert_currency apparaît-il dans la liste des outils du client ? Sinon, c'est généralement le lancement du sous-processus qui échoue (mauvais chemin, dépendance manquante).
2. Provoquer un appel : pose une question qui déclenche l'outil (« Combien font 500 EUR en CHF ? »). Le client devrait appeler l'outil avec les bons arguments.
3. Vérifier la réponse : le serveur renvoie-t-il un résultat bien formé que le client intègre dans sa réponse ?

Pour déboguer indépendamment du modèle, le MCP Inspector officiel est précieux : un outil autonome issu du projet MCP, qui te permet d'appeler des outils directement et de suivre le protocole JSON-RPC en direct. Le débogage va ainsi beaucoup plus vite.

Exemple concret avec des chiffres

Imaginons que tu connectes une liste de prix interne. Le serveur expose un outil get_product_price. Un collaborateur demande dans le client : « Combien coûte l'article A-204 en variante L ? » Sans MCP, le modèle devrait deviner ou halluciner. Avec l'outil, le modèle appelle get_product_price(sku="A-204", variante="L"), le serveur renvoie {"preis": 49.90, "währung": "EUR", "lager": 12} et le modèle répond en s'appuyant sur des faits. Pour un tel outil en lecture seule, l'effort d'implémentation total tient en un fichier et quelques dizaines de lignes. L'essentiel des 30 minutes évoquées au début sert à connecter ta source de données existante, pas au protocole.

Erreurs fréquentes

• Logs sur stdout : l'erreur de débutant la plus courante avec le transport stdio. Tout ce qui n'est pas du JSON-RPC doit aller sur stderr.
• Descriptions d'outils vagues : le modèle n'appelle pas l'outil, ou l'appelle mal. Rédige tes descriptions comme une doc d'API destinée à un collègue.
• JSON Schema manquant ou erroné : champs obligatoires non marqués, types imprécis. Le client ne peut alors pas valider les arguments.
• Autorisations trop larges : un outil qui peut faire plus que nécessaire constitue une surface d'attaque. Le moindre privilège s'applique dès la première ligne.
• Failles de sécurité dues à des hypothèses de confiance : en 2025/2026, on a notamment documenté l'injection de prompt indirecte via les descriptions d'outils, l'empoisonnement d'outils (Invariant Labs, PoC WhatsApp d'avril 2025), le squatting par des serveurs look-alike, le Full-Schema Poisoning décrit par CyberArk (chaque partie d'un schéma d'outil peut servir de point d'injection) et le « Toxic Agent Flow » via des issues GitHub manipulées. En cause : le modèle de confiance de MCP, optimiste par principe, qui assimile la correction syntaxique à la sécurité sémantique. La sécurisation incombe à l'exploitant : sandboxing, tokens à portée limitée, OAuth 2.1 pour les transports HTTP et aucune installation automatique de serveurs MCP issus de registres non fiables.

Où en est-on en 2026

En 2026, MCP est le standard du secteur, largement soutenu, pour connecter les agents aux outils : le 9 décembre 2025, Anthropic a confié le protocole à l'Agentic AI Foundation, nouvellement créée sous l'égide de la Linux Foundation. La fondation a été cofondée par Anthropic, Block et OpenAI ; AWS, Bloomberg, Cloudflare, Google et Microsoft la soutiennent au niveau Platinum. MCP est notamment pris en charge par OpenAI (depuis mars 2025), Google DeepMind (avril 2025), Microsoft Copilot Studio, SAP Joule, Salesforce Agentforce, ainsi que n8n et LangGraph. Claude dispose d'un annuaire de plus de 75 connecteurs MCP officiels. Pour la collaboration entre agents autonomes, tu ne mises pas sur MCP mais sur A2A. La règle empirique : MCP pour les capacités, A2A pour la collaboration.

Pour les agences et le B2B

Pour les agences en Europe, un serveur MCP maison est la voie directe pour rendre des capacités propriétaires (une fonction de recherche de mots-clés, un CMS interne, une API de prix) utilisables quel que soit l'éditeur, sans développer une intégration spécifique pour chaque client IA. Un serveur MCP bien construit une fois se réutilise d'une gamme de produits à l'autre. Pour les décideurs B2B : si tu déploies des agents en 2026, tu consommeras ou écriras des serveurs MCP, que ce soit prévu ou non. Considère chaque outil comme un sujet d'autorisations et d'audit. Chez Blck Alpaca, nous concevons des serveurs MCP selon le principe du moindre privilège, avec des schémas propres et des pistes d'audit traçables. Contacte-nous si tu veux connecter une source de données interne à tes agents IA conformément au RGPD.