MCP : SDKs et frameworks, choisir sa stack

TL;DR : Dix langages disposent d’un SDK MCP officiel sous l’organisation modelcontextprotocol. Python reste le choix dominant pour les projets IA grâce à FastMCP (25 700 étoiles GitHub, environ 70 % des serveurs en production), qui réduit le boilerplate de 80 % par rapport au SDK bas niveau. Go s’impose pour les performances et les containers minimalistes. TypeScript couvre les applications Node.js. Java et Kotlin sont utiles pour les entreprises ayant l’habitude d’utiliser les JVMs de ces languages…. Cet article présente un extrait de code « hello tool » pour chaque SDK principal, compare SDK bas niveau et FastMCP côte à côte, et présente le choix de Python + FastMCP pour la suite de cette série MCP-101.

MCP est-il uniquement implémenté en Python ?

Si vous avez suivi la partie 1 de cette série, vous savez que MCP repose sur JSON-RPC 2.0 transporté via STDIO ou HTTP. Ce choix de protocole n’est pas accidentel : JSON-RPC 2.0 est un standard mature, lisible par n’importe quelle machine, et implémentable dans tout langage capable d’écrire sur stdout et de lire sur stdin. Un serveur MCP n’est pas un programme Python — c’est un processus qui répond à des messages JSON structurés selon une spécification ouverte.

En pratique, cela signifie que votre agent Claude Desktop peut piloter simultanément un serveur MCP écrit en Go interrogeant une base PostgreSQL, un serveur Python générant des images, et un serveur TypeScript intégré dans votre application Node.js existante. L’hôte MCP ne sait pas, et ne se soucie pas, du langage d’implémentation. Il voit des tools, des resources et des prompts définis dans un schéma JSON standardisé.

La spécification MCP étant ouverte, n’importe qui peut l’implémenter dans n’importe quel langage. Mais écrire un parseur JSON-RPC, gérer les transports STDIO et HTTP, valider les schémas d’entrée de chaque tool, et implémenter correctement le handshake d’initialisation peuvent représenter un certain travail d’écriture et de maintenance. C’est précisément ce que les SDKs officiels et les frameworks haut niveau éliminent. L’organisation modelcontextprotocol maintient aujourd’hui dix SDKs officiels couvrant les langages les plus utilisés, et des frameworks comme FastMCP et Google ADK ont émergé pour réduire encore davantage le boilerplate.

Cet article couvre les quatre SDKs officiels principaux avec un extrait de code fonctionnel pour chacun, présente FastMCP et Google ADK dans leur rôle respectif, puis donne un guide de choix clair par cas d’usage. La partie se conclut sur le choix de Python + FastMCP pour la suite de la série, avec la justification technique qui s’impose.

Quels sont les SDKs MCP officiels disponibles aujourd’hui ?

Python SDK — le plus adopté de l’écosystème

Le SDK Python (pip install mcp, ou uv add mcp avec uv) est de loin le plus utilisé de l’écosystème avec 23 400 étoiles GitHub en juin 2026. Maintenu par Anthropic sous l’organisation modelcontextprotocol, il implémente l’intégralité de la spécification MCP : transports STDIO, SSE et Streamable HTTP, primitives tools/resources/prompts, authentification OAuth 2.1, et le protocole de sampling. Il fonctionne sur Python 3.10+.

Le SDK propose deux niveaux d’API. L’API bas niveau donne un contrôle total sur chaque message du protocole, au prix d’un boilerplate significatif. FastMCP (inclus dans le package mcp.server.fastmcp) couvre les cas d’usage courants avec des décorateurs. Le quickstart officiel de modelcontextprotocol utilise FastMCP — ce n’est pas un hasard, et j’y reviens dans la section suivante.

Voici un tool « hello » complet en API bas niveau, tel qu’il serait écrit sans aucun framework :

from mcp.server import Server
from mcp.server.stdio import stdio_server
import mcp.types as types

server = Server("demo")

@server.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="hello",
            description="Retourne un message de bienvenue",
            inputSchema={"type": "object", "properties": {}},
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "hello":
        return [types.TextContent(type="text", text="Hello, World!")]

async def main():
    async with stdio_server() as (read, write):
        await server.run(read, write, server.create_initialization_options())

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

Ce code est correct et fonctionne. Mais il révèle les points de friction du SDK bas niveau : chaque tool nécessite deux handlers distincts (list_tools pour annoncer le tool à l’hôte, call_tool pour l’exécuter), le schéma JSON est écrit manuellement, et la gestion du transport STDIO est explicite. Pour un serveur exposant dix tools, la surface de code devient importante à maintenir. C’est ce que FastMCP adresse, comme je le montre un peu plus loin.

La version 2.0 du SDK Python est actuellement en alpha, avec une stabilisation de l’API client en priorité. Pour la production et pour cette série, c’est la v1.x stable qui est utilisée.

TypeScript SDK — pour les applications Node.js et multi-runtime

Le SDK TypeScript (npm install @modelcontextprotocol/sdk) est le deuxième SDK officiel par adoption avec 12 700 étoiles GitHub. Maintenu par Anthropic, il s’exécute sur Node.js, Deno et Bun. La version stable actuelle est la v1.29.0 (mars 2026). Une v2 est en pré-alpha, sans date de stabilisation annoncée.

L’API TypeScript est explicite mais cohérente avec les idiomes du langage. Les types sont stricts, la validation des schémas d’entrée repose sur Zod. Le SDK inclut des adaptateurs pour Express, Hono et le serveur HTTP natif Node.js, ce qui facilite l’intégration dans des applications web existantes. Un même serveur MCP TypeScript peut tourner en CLI stdio ou exposer un endpoint HTTP selon le transport instancié.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new McpServer({ name: "demo", version: "1.0.0" });

server.registerTool(
  "hello",
  {
    description: "Retourne un message de bienvenue",
    inputSchema: {}
  },
  async () => ({
    content: [{ type: "text", text: "Hello, World!" }]
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

L’API TypeScript unifie déclaration et implémentation en un seul appel registerTool, ce qui est plus concis que le SDK Python bas niveau. Les types TypeScript garantissent que le schéma d’entrée et le handler sont cohérents à la compilation. Pour un projet déjà en Node.js, ajouter un serveur MCP revient à installer un package et écrire quelques fichiers dans la structure existante.

Le SDK TypeScript est aussi le choix naturel pour les plugins d’éditeurs (VS Code, Cursor, Windsurf) et pour les services déployés sur des plateformes cloud-function Node.js comme Vercel ou Cloudflare Workers, où les runtimes Python ne sont pas disponibles.

Go SDK — performances et déploiement sans runtime

Le SDK Go (go get github.com/modelcontextprotocol/go-sdk), co-maintenu avec Google, est à la v1.6.1 (mai 2026) avec 4 700 étoiles GitHub. C’est l’option de référence pour les serveurs MCP à haute charge / hautes performances et les environnements contraints.

L’API Go suit les idiomes du langage : structs typés avec annotations JSON Schema, fonctions handler avec signature explicite, inférence du schéma depuis les types Go. L’annotation jsonschema sur les champs struct génère automatiquement le JSON Schema que MCP attend pour valider les entrées de l’outil côté client.

package main

import (
    "context"
    "github.com/modelcontextprotocol/go-sdk/mcp"
)

type HelloInput struct{}

type HelloOutput struct {
    Message string `json:"message" jsonschema:"description=Message de bienvenue"`
}

func hello(
    ctx context.Context,
    req *mcp.CallToolRequest,
    _ HelloInput,
) (*mcp.CallToolResult, HelloOutput, error) {
    return nil, HelloOutput{Message: "Hello, World!"}, nil
}

func main() {
    server := mcp.NewServer("demo", "1.0.0", nil)
    mcp.AddTool(
        server,
        &mcp.Tool{Name: "hello", Description: "Retourne un message de bienvenue"},
        hello,
    )
    server.Run()
}

Le compilateur Go valide les types à la compilation : si le handler retourne un type incompatible avec le schéma déclaré, l’erreur apparaît avant le déploiement. C’est un avantage non négligeable pour les serveurs MCP critiques exposés en production. Le binaire compilé tourne sans runtime Python ou Node.js installé, ce qui simplifie les containers Docker minimalistes : une image Alpine de quelques mégaoctets suffit.

Les goroutines sont également beaucoup plus légères qu’un thread Python ou une Promise Node.js pour le traitement concurrent de requêtes MCP. Si votre serveur doit gérer des centaines de requêtes simultanées (cas rare pour un serveur STDIO, plus courant pour un serveur HTTP exposé en production), Go est le choix approprié.

Java SDK — intégration Spring Boot et écosystème JVM

Le SDK Java (spring-ai-mcp via Maven ou Gradle), développé en collaboration avec l’équipe Spring AI de VMware Broadcom, est à la v2.0.0 (juin 2026) avec 3 500 étoiles GitHub. Il s’intègre nativement dans Spring Boot via des annotations, ce qui le rend familier pour les équipes utilisant Java et qui ont déjà -par exemple- des microservices Spring en production.

// Service exposant les tools MCP
public class HelloService {

    @Tool(description = "Retourne un message de bienvenue")
    public String hello() {
        return "Hello, World!";
    }
}

// Configuration Spring Boot
@SpringBootApplication
public class McpDemoApplication {

    @Bean
    public ToolCallbackProvider helloTool() {
        return MethodToolCallbackProvider.builder()
            .toolObjects(new HelloService())
            .build();
    }
}

L’intégration Spring Boot est le point fort du SDK Java : injection de dépendances, configuration centralisée via application.yml, Spring Security pour l’authentification, et Micrometer pour les métriques. Pour les équipes déjà sur Spring, exposer un service existant comme tool MCP revient à ajouter l’annotation @Tool et un bean de configuration. La migration d’un service REST vers MCP est une opération de quelques heures.

Le SDK Kotlin (modelcontextprotocol/kotlin-sdk, v0.13.0, co-maintenu avec JetBrains) offre la même fonctionnalité avec la concision idiomatique Kotlin. Les lambdas et les extensions du langage réduisent le boilerplate par rapport à Java :

// Kotlin SDK
val server = Server(
    ServerInfo(name = "demo", version = "1.0.0"),
    ServerOptions(capabilities = ServerCapabilities(tools = ServerCapabilities.Tools()))
)

server.addTool(
    name = "hello",
    description = "Retourne un message de bienvenue"
) { _ ->
    CallToolResult(
        content = listOf(TextContent(text = "Hello, World!"))
    )
}

Kotlin est le choix recommandé pour les nouveaux projets JVM grâce à sa sécurité « null » intégrée dans le système de types et à la réduction du code boilerplate. JetBrains co-maintient ce SDK, ce qui signale une continuité de support pour l’écosystème IntelliJ et les futures versions de Kotlin.

Tableau comparatif des cinq SDKs principaux

SDK	Version stable	Étoiles GitHub	Co-mainteneur	Boilerplate	Déploiement	Cas d’usage typique
Python	v1.x	23 400	Anthropic	Faible (avec FastMCP)	pip + venv / uv	Data, IA, scripting, prototypage rapide
TypeScript	v1.29.0	12 700	Anthropic	Moyen	npm + Node.js / Deno	Apps web, plugins IDE, cloud functions
Go	v1.6.1	4 700	Google	Moyen	Binaire statique	Haute performance, containers minimaux
Java	v2.0.0	3 500	Spring AI / VMware	Faible (annotations)	JVM + Spring Boot	Microservices enterprise, migration REST→MCP
Kotlin	v0.13.0	1 400	JetBrains	Très faible	JVM / Android	Nouveaux projets JVM, Android

 

FastMCP et les frameworks haut niveau changent-ils vraiment la donne ?

FastMCP : de la contribution communautaire au standard de fait

FastMCP a démarré comme un projet personnel de Jerrod Linderman (alias jlowin sur GitHub), avec un objectif simple : appliquer à MCP la même philosophie que FastAPI avait apportée aux API REST — des décorateurs Python, des types natifs, zéro configuration manuelle de schémas. Le projet a fonctionné à une vitesse remarquable. Son core v1 a été contribué et intégré dans le SDK officiel Python MCP maintenu par Anthropic. Aujourd’hui, from mcp.server.fastmcp import FastMCP fait partie du package mcp d’Anthropic lui-même.

Depuis, le projet a été transféré sous l’organisation PrefectHQ (la société derrière le framework d’orchestration Prefect). La v3.4.2 est sortie en juin 2026 avec 25 700 étoiles GitHub, dépassant le SDK Python officiel lui-même (23 400 étoiles). Il affiche environ un million de téléchargements par jour sur PyPI, et la majorité des serveurs MCP en production l’utilisent.

Comparaison directe : SDK bas niveau vs FastMCP

La différence se voit immédiatement sur un exemple minimal. Voici le même tool « hello » en API bas niveau (déjà vu dans la section Python) et en FastMCP, côte à côte :

SDK bas niveau (26 lignes) :

from mcp.server import Server
from mcp.server.stdio import stdio_server
import mcp.types as types

server = Server("demo")

@server.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="hello",
            description="Retourne un message de bienvenue",
            inputSchema={"type": "object", "properties": {}},
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "hello":
        return [types.TextContent(type="text", text="Hello, World!")]

async def main():
    async with stdio_server() as (read, write):
        await server.run(read, write, server.create_initialization_options())

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

FastMCP via SDK officiel (8 lignes) :

from mcp.server.fastmcp import FastMCP  # inclus dans pip install mcp

mcp = FastMCP("demo")

@mcp.tool()
def hello() -> str:
    """Retourne un message de bienvenue"""
    return "Hello, World!"

if __name__ == "__main__":
    mcp.run()

FastMCP infère le schéma JSON depuis la signature de la fonction et la docstring. Le type de retour str indique au SDK que le tool renvoie du texte. Les types Python natifs (str, int, list[dict]), les modèles Pydantic et les classes dataclass sont tous convertis automatiquement en JSON Schema. La gestion du transport STDIO est absorbée par mcp.run().

Sur un tool avec paramètres, l’avantage devient encore plus visible :

from mcp.server.fastmcp import FastMCP
from pydantic import BaseModel, Field

mcp = FastMCP("mon-serveur")

class QueryParams(BaseModel):
    table: str = Field(description="Nom de la table à interroger")
    limit: int = Field(default=10, description="Nombre maximum de résultats")
    filter: str | None = Field(default=None, description="Filtre SQL WHERE optionnel")

@mcp.tool()
def query_database(params: QueryParams) -> list[dict]:
    """Interroge une table de la base de données"""
    # logique métier ici
    return [{"id": 1, "name": "exemple"}]

FastMCP génère automatiquement le JSON Schema de QueryParams depuis le modèle Pydantic, avec les valeurs par défaut, les types optionnels et les descriptions issues des champs Field(description=...). L’hôte MCP (Claude Desktop, Claude Code CLI) voit un tool bien documenté avec des paramètres validés. Sans FastMCP, ce schéma JSON serait écrit manuellement dans inputSchema — un objet imbriqué de 15 à 20 lignes supplémentaires.

FastMCP v1 (SDK officiel) vs FastMCP v3 standalone : quelle différence en pratique ?

Deux versions coexistent. La v1, intégrée dans le SDK officiel (import from mcp.server.fastmcp import FastMCP), est stable mais « gelée » : elle reçoit des correctifs de sécurité mais peu de nouvelles fonctionnalités. La v3 standalone (pip install fastmcp, organisation PrefectHQ) va beaucoup plus loin :

• Client MCP intégré : FastMCP v3 inclut un client Python permettant de consommer des serveurs MCP depuis du code Python, sans passer par un hôte comme Claude Desktop.
• Composition de serveurs : plusieurs serveurs MCP peuvent être montés sous un même serveur parent, avec routage automatique des tools.
• Proxying : FastMCP v3 peut se comporter comme un proxy MCP, redirigeant les requêtes vers d’autres serveurs. Utile pour la mise en cache, le rate-limiting, ou l’ajout de middleware.
• Intégration OpenAPI/FastAPI : un serveur FastAPI existant peut être converti automatiquement en serveur MCP en passant l’objet app à FastMCP. Chaque route FastAPI devient un tool MCP.

Pour les exemples de la série MCP-101, j’utilise l’import SDK officiel (from mcp.server.fastmcp import FastMCP) : aucune dépendance supplémentaire, installation avec pip install mcp ou uv add mcp, et le code est valide sur toute installation MCP standard. À partir de la partie 7, qui couvre les serveurs MCP exposés en HTTP avec un client Python, on mettre en oeuvre pip install fastmcp pour accéder au client intégré.

Google ADK et MCPToolset : piloter des agents avec des serveurs MCP existants

Google ADK (Agent Development Kit, v1.0 stable, annoncé en production-ready en mai 2026) adopte une approche différente de FastMCP : l’ADK n’aide pas à créer des serveurs MCP — il aide à consommer des serveurs MCP existants dans des pipelines d’agents complexes. C’est un framework d’orchestration d’agents, pas un SDK de serveur.

La classe MCPToolset est l’interface centrale. Lorsque vous l’ajoutez à un agent ADK, elle établit la connexion au serveur MCP, liste ses tools via tools/list, convertit les schémas JSON Schema en BaseTool ADK, et proxifie les appels de l’agent vers le serveur MCP de façon transparente :

from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset, StdioServerParameters

agent = LlmAgent(
    name="assistant-code",
    model="gemini-2.0-flash",
    tools=[
        MCPToolset(
            connection_params=StdioServerParameters(
                command="python",
                args=["mon_serveur_mcp.py"]
            )
        )
    ]
)

ADK est l’option à considérer quand votre projet est un pipeline multi-agents plutôt qu’un serveur MCP isolé : orchestration de plusieurs agents spécialisés, routage de tâches, gestion de mémoire partagée entre agents. MCP y joue le rôle de couche d’outillage standardisée — n’importe quel serveur MCP de la communauté peut être branché dans un agent ADK via MCPToolset. La relation entre MCP et le protocole A2A (Agent-to-Agent), qui gère la communication entre agents dans un pipeline, fait l’objet d’un article séparé sur ce site.

LangChain MCP Adapters : le pont pour les stacks existantes

Si votre stack utilise LangChain ou LangGraph, le package langchain-mcp-adapters (maintenu par l’organisation langchain-ai, v0.3.0 en juin 2026) permet de connecter un agent LangGraph à n’importe quel serveur MCP sans réécriture :

from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.prebuilt import create_react_agent

async with MultiServerMCPClient({
    "filesystem": {
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/docs"]
    },
    "mon-serveur": {
        "command": "python",
        "args": ["mon_serveur_mcp.py"]
    }
}) as client:
    tools = await client.get_tools()
    agent = create_react_agent(model, tools)
    result = await agent.ainvoke({"messages": [("user", "Résume les fichiers du répertoire docs")]})

L’adapter convertit les tools MCP en BaseTool LangChain. Toute la logique de découverte (tools/list) et d’appel (tools/call) MCP reste transparente pour votre agent. C’est la solution de moindre friction pour les équipes qui ont investi dans LangChain mais veulent accéder aux serveurs MCP de la communauté — notamment les serveurs référencés dans le registre officiel modelcontextprotocol ou les serveurs populaires comme Brave Search, GitHub, Slack et Notion.

Une note de mise en garde : langchain-mcp-adapters est un adaptateur de consommation, pas un SDK de création. Si vous voulez créer un serveur MCP depuis LangChain, vous revenez au SDK Python ou à FastMCP. Les deux approches sont complémentaires.

Quel langage et quel SDK choisir pour votre serveur MCP ?

La question mérite des réponses directes par cas d’usage…. : voici ma lecture de l’état de l’art en juin 2026.

Python + FastMCP : le choix par défaut pour 90 % des projets

Si vous êtes développeur Python et que vous n’avez pas de contrainte technique imposant un autre langage, Python + FastMCP est le bon choix. Pas par défaut de mieux mais pour trois raisons concrètes.

Première raison : l’écosystème IA. Python dispose des bibliothèques les plus matures et les plus directement utiles pour les projets MCP : NumPy et Pandas pour la manipulation de données, scikit-learn et PyTorch pour les modèles, Hugging Face Transformers pour les LLMs locaux, boto3 pour AWS, le client Python Ollama, LangChain, LlamaIndex, et des dizaines d’autres. Un serveur MCP Python peut appeler n’importe laquelle en un import. En Go ou TypeScript, vous créez des bindings pour des fonctionnalités que Python propose depuis des années.

Deuxième raison : la vitesse de développement. FastMCP réduit un serveur fonctionnel à une dizaine de lignes. Avec uv comme gestionnaire de paquets, l’environnement est reproductible et installé en quelques secondes sur n’importe quelle machine. Pour prototyper un tool qui appelle une API externe, analyse un fichier CSV ou génère une image, le cycle « écrire, tester dans Claude Desktop, itérer » est extrêmement court.

Troisième raison : la communauté et la documentation. Le SDK Python est le plus documenté, les exemples de serveurs MCP sur GitHub sont majoritairement en Python ou en TypeScript, et quand vous cherchez comment implémenter un pattern spécifique (resources, prompts, sampling, OAuth), quelqu’un l’a déjà résolu en Python et a publié le code. La partie 2 de cette série recense des dizaines de serveurs MCP communautaires, presque tous en Python ou TypeScript.

Go : quand les performances et le déploiement sont des contraintes réelles

Go est le bon choix dans trois situations précises. La première : votre serveur MCP traite des volumes importants de requêtes concurrentes et la latence doit rester prévisible. Si vous exposez un serveur MCP en HTTP à plusieurs agents simultanément (architecture multi-agent, serveur MCP partagé entre équipes), les goroutines gèrent la concurrence nativement avec un overhead très faible par rapport aux threads Python ou aux workers asyncio.

La deuxième situation : vous déployez dans un container minimaliste où vous ne voulez pas embarquer un runtime Python de 50 à 100 MB. Un binaire Go compilé de 10 MB tourne sur une image Alpine Linux sans aucune dépendance runtime. Pour les déploiements Kubernetes à grande échelle ou les Lambda functions AWS où chaque mégaoctet a un coût, c’est significatif.

La troisième situation : votre équipe est Go-first et a déjà des services Go en production avec un outillage de monitoring, de test et de CI/CD établi. Rester dans le même langage réduit la charge cognitive et évite de maintenir deux chaînes d’outils. Le co-maintien de Google signale que le SDK Go va continuer à évoluer au même rythme que la spécification.

TypeScript : pour l’intégration dans une application web ou un plugin d’éditeur

TypeScript s’impose quand votre serveur MCP est un composant d’une application Node.js existante. L’intégration avec Express, Hono ou Fastify est native, les middlewares d’authentification et de rate-limiting existants sont réutilisables, et les outils de build (esbuild, tsx, tsc) sont déjà en place. TypeScript est aussi le choix naturel pour les extensions de VS Code, les plugins Cursor et Windsurf, qui s’exécutent dans le processus Node.js de l’éditeur.

La compatibilité multi-runtime est un avantage supplémentaire : un même serveur MCP TypeScript peut tourner en Deno Deploy pour une latence globale réduite, ou en Bun pour des performances I/O supérieures, sans changer une ligne de code si vous évitez les APIs Node.js spécifiques.

Java/Kotlin : pour les projets JVM

Si votre organisation utilise Spring Boot pour ses microservices, le SDK Java Spring AI intègre MCP dans l’écosystème Spring avec des annotations familières aux développeurs Java. Les outils de monitoring (Micrometer, Spring Boot Actuator), la gestion de configuration centralisée (Spring Cloud Config) et Spring Security s’appliquent à votre serveur MCP exactement comme à n’importe quel autre bean Spring. La migration d’un service REST Spring Boot existant vers MCP se fait souvent sans refactoring majeur.

Kotlin est la variante recommandée pour les nouveaux projets JVM. La sécurité null intégrée dans le système de types permet d’éviter de nombreux bugs qui peuvent survenir plus facilement en Java. Les coroutines Kotlin s’intègrent naturellement avec le modèle async de MCP. JetBrains co-maintient le SDK, ce qui garantit sa compatibilité avec les nouvelles versions de Kotlin et d’IntelliJ.

Tableau décisionnel

Situation	Recommandation	Raison principale
Nouveau projet, pas de contrainte de langage	Python + FastMCP	Écosystème IA, vitesse de dev, communauté
Volume de requêtes élevé, latence critique	Go + go-sdk	Goroutines légères, binaire statique
Application Node.js ou plugin d’éditeur existant	TypeScript SDK	Réutilisation middleware, compatibilité multi-runtime
Microservices Spring Boot en place	Java SDK (Spring AI)	Annotations familières, intégration Spring native
Nouveau projet JVM ou Android	Kotlin SDK	Sécurité null, coroutines, JetBrains co-maintenu
Pipeline multi-agents Google ADK	ADK MCPToolset	Orchestration agents, consommateur (pas créateur) de MCP
Stack LangChain/LangGraph existante	langchain-mcp-adapters	Zéro réécriture, bridge transparent vers serveurs MCP

 

Conclusion : Python + FastMCP comme socle de MCP-101

Le paysage des SDKs MCP est plus riche qu’il n’y paraît à première vue. Dix langages, cinq mainteneurs industriels différents (Anthropic, Google, Microsoft, JetBrains, VMware Broadcom), et des frameworks haut niveau qui ont redéfini l’expérience développeur en quelques mois. C’est la marque d’un protocole qui a trouvé sa place dans l’industrie.

Le choix de Python + FastMCP pour la suite de cette série n’est pas arbitraire. C’est le chemin de moindre friction pour 90 % des développeurs qui veulent exposer de l’outillage à un agent IA : écosystème de bibliothèques inégalé, FastMCP qui supprime le boilerplate technique, et une communauté qui a déjà résolu la plupart des problèmes d’intégration. L’article 8 reviendra sur Go pour construire le même serveur en comparaison directe — même fonctionnalités, deux langages, mesure concrète des différences.

Avant d’écrire la première ligne de code d’un serveur MCP réel, la prochaine partie de la série couvre la sécurité. MCP introduit des vecteurs d’attaque que les scanners de sécurité classiques ne détectent pas encore : prompt injection via les descriptions de tools, exfiltration de credentials, escalade de privilèges entre tools d’un même serveur. Ces risques existent indépendamment du langage choisi — un tool malveillant reste malveillant qu’il soit écrit en Python, Go ou TypeScript. La partie 4 pose les bases de sécurité avant qu’on touche au premier décorateur @mcp.tool().

FAQ

FastMCP standalone (pip install fastmcp) et FastMCP dans le SDK officiel (mcp.server.fastmcp) sont-ils interchangeables ?

L’API de base est compatible : @mcp.tool(), @mcp.resource() et @mcp.prompt() fonctionnent identiquement dans les deux versions. La différence est dans les fonctionnalités avancées : le client MCP Python, la composition de serveurs, le proxying et l’intégration OpenAPI/FastAPI sont uniquement dans FastMCP v3 standalone. Pour les exemples de cette série jusqu’à la partie 6, l’import SDK officiel suffit. La partie 7 (client Python + tests d’intégration) passe à pip install fastmcp.

Peut-on connecter des serveurs MCP de langages différents au même agent ?

Oui, sans contrainte. Un agent Claude Desktop peut se connecter simultanément à un serveur Python, un serveur Go et un serveur TypeScript. La configuration dans claude_desktop_config.json liste simplement les commandes de démarrage de chaque serveur, et l’hôte MCP gère les connexions en parallèle via STDIO ou HTTP. Le protocole JSON-RPC 2.0 est le dénominateur commun — le langage d’implémentation est invisible pour l’hôte.

Le SDK Python MCP fonctionne-t-il avec des modèles autres que Claude ?

Le SDK Python implémente le protocole MCP, pas l’API Claude. N’importe quel client MCP peut se connecter à un serveur Python : Claude Desktop, Claude Code CLI, Gemini CLI, Cursor, Windsurf, Continue, Cline. Depuis qu’OpenAI a adopté MCP en mars 2025, les outils de l’écosystème OpenAI supportent également le protocole. Un serveur MCP que vous écrivez en Python est accessible à tout agent compatible MCP, quel que soit le modèle derrière.

Faut-il Docker pour déployer un serveur MCP Python ?

Non pour le développement local. Un serveur MCP Python en mode STDIO peut tourner directement dans un virtualenv géré par uv, déclaré dans la configuration de votre client MCP (claude_desktop_config.json pour Claude Desktop, .mcp.json pour Claude Code CLI). Docker est utile si vous voulez déployer le serveur en mode HTTP dans un environnement cloud ou Kubernetes, ou si vous souhaitez isoler les dépendances de façon stricte pour plusieurs projets sur la même machine.

Pourquoi Go et TypeScript ont-ils moins d’étoiles GitHub que FastMCP ?

FastMCP (25 700 étoiles) dépasse les SDKs officiels Go (4 700) et TypeScript (12 700) parce qu’il résout un problème de developer experience immédiatement visible : comparer les exemples de code bas niveau et FastMCP suffit à convaincre. Les SDKs officiels accumulent des étoiles de développeurs qui utilisent MCP dans un langage spécifique par contrainte professionnelle — une audience plus petite. Ce n’est pas un signal de qualité ou de support : le SDK Go est co-maintenu par Google, le SDK TypeScript par Anthropic, les deux sont activement développés.

C et C++ ont-ils un SDK MCP officiel ?

Non. Aucun SDK MCP officiel n’existe pour C ou C++ à ce jour. Les deux langages sont absents de l’organisation modelcontextprotocol, malgré leur place dans le top 5 TIOBE. La communauté cible de MCP — développeurs d’agents IA, d’outillage LLM, d’applications de productivité — code majoritairement en Python, TypeScript et Go. C et C++ peuvent implémenter MCP en parsant JSON-RPC 2.0 manuellement (la spécification est publique), mais sans SDK officiel pour absorber le boilerplate. Si votre projet est en C++, la voie la plus pragmatique reste d’exposer votre logique via un binding Python ou un microservice Go qui parle MCP.