MCP en pratique: quand un serveur Model Context Protocol vaut le coup

Dix-huit mois après la publication du Model Context Protocol, l'écosystème s'est décanté. Certains serveurs tournent en production, d'autres ont été retirés discrètement. Ce qui reste, c'est une question qui revient dans toute discussion de roadmap sur les outils IA: en faut-il un à nous?

Ce que fait vraiment MCP

Le Model Context Protocol est un contrat entre agent et outil. Au lieu que chaque agent (Claude Code, Cursor, OpenCode, implémentations maison) apporte son propre style de tool calling avec son propre schéma, tous parlent la même langue: définitions d'outils normalisées, URI de ressources, prompts. Un serveur écrit une fois est utilisable par n'importe quel agent compatible.

Ce n'est pas une idée révolutionnaire - c'est un adaptateur bien écrit. La valeur tient à la réutilisation.

Trois critères pour son propre serveur MCP

Nos derniers projets font émerger trois conditions dans lesquelles un serveur dédié se rembourse:

1. Au moins deux consommateurs. Si un seul workflow utilise l'outil, un script revient moins cher. C'est le deuxième agent (ou un humain dans une autre IDE) qui rembourse l'investissement MCP.
2. Surface d'outils stable. Une fonction dont la signature change chaque mois ne se prête pas à un protocole avec contrat versionné. MCP récompense des outils clairs, pas trop fins.
3. Exigence de conformité ou de logging. Dès que les accès doivent être traçables ou filtrés par policy, un serveur central est le bon endroit, pas des plugins éparpillés. Une couche OPA ou un audit log s'implémentent une seule fois, proprement.

Trois contre-indicateurs

Tout aussi clairement, voici quand un serveur dédié devient du sur-ingénierie:

• Migration ou ETL ponctuel. Un script lancé trois fois puis archivé ne justifie pas la maintenance d'un schéma de protocole.
• Une interface dédiée existe déjà. Si l'outil est piloté principalement par des humains via une UI web, la surface MCP supplémentaire devient un second front à maintenir.
• Une seule source de données, un seul agent. Dans ce cas, un appel de fonction dans le skill de l'agent suffit - la complexité d'un serveur dédié ne se rembourse pas.

Exemple terrain: quand nous recommandons MCP

Chez un client récent, les données clients vivaient dans un ERP, les contrats dans un DMS, les disponibilités dans un agenda. Trois sources, six workflows agent, trois personnes avec chacune son tooling. Un serveur MCP central tapant les trois sources, sécurisé par OPA, est ressorti nettement moins cher que six intégrations séparées.

Chez un autre client, il s'agissait d'un seul classifieur documentaire pour le courrier entrant. Un script Python avec cron a réglé le problème en une semaine - MCP n'aurait rien ajouté.

La règle simple

Ce n'est qu'à partir du second "ce serait bien qu'un autre agent puisse l'utiliser aussi" que le saut se rembourse. Avant cela, MCP est une solution qui cherche encore son problème.