FastMCP ou MCP SDK : quel framework Python choisir ?

Vous copiez from mcp.server.fastmcp import FastMCP depuis un tutoriel dans un projet neuf, vous l’exécutez, et Python vous répond par un ModuleNotFoundError. Rien ne cloche dans votre installation. Le SDK officiel a renommé cette classe, le projet FastMCP autonome a poursuivi son chemin de son côté, et les deux bibliothèques partagent aujourd’hui un nom, une couche protocolaire et beaucoup de développeurs désorientés.

Voici la réponse courte. En octobre 2026, le paquet officiel mcp est en version 2.3.0 et le paquet autonome fastmcp en version 4.0.11. Choisissez FastMCP si vous voulez la composition de serveurs, le proxy, l’import OpenAPI, des fournisseurs d’authentification intégrés et un client de test en processus. Choisissez le SDK MCP officiel si vous voulez l’arbre de dépendances le plus léger, un contrôle direct sur les primitives du protocole et aucun framework supplémentaire entre votre code et la spécification.

💡 Verdict rapide : si vous construisez un serveur Model Context Protocol que de vrais utilisateurs vont solliciter et que vous hésitez, commencez par FastMCP. Pour un serveur simple, passer plus tard au SDK officiel représente une modification de cinq minutes. Le chemin inverse oblige à reconstruire des fonctionnalités que FastMCP vous offrait d’emblée.

Pourquoi deux bibliothèques portent le même nom

Comment FastMCP s’est retrouvé dans le SDK

Jeremiah Lowin a conçu FastMCP pour que l’écriture d’un serveur MCP ressemble à l’écriture d’une fonction Python ordinaire. Cette API de haut niveau a été jugée suffisamment bonne pour que le SDK Python officiel d’Anthropic l’intègre en 2024 sous le nom FastMCP 1.0, hébergé à mcp.server.fastmcp. Le projet autonome, lui, n’a jamais cessé. Il a continué à sortir des versions sous son propre nom de paquet, a atteint la version 3.0 GA le 18 février 2026, et est passé d’un compte GitHub personnel au dépôt PrefectHQ/fastmcp lorsque Prefect l’a adopté comme infrastructure centrale.

Aujourd’hui, il est maintenu par Jeremiah Lowin et Nate Nowack sous licence Apache-2.0. Le projet affirme alimenter environ 70 % des serveurs MCP, tous langages confondus, un chiffre auto-déclaré qu’il faut prendre avec précaution.

Ce qui a changé avec le SDK v2

Le SDK v2 a officialisé la séparation. La classe FastMCP incluse dans le paquet s’appelle désormais MCPServer, et l’ancien chemin d’import a été purement supprimé :

# SDK v1 (bundled FastMCP, gone in v2)
from mcp.server.fastmcp import FastMCP

# SDK v2
from mcp.server import MCPServer

# Standalone FastMCP
from fastmcp import FastMCP

Copier le prompt

Si vous avez encore besoin de l’ancien comportement, la branche v1 est en mode maintenance. Installez-la avec uv add "mcp[cli]<2".

Vous ne choisissez pas entre deux implémentations concurrentes du protocole. FastMCP 4 repose sur la même couche protocolaire du SDK v2, la vraie question est donc la quantité de framework que vous voulez placer par-dessus.

Côte à côte : la comparaison rapide

Voici comment se positionnent les deux solutions sur les critères qui tranchent la plupart des projets :

Les chiffres de taille d’installation proviennent d’un test comparatif publié le 5 octobre 2026. Vos résultats varieront selon la plateforme et les extras installés.

Un serveur minimal dans les deux bibliothèques

Le code du premier jour est presque identique. Dans les deux bibliothèques, les annotations de type deviennent du JSON Schema et les docstrings deviennent les descriptions des outils. Voici la version du SDK officiel :

from mcp.server import MCPServer

mcp = MCPServer("Demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"

Copier le prompt

Et la version FastMCP :

from fastmcp import FastMCP

mcp = FastMCP("Demo")

@mcp.tool
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"

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

Copier le prompt

Avec l’extra cli du SDK, vous pouvez essayer la première avec mcp dev server.py. La seconde fonctionne avec un simple python server.py.

Petites différences de syntaxe qui piègent

La plupart des bugs de migration viennent de détails de ce genre :

• Parenthèses : le MCPServer du SDK exige @mcp.tool(). Un simple @mcp.tool lève une TypeError. FastMCP accepte les deux.
• Nom du transport : le SDK l’appelle "streamable-http". FastMCP l’appelle "http".
• Paramètres de transport : dans le SDK v2, l’hôte et le port ont quitté le constructeur pour rejoindre l’appel run().
• Propriétés du contexte : ctx.mcp_server dans le SDK devient ctx.fastmcp dans FastMCP, et ctx.log(level, data) devient ctx.log(message, level=...).

Ce que le SDK officiel fait le mieux

Un socle de dépendances plus léger

Le paquet officiel est l’installation la plus légère. Selon les mesures d’octobre 2026, mcp 2.3.0 ajoute 36 paquets et environ 41 Mo dans site-packages, tandis que fastmcp 4.0.11 en ajoute 66 et environ 65 Mo. Cet écart est le prix des extras : fournisseurs d’authentification, outillage OpenAPI, proxy et bibliothèque cliente.

Pourquoi cela compte en pratique :

• Moins de paquets à auditer lorsqu’une équipe sécurité examine chaque dépendance transitive.
• Images de conteneurs plus petites pour les serveurs qui tournent en de nombreuses petites répliques.
• Moins de surface de mise à jour quand une vulnérabilité touche du code que votre serveur n’utilise jamais.

Le temps d’import à froid est un argument plus faible. Les mesures ont beaucoup varié d’une exécution à l’autre sur une même machine : ne choisissez donc pas une bibliothèque pour quelques centaines de millisecondes de démarrage.

Contrôle direct du protocole

Le SDK officiel conserve une classe bas niveau Server à côté de la classe conviviale MCPServer. Dans la v2, chaque gestionnaire suit une seule forme, async (ctx, params) -> result, sans décorateurs ni enveloppement automatique :

from mcp.server import Server, ServerRequestContext
from mcp.types import CallToolRequestParams, CallToolResult, TextContent

async def call_tool(ctx: ServerRequestContext, params: CallToolRequestParams) -> CallToolResult:
    return CallToolResult(content=[TextContent(type="text", text="ok")])

server = Server("Bookshop", on_call_tool=call_tool)

Copier le prompt

Vous écrivez vous-même le traitement des requêtes, ce qui demande plus de code mais donne plus de pouvoir. Le SDK v2 ajoute aussi des outils de niveau protocole, que vous atteignez ici le plus directement :

• Resolve et Elicit : un paramètre d’outil rempli par une fonction que vous écrivez, invisible pour le modèle, capable de s’arrêter pour poser une question à l’utilisateur en pleine exécution.
• Client de première classe : from mcp import Client négocie la connexion à votre place, sans ClientSession imbriqué ni initialisation manuelle.
• OpenTelemetry intégré : chaque requête est tracée par le middleware.
• Mise en cache des réponses : cache_hints côté serveur et prise en charge du cache côté client.
• Prise en charge de deux protocoles : un seul déploiement peut servir des clients des révisions 2025 et 2026 du protocole.

La révision 2026-07-28 du protocole supprime la poignée de main initialize et les identifiants de session sur Streamable HTTP, ce qui permet à un répartiteur de charge classique de distribuer les requêtes entre des répliques sans état. Les deux bibliothèques reposent sur la même couche protocolaire, mais c’est dans le SDK que vous la configurez directement.

Ce que FastMCP ajoute par-dessus

L’argument de FastMCP est simple : les éléments que vous finissez par écrire autour d’un serveur sont déjà écrits.

Composition et proxy

FastMCP peut monter un serveur à l’intérieur d’un autre, si bien qu’un serveur weather et un serveur billing peuvent vivre dans des modules séparés tout en apparaissant comme un seul point d’accès, avec des préfixes de chemin. Il peut aussi faire office de proxy pour un serveur MCP tiers, ce qui vous permet d’envelopper un serveur existant avec votre propre authentification. Le SDK officiel n’intègre aucune de ces deux fonctions.

La version 3.0 a reconstruit cette fonction autour de fournisseurs. Les outils n’ont plus à se trouver dans un seul fichier : un FileSystemProvider les découvre dans un répertoire et les recharge lorsqu’ils changent.

Import OpenAPI et fournisseurs d’authentification

Si votre entreprise exploite déjà une API REST, OpenAPIProvider transforme une spécification OpenAPI ou une application FastAPI en outils MCP, sans réécrire chaque point de terminaison à la main.

L’authentification bénéficie du même traitement. FastMCP regroupe les trois paramètres distincts du SDK (token_verifier, auth_server_provider et auth=AuthSettings) en un seul fournisseur auth=, avec une prise en charge intégrée de JWT, OAuth, GitHub et Google. Ajouter une connexion GitHub devient un choix de configuration plutôt qu’un projet de week-end. Les outils peuvent aussi demander de l’aide au LLM du client via ctx.sample().

Tester sans réseau

Le Client de FastMCP accepte directement un objet serveur, si bien qu’un test s’exécute en processus, sans ports, sans sous-processus et sans délais d’attente capricieux :

import asyncio
from fastmcp import Client, FastMCP

mcp = FastMCP("Demo")

@mcp.tool
def add(a: int, b: int) -> int:
    return a + b

async def main():
    async with Client(mcp) as client:
        result = await client.call_tool("add", {"a": 2, "b": 3})
        print(result.data)  # 5

asyncio.run(main())

Copier le prompt

Le test en processus fait partie des avantages que mettent en avant les notes de migration de FastMCP lui-même, et il permet de construire facilement une suite pytest rapide.

Les limites de chaque option

Aucun des deux choix n’est gratuit. Les deux entraînent une facture qui arrive plus tard. Les équipes qui choisissent FastMCP paient en évolutions fréquentes et en nombre plus élevé de dépendances, celles qui choisissent le SDK paient en code qu’elles écrivent elles-mêmes.

FastMCP évolue vite

FastMCP est passé de la version 3.0 GA de février 2026 à la 4.0.11 d’octobre : attendez-vous donc à voir les versions majeures arriver rapidement. Fixez la plage de versions dans le fichier de votre projet, par exemple fastmcp>=4,<5, et lisez les notes de version avant chaque mise à jour.

Il installe aussi environ 30 paquets de plus que le SDK. Prefect propose une plateforme hébergée, Horizon, pour le déploiement et le contrôle d’accès. La bibliothèque elle-même est sous licence Apache-2.0 et fonctionne partout où vous pouvez exécuter Python.

Le SDK v2 casse l’ancien code

Si vous migrez un serveur v1, prévoyez suffisamment de temps. Les notes de version du SDK v2 listent ces changements incompatibles :

• Le transport WebSocket (mcp[ws]) a été supprimé.
• L’API Tasks expérimentale a été supprimée et déplacée vers une extension.
• McpError devient MCPError, et une MCPError levée dans un outil devient une erreur de protocole que le modèle ne voit jamais.
• Le paramètre mount_path a disparu.
• Les gestionnaires synchrones s’exécutent désormais sur un thread de travail au lieu de la boucle d’événements.
• Sur Streamable HTTP, le lifespan s’exécute une fois au démarrage, et non une fois par session.
• Le client HTTP est passé de httpx à httpx2.

Bien choisir en quelques minutes

Inutile de chercher parmi toutes les fonctionnalités : associez votre situation à ce tableau :

Imaginez une équipe de trois personnes qui veut qu’un assistant IA lise son API interne de commandes. Avec une spécification OpenAPI déjà en place, OpenAPIProvider supprime l’essentiel du travail endpoint par endpoint, et le fournisseur auth= unique gère la connexion de l’entreprise. Imaginez maintenant une équipe plateforme qui construit une passerelle auditée et doit passer une revue stricte des dépendances. Cette équipe se tourne vers le SDK et gagne les gestionnaires bas niveau dont elle a besoin. Aucune des deux équipes ne s’est trompée : elles sont parties de contraintes différentes.

Choisissez FastMCP si

• Vous livrez quelque chose auquel les utilisateurs devront se connecter.
• Vous voulez un seul paramètre auth= au lieu de trois.
• Vous prévoyez de passer d’un serveur à plusieurs.
• Vous préférez le décorateur @mcp.tool, plus court, et des tests en processus rapides.

Choisissez le SDK officiel si

• Vous voulez le moins de dépendances et l’image la plus petite.
• Vous devez gérer vous-même les requêtes et les réponses brutes.
• Votre équipe adopte l’implémentation de référence du projet MCP.
• Vous voulez OpenTelemetry et la prise en charge de Resolve ou Elicit directement depuis le paquet de base.

Passer de l’un à l’autre plus tard

Les deux bibliothèques partagent une couche protocolaire, donc le passage de l’une à l’autre est surtout mécanique. Pour aller du SDK vers FastMCP, cela ressemble à ceci :

- from mcp.server import MCPServer
+ from fastmcp import FastMCP

- mcp = MCPServer("orders")
+ mcp = FastMCP("orders")

- @mcp.tool()
+ @mcp.tool

Copier le prompt

Remplacez ensuite "streamable-http" par "http" dans votre appel run(), renommez ctx.mcp_server en ctx.fastmcp, et fusionnez vos trois paramètres d’authentification en un seul fournisseur. Dans l’autre sens, annulez ces modifications et prévoyez de remplacer la composition, le proxy et l’import OpenAPI par votre propre code.

Lancez vos tests après chaque étape. Si vous les avez écrits avec un client en processus, la vérification complète ne prend que quelques secondes.

Construisez le vôtre avec PicassoIA

Un serveur MCP n’est utile qu’à la mesure de ce qui se trouve derrière ses outils. PicassoIA propose un connecteur MCP et une API pour développeurs couvrant la génération d’images, à l’édition d’images et à la génération de vidéos, si bien qu’un client comme Claude Desktop peut créer des visuels grâce à des outils que vous n’avez jamais eu à construire. Ces tâches sont asynchrones : vous en soumettez une, puis vous interrogez le résultat. Ce schéma soumettre-puis-interroger est aussi un bon modèle pour vos propres serveurs, avec un outil qui renvoie un identifiant de tâche et un second outil qui vérifie son statut.

Rédigez votre serveur sur PicassoIA

Vous pouvez demander à un LLM d’écrire la première version de l’une ou l’autre. Voici la voie rapide avec Claude Sonnet 5, un modèle conçu pour les tâches de programmation :

1. Ouvrez la page Claude Sonnet 5 sur PicassoIA.
2. Remplissez le champ Prompt obligatoire, par exemple : « Écrivez un serveur MCP en Python avec FastMCP, comportant deux outils, l’un qui additionne des nombres et l’autre qui récupère un résumé météo, ainsi qu’un fichier pytest utilisant le client en processus. »
3. Réglez effort : laissez-le sur low pour les petites modifications, ou augmentez-le pour un bug complexe réparti sur plusieurs fichiers.
4. Gardez max tokens à la valeur par défaut de 8 192 pour un fichier de serveur complet, et utilisez system prompt pour fixer une fois pour toutes un style de code.
5. Joignez une image si vous en avez une, comme une capture d’écran d’erreur, puis générez le code et collez-le dans votre projet.

Demandez les deux versions dans une seule requête et comparez-les vous-même. Si vous voulez un second avis sur le code, GPT 5.6 Sol est conçu pour les tâches de programmation complexes et fait un bon relecteur.

Une fois votre serveur en marche, donnez-lui quelque chose d’amusant à faire. Ouvrez PicassoIA, essayez les modèles d’image et de vidéo, et voyez ce que produisent quelques prompts bien rédigés. Reliez ensuite votre outil préféré à votre propre serveur MCP et laissez votre prochain projet créer ses propres visuels. Votre première image n’est qu’à un prompt de distance.