Comment contribuer a un serveur MCP open source en 7 etapes

Le Model Context Protocol (MCP) vient d etre transfere a la Linux Foundation sous l egide de l Agentic AI Foundation (AAIF). Avec 97 millions de telechargements SDK mensuels et des milliers de serveurs open source, MCP est devenu le standard de facto pour connecter les modeles d IA a des outils et des sources de donnees. Et l ecosysteme a besoin de contributeurs.

La bonne nouvelle : contribuer a un serveur MCP ne necessite pas d expertise en intelligence artificielle. Si vous savez ecrire une API REST, vous savez ecrire un serveur MCP. Le protocole est simple, bien documente, et les SDKs officiels (TypeScript et Python) font le gros du travail. Ce guide vous emmene de zero a votre premiere contribution mergee en 7 etapes concretes.

Etape 1 — Comprendre l architecture MCP (30 minutes suffisent)

Avant de toucher une ligne de code, prenez 30 minutes pour comprendre comment MCP fonctionne. Le protocole repose sur un modele client-serveur simple. Un client MCP (Claude, ChatGPT, un IDE, ou n importe quel programme) se connecte a un serveur MCP qui expose des capacites. Le client envoie des requetes, le serveur repond. C est aussi simple qu une API REST, mais avec un protocole standardise.

Un serveur MCP expose trois types de capacites :

Tools — des fonctions que le modele peut appeler. Exemples : search_database, create_issue, send_email. Chaque tool a un nom, une description, et un schema de parametres (JSON Schema). Quand le modele decide d appeler un tool, le client MCP envoie la requete au serveur qui execute la fonction et retourne le resultat.

Resources — des sources de donnees que le modele peut lire. Exemples : le contenu d un fichier, les resultats d une requete base de donnees, les metadonnees d un repository. Les resources sont identifiees par des URIs et peuvent etre statiques (lues une fois) ou dynamiques (mises a jour en temps reel via des subscriptions).

Prompts — des templates de prompts preconfigures que le serveur propose au client. Utiles pour guider les utilisateurs vers les bonnes facons d interagir avec les capacites du serveur. Par exemple, un serveur MCP pour GitHub pourrait proposer un prompt review_pull_request qui inclut les instructions optimales pour une review de code.

Le transport entre client et serveur se fait via stdio (pour les serveurs locaux) ou SSE/Streamable HTTP (pour les serveurs distants). Le protocole est base sur JSON-RPC 2.0, un standard simple et bien supporte. Si vous avez deja travaille avec des Language Server Protocol (LSP) dans les IDE, le modele mental est tres similaire.

Si vous savez ecrire un endpoint REST qui accepte du JSON et retourne du JSON, vous savez ecrire un serveur MCP. Le SDK fait tout le marshalling et la gestion du transport pour vous. Concentrez-vous sur la logique metier. — Sophie Laurent, Developpeuse open source senior

Etape 2 — Choisir un serveur MCP cible (ou en creer un)

Vous avez deux options : contribuer a un serveur existant ou creer un nouveau serveur. Pour une premiere contribution, nous recommandons de commencer par un serveur existant — le cadre est deja en place, et vous pouvez vous concentrer sur l ajout d une fonctionnalite.

Ou trouver des serveurs existants :

• Le repository officiel modelcontextprotocol/servers sur GitHub contient les serveurs de reference maintenus par la communaute MCP. C est le meilleur point de depart — les standards de qualite sont eleves et les reviews sont rapides.

• Le MCP Server Registry liste les serveurs communautaires. Filtrez par langage (TypeScript, Python) et par categorie (database, cloud, devtools) pour trouver un serveur qui correspond a votre expertise.

• Les GitHub Topics mcp-server et model-context-protocol indexent des centaines de serveurs. Cherchez ceux avec des issues good-first-issue ou help-wanted.

Criteres de choix : choisissez un serveur pour un outil ou service que vous utilisez deja. Si vous travaillez avec PostgreSQL au quotidien, contribuez au serveur MCP PostgreSQL. Si vous utilisez GitLab, contribuez au serveur MCP GitLab. Votre connaissance du service sous-jacent est votre avantage competitif — vous savez quels tools manquent et quels edge cases ne sont pas geres.

Option : creer un nouveau serveur. Si vous connaissez un service ou une API pour laquelle aucun serveur MCP n existe, c est une opportunite. Les APIs francaises et europeennes sont particulierement sous-representees : APIs d OVHcloud, Scaleway, Clever Cloud, des services publics francais (api.gouv.fr), ou des outils specifiques a l ecosysteme francophone. Creer le premier serveur MCP pour un de ces services vous positionne comme mainteneur de reference.

Etape 3 — Configurer l environnement de developpement

Une fois votre serveur cible choisi, configurez votre environnement local. La procedure est classique pour un projet open source, avec quelques specificites MCP.

Fork et clone. Forkez le repository du serveur sur votre compte GitHub, puis clonez-le localement. Ajoutez le repository original comme remote upstream pour pouvoir synchroniser plus tard.

Installez les dependances. Pour un serveur TypeScript : npm install ou pnpm install. Pour un serveur Python : creez un venv et installez avec pip install -e ".[dev]" ou uv sync. Verifiez que le SDK MCP est bien installe : @modelcontextprotocol/sdk pour TypeScript ou mcp pour Python.

Lancez le serveur en mode dev. La plupart des serveurs MCP se lancent avec npm run dev ou python -m server. Utilisez le MCP Inspector pour tester que le serveur repond correctement. L Inspector est un outil de debug officiel qui vous permet d envoyer des requetes et de visualiser les reponses en temps reel — c est votre meilleur ami pendant le developpement.

Configurez Claude Desktop (optionnel mais recommande). Si vous utilisez Claude, ajoutez votre serveur local dans le fichier de configuration claude_desktop_config.json. Cela vous permet de tester vos tools en conditions reelles — en parlant a Claude et en voyant comment il utilise vos outils. C est le moyen le plus fiable de valider l experience utilisateur de votre contribution.

Lancez les tests existants. Assurez-vous que la suite de tests passe avant de modifier quoi que ce soit. Si des tests echouent sur la branche main, c est un bug a signaler — et potentiellement une bonne premiere contribution.

Etape 4 — Contribuer un tool, une resource ou un prompt

C est le coeur de la contribution. La plupart des serveurs MCP existants ne couvrent qu une fraction des fonctionnalites de l API ou du service qu ils connectent. Votre contribution consiste a ajouter un tool, une resource ou un prompt manquant.

Ajouter un tool est la contribution la plus courante. Un tool MCP est une fonction avec un nom, une description, des parametres (definis en JSON Schema), et un handler qui execute la logique. Voici les bonnes pratiques :

• Nom clair et specifique. Utilisez le format action_object : list_issues, create_branch, search_documents. Evitez les noms generiques comme run ou execute.

• Description detaillee. La description du tool est ce que le modele IA lit pour decider quand l utiliser. Soyez precis : Lists all open issues in the specified repository, filtered by label and assignee. Returns issue title, number, body, and labels. Plus la description est precise, mieux le modele saura quand et comment utiliser votre tool.

• Schema de parametres strict. Definissez chaque parametre avec son type, sa description, et ses contraintes (required, enum, min/max). Un schema bien defini evite les erreurs d appel et ameliore l experience utilisateur. Utilisez des valeurs par defaut sensees pour les parametres optionnels.

• Gestion d erreurs robuste. Retournez des messages d erreur clairs quand un appel echoue — le modele IA a besoin de comprendre pourquoi pour adapter sa strategie. Distinguez les erreurs de parametres (corrigeables par le modele) des erreurs systeme (non corrigeables).

Ajouter une resource est utile quand le serveur doit exposer des donnees consultables : configuration, schemas, documentation. Les resources sont identifiees par des URIs et retournent du contenu texte ou binaire.

Ajouter un prompt est la contribution la plus sous-estimee. Les prompts aident les utilisateurs a utiliser le serveur de maniere optimale. Si vous remarquez que les utilisateurs posent souvent les memes questions ou font les memes erreurs avec un tool, creez un prompt qui les guide.

Etape 5 — Ecrire les tests et la documentation

Une contribution sans tests est une contribution qui ne sera pas mergee — du moins pas dans les serveurs serieux. Et une contribution sans documentation est une contribution que personne ne saura utiliser. Les deux sont non negociables.

Tests unitaires pour chaque tool. Testez les cas nominaux (appel correct avec parametres valides), les cas limites (parametres aux bornes, listes vides, strings tres longues), et les cas d erreur (parametres manquants, types invalides, service indisponible). Le SDK MCP fournit des helpers pour simuler un client dans vos tests. En TypeScript, utilisez vitest ou jest. En Python, pytest avec pytest-asyncio.

Tests d integration avec le MCP Inspector. Lancez votre serveur et testez manuellement chaque tool via l Inspector. Documentez les commandes et les resultats attendus. Certains projets incluent des tests d integration automatises qui lancent le serveur dans un conteneur Docker et envoient des requetes reelles.

Documentation du tool dans le README. Ajoutez une section pour votre tool dans le README du serveur. Incluez : le nom, la description, les parametres (avec exemples de valeurs), un exemple de requete/reponse, et les prerequis (cles API, permissions, etc.). La documentation est souvent plus impactante que le code lui-meme — c est elle qui determine si les utilisateurs adopteront votre tool.

Piege a eviter : ne mockez pas tout dans vos tests. Les tests qui ne testent que des mocks ne testent rien. Pour les appels API externes, utilisez des fixtures enregistrees (VCR pattern) ou un serveur de test local. L objectif est de garantir que votre tool fonctionne vraiment, pas qu il compile.

Etape 6 — Soumettre la pull request

Votre code est ecrit, teste, et documente. Il est temps de soumettre votre PR. Les serveurs MCP ont generalement des standards de qualite eleves — voici comment maximiser vos chances de merge rapide.

Branche propre et commits atomiques. Nommez votre branche clairement : feat/add-list-issues-tool ou fix/search-pagination-bug. Chaque commit doit representer un changement logique unique. Faites un rebase sur upstream/main avant de pusher.

Description de PR structuree. Incluez : le contexte (quel probleme ca resout ou quelle fonctionnalite ca ajoute), le changement (ce que vous avez fait et pourquoi), les tests (comment verifier que ca marche), et la documentation (ce que vous avez mis a jour). Si votre PR ajoute un tool, incluez un exemple d utilisation avec le MCP Inspector ou Claude Desktop.

CI verte obligatoire. Verifiez que tous les checks CI passent avant de demander une review. Linter, type checking, tests unitaires, build — tout doit etre vert. Si un check echoue pour une raison qui n est pas liee a votre changement, signalez-le dans la PR.

Reagissez rapidement aux reviews. Les projets MCP actifs reviewent generalement les PR dans les 48 a 72 heures. Quand vous recevez des commentaires, repondez et corrigez dans les 24 heures si possible. Les PR inactives sont fermees apres quelques semaines — ne laissez pas la votre mourir.

Etape 7 — Publier et promouvoir votre serveur

Si vous avez cree un nouveau serveur MCP (plutot que contribue a un existant), cette etape est cruciale. Un serveur que personne ne connait est un serveur que personne n utilise. Voici comment maximiser la visibilite de votre creation.

Publiez sur les registres de packages. Pour TypeScript, publiez sur npm. Pour Python, publiez sur PyPI. Utilisez un nom de package clair avec le prefixe mcp-server- pour etre facilement trouvable. Ajoutez des keywords pertinents : mcp, model-context-protocol, ai-tools.

Enregistrez sur le MCP Server Registry. Soumettez votre serveur au registre officiel pour qu il soit decouvert par les clients MCP. Le processus est generalement une PR sur le repository du registre avec les metadonnees de votre serveur.

Ajoutez les bons GitHub Topics. Sur votre repository, ajoutez les topics mcp-server, model-context-protocol, et des topics specifiques a votre service (ex: postgresql, gitlab).

Communiquez. Publiez un post sur les reseaux sociaux (LinkedIn, Twitter/X, Mastodon) expliquant votre serveur et le probleme qu il resout. Postez sur les communautes MCP (Discord, forums). Si vous avez cree un serveur pour un service francais, partagez-le dans les communautes open source francaises (April, CNLL, meetups locaux). La visibilite attire les premiers utilisateurs et les premiers contributeurs.

FAQ