MCP dispose de SDK officiels pour plusieurs langages, mais pour le travail d’ingénierie de données, Python et TypeScript sont les choix pratiques. Les autres SDK (Go, Rust, Java, C#) existent et sont prêts pour la production, mais l’outillage de l’écosystème et le support des bibliothèques pour le travail data favorisent largement ces deux langages.
SDK Python
Pour les équipes d’ingénierie de données travaillant en Python, c’est l’option principale.
- Package :
mcpsur PyPI - Dépôt : github.com/modelcontextprotocol/python-sdk
- Version actuelle : v1.25.0 (v2 en développement)
- Prérequis : Python 3.10+
Installation avec uv (recommandé) :
uv add "mcp[cli]"Ou avec pip :
pip install "mcp[cli]"L’extra [cli] inclut des outils en ligne de commande pour les tests et l’installation — utile pendant le développement même si vous les supprimez en production.
Le SDK inclut FastMCP, un framework de haut niveau qui utilise des décorateurs pour définir des outils, des ressources et des prompts. FastMCP gère automatiquement la sérialisation JSON-RPC, la gestion du transport et la négociation de protocole. Vous écrivez des fonctions Python avec des annotations de type et des docstrings ; FastMCP les transforme en outils MCP. Voir FastMCP Server Skeleton pour le tutoriel pratique.
Le principal avantage du SDK Python pour l’ingénierie de données est l’accès aux bibliothèques. Vous pouvez importer pandas, SQLAlchemy, boto3, la bibliothèque client BigQuery, le client API d’Airflow — tout ce que votre stack de données utilise. Vos outils MCP sont de simples fonctions Python, donc ils peuvent appeler tout ce que Python peut appeler.
SDK TypeScript
Pour les équipes avec une infrastructure Node.js, ou les développeurs full-stack s’orientant vers les outils data :
- Packages :
@modelcontextprotocol/server,@modelcontextprotocol/client - Dépôt : github.com/modelcontextprotocol/typescript-sdk
- Prérequis : Node.js 18+ (22.7.5+ recommandé)
Installation :
npm install @modelcontextprotocol/server zodLe SDK TypeScript utilise Zod pour la validation de schéma, ce qui offre une bonne sécurité de type et un support IDE solide. Les schémas d’entrée des outils sont définis avec des types Zod plutôt que des annotations de type Python, et la validation du schéma se produit au niveau du SDK avant que votre code de gestionnaire s’exécute.
TypeScript est un bon choix pour les charges de travail lourdes en I/O asynchrone — si votre serveur doit effectuer de nombreux appels d’API concurrents ou gérer des données en streaming, le modèle de boucle d’événements de Node fonctionne bien. Il convient également lorsque votre serveur MCP fait partie d’une architecture de services Node.js plus large.
Framework de décision
| Critère | Python | TypeScript |
|---|---|---|
| Base de code existante | Pipelines de données, notebooks, dbt | Applications web, services Node |
| Bibliothèques | pandas, SQLAlchemy, boto3 | Mieux pour les charges de travail I/O asynchrones lourdes |
| Expertise de l’équipe | Ingénieurs de données | Développeurs full-stack |
| Déploiement | Fonctionne avec uvx, facile à distribuer | Packages npm, conteneurisé |
| Validation de schéma | Annotations de type + Pydantic | Schémas Zod |
La décision se résume généralement à une question : que votre équipe écrit-elle déjà ? Si vos pipelines de données sont en Python, vos notebooks sont en Python, et votre équipe pense en Python — utilisez Python. Vous réutiliserez le code, les bibliothèques et les modèles mentaux existants.
Si votre infrastructure est basée sur Node, ou si votre équipe fait du JavaScript full-stack, TypeScript évite une frontière de langage. Mais pour la plupart des travaux d’ingénierie de données, Python avec FastMCP est le chemin le plus rapide vers un serveur fonctionnel.
Considérations de distribution
La façon dont vous distribuez le serveur compte aussi.
Les serveurs Python fonctionnent bien avec uvx pour une exécution sans installation — les utilisateurs exécutent uvx your-package et ça fonctionne. La commande uv run gère automatiquement la création d’environnements virtuels et la résolution de dépendances. Pour la distribution interne, la publication sur un index PyPI privé ou la distribution comme package installable depuis Git fonctionnent toutes les deux.
Les serveurs TypeScript se distribuent comme packages npm ou conteneurs Docker. La commande npx offre une expérience sans installation similaire à uvx. Pour les équipes qui publient déjà des packages npm, cela s’intègre naturellement dans les pipelines CI/CD existants.
Les deux langages se conteneurisent facilement. Pour les serveurs d’équipe partagés qui s’exécutent comme services HTTP (voir MCP Transport Configuration), le choix du langage importe moins — le serveur est derrière un endpoint HTTP dans tous les cas.
Une équipe, un SDK
Évitez de mélanger les SDK au sein d’une équipe sans raison impérieuse. Standardiser sur un SDK signifie des connaissances partagées, des techniques de débogage partagées et des patterns de déploiement partagés. Si votre équipe construit cinq serveurs MCP personnalisés, tous les cinq devraient utiliser le même SDK pour que n’importe qui puisse maintenir n’importe quel serveur.
L’exception est lorsque vous encapsulez une bibliothèque qui n’existe que dans un seul langage. Si un outil interne critique dispose d’un client TypeScript mais pas d’équivalent Python, écrire ce seul serveur en TypeScript tout en gardant le reste en Python est un choix pragmatique raisonnable.