Squelette de serveur FastMCP

Les SDK Python et TypeScript permettent tous deux de produire un serveur MCP fonctionnel en moins de 30 lignes. Cette note couvre le squelette minimal pour chacun, ainsi que la façon de connecter le serveur à un client. L’extension du squelette avec des outils supplémentaires suit le même pattern que l’exemple initial.

Exemple Python FastMCP

Créez un fichier nommé server.py :

from mcp.server.fastmcp import FastMCP

# Initialiser le serveur avec un nom
mcp = FastMCP("DataEngineering")

@mcp.tool()
def query_database(query: str, database: str = "production") -> str:
    """Exécute une requête SQL contre la base de données spécifiée.

    Args:
        query: La requête SQL à exécuter
        database: Nom de la base de données cible (par défaut : production)

    Returns:
        Résultats de la requête sous forme de texte formaté
    """
    # Dans une implémentation réelle, vous vous connecteriez ici à votre base de données
    return f"Query executed on {database}: {query}"

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

C’est tout. Un serveur MCP fonctionnel.

Le décorateur @mcp.tool() effectue automatiquement plusieurs opérations :

Enregistre la fonction comme outil MCP
Extrait la signature de la fonction pour construire le schéma JSON des entrées
Utilise la docstring comme description de l’outil que l’IA voit
Gère toute la sérialisation JSON-RPC et la communication protocolaire

Exécuter le serveur :

uv run server.py

Le serveur commence à écouter sur stdin/stdout pour les messages du protocole MCP. Vous ne verrez aucune sortie — c’est normal. Le serveur attend qu’un client se connecte. Utilisez MCP Inspector pour interagir avec lui.

Exemple TypeScript McpServer

Créez server.ts :

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

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

server.registerTool(
  "query_database",
  {
    description: "Execute a SQL query against the specified database",
    inputSchema: {
      query: z.string().describe("The SQL query to execute"),
      database: z.string().default("production").describe("Target database name"),
    },
  },
  async ({ query, database }) => {
    // Dans une implémentation réelle, connectez-vous ici à votre base de données
    return {
      content: [{ type: "text", text: `Query executed on ${database}: ${query}` }],
    };
  }
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main();

Compiler et exécuter :

npx tsc server.ts
node server.js

La version TypeScript est plus verbeuse — vous définissez explicitement le schéma d’entrée avec les types Zod, et la valeur de retour doit être encapsulée dans le format de contenu MCP. Le compromis est une meilleure sécurité de type et des définitions de schéma explicites que votre IDE peut valider.

Pourquoi le transport stdio

Les deux exemples utilisent le transport stdio, ce qui signifie que le serveur communique via les flux d’entrée/sortie standard. C’est la valeur par défaut pour le développement local parce que :

Aucune configuration réseau requise
Le client démarre le serveur comme sous-processus
La communication se fait via des pipes, pas des sockets
Les identifiants restent dans les variables d’environnement, jamais sur le réseau
Chaque client obtient sa propre instance de serveur (isolation des processus)

stdio est idéal pour les applications de bureau comme Claude Desktop ou Cursor, et pour le développement avec Claude Code. Pour un déploiement en production avec plusieurs clients, vous passeriez au transport HTTP — mais commencez par stdio.

Connexion à un client

Une fois le serveur lancé, vous devez pointer un client vers lui.

Pour Claude Desktop, ajoutez à votre claude_desktop_config.json :

{
  "mcpServers": {
    "my-data-server": {
      "command": "uv",
      "args": ["run", "/path/to/server.py"],
      "env": {
        "DATABASE_URL": "postgresql://localhost/analytics"
      }
    }
  }
}

Pour Claude Code :

claude mcp add my-data-server -- uv run /path/to/server.py

La configuration du client indique à l’application hôte comment démarrer le processus serveur et quelles variables d’environnement passer. L’hôte démarre le serveur, effectue le handshake d’initialisation MCP, découvre les outils disponibles, et à partir de là l’IA peut les invoquer pendant les conversations.

Du squelette au vrai serveur

Le squelette est intentionnellement trivial. Un vrai serveur remplace l’implémentation factice par une logique métier réelle — connexion aux bases de données, appels d’API, interrogation des systèmes internes. L’insight clé est que la couche MCP (décorateurs, schémas, transport) reste identique. Vous ne changez que ce qui se passe dans le corps de la fonction.

Une progression courante :

Commencer avec le squelette, vérifier qu’il fonctionne avec MCP Inspector
Ajouter un vrai outil qui se connecte à votre système réel
Tester avec Inspector, puis avec Claude Desktop ou Claude Code
Ajouter d’autres outils au fur et à mesure que vous découvrez ce dont l’IA a besoin
Affiner les descriptions et les schémas en fonction de la façon dont l’IA utilise les outils

La note MCP Tool Design Patterns couvre comment concevoir des outils qui fonctionnent bien — bonnes descriptions, sorties structurées, entrées validées. La note MCP Server Project Setup couvre la structure complète du projet pour un serveur prêt pour la production.