Spécification MCP – changements de la version du 2025-06-18

 (modelcontextprotocol.io)
1 points par GN⁺ 2025-06-20 | 2 commentaires | Partager sur WhatsApp
  • La nouvelle mise à jour de la spécification MCP met l’accent sur les métadonnées structurées et la gestion du contexte. Elle vise à améliorer l’extensibilité et à renforcer l’interopérabilité entre divers systèmes
  • De nouveaux champs de données ont été ajoutés, et les champs obligatoires existants sont désormais définis plus précisément. La hiérarchisation de la structure des métadonnées permet de prendre en charge des modes d’extension spécifiques à chaque système
  • Des règles claires sont proposées pour le suivi du contexte et la mise à jour des propriétés, avec un accent mis sur une gestion cohérente des informations d’état par rapport aux versions précédentes
  • Les procédures de gestion des autorisations et de validation des données sont explicitement indiquées dans la spécification du protocole. Certains champs nouvellement ajoutés ont été pensés en vue de la compatibilité avec de futures versions du protocole
  • Prise en charge de l’intégration cross-platform : elle fournit une base permettant d’échanger des données de contexte de manière cohérente entre plusieurs plateformes IA et environnements de services cloud
  • MCP (Model Context Protocol) est un protocole d’échange de métadonnées de contexte entre divers systèmes d’IA, tels que les modèles de machine learning ou les grands modèles de langage

Major changes

  1. Suppression de la prise en charge du batching JSON-RPC (PR #416)
  2. Ajout de la prise en charge des sorties d’outils structurées (structured tool output) (PR #371)
  3. Classification des serveurs MCP comme serveurs de ressources OAuth, avec ajout de métadonnées sur les ressources protégées afin de faciliter la découverte du serveur d’autorisation associé (PR #338)
  4. Obligation pour les clients MCP d’implémenter le Resource Indicator de la RFC 8707 (afin d’empêcher qu’un serveur malveillant obtienne un jeton d’accès) (PR #734)
  5. Clarification des security considerations et des bonnes pratiques dans la spécification Authorization, avec ajout d’une page de guide de sécurité dédiée
  6. Ajout de la fonctionnalité Elicitation (requête d’information), permettant au serveur de demander des informations supplémentaires à l’utilisateur (PR #382)
  7. Ajout de la prise en charge des Resource Links, avec possibilité d’inclure des liens de ressources dans le résultat d’un appel d’outil (PR #603)
  8. Lors de la négociation de version du protocole, l’en-tête HTTP MCP-Protocol-Version devient obligatoire (PR #548)
  9. Le SHOULD des Lifecycle Operation est remplacé par MUST (référence)

Other schema changes

  1. Le champ _meta est ajouté à davantage de types d’interface (PR #710), avec description de son usage approprié
  2. Ajout du champ context à CompletionRequest, permettant d’inclure des variables précédemment interprétées (PR #598)
  3. Ajout du champ title pour un affichage convivial distinct de l’identifiant destiné au programme (name est destiné à l’identifiant de code, title à l’affichage) (PR #663)

À lire aussi

2 commentaires

 
kernel00 2025-06-20

Les commentaires sur Hacker News sont un peu décevants. On dirait qu’ils n’ont regardé que stdio, alors qu’en ce moment les remote MCP servers et les registries qui les servent d’intermédiaire se multiplient à toute vitesse....
 
GN⁺ 2025-06-20
Avis Hacker News
  • La principale chose que j’ai apprise en surfant sur la vague MCP (Machine Context Protocol), c’est qu’en développement logiciel backend, il n’y a pas vraiment besoin d’utiliser MCP. Il y a un décalage au niveau de l’architecture. C’est encore plus vrai dans un environnement comme Elixir, selon moi. Si on déploie un serveur distinct pour chaque API, cela revient à faire tourner 500 microservices pour 500 API. Je ne m’en suis rendu compte qu’après avoir utilisé moi-même une vingtaine de serveurs MCP, mais au final MCP n’était qu’un emballage autour de l’appel de fonctions. Chaque API peut très bien être implémentée comme un module séparé plutôt que comme un serveur. Inutile de courir après la dernière spécification MCP ni de mettre à jour des centaines de microservices à chaque changement de spec. Au bout du compte, c’est juste une complexité inutile
    • À moins que le client ne se connecte directement à chaque microservice sans passer par une gateway ou un BFF, il suffit simplement de placer MCP devant l’ensemble du service et d’exposer les fonctionnalités comme on le fait déjà avec API, GraphQL, RPC, etc. En pratique, ça ressemble à une interface spécialisée pour les LLM. Les tool calls basés sur une spécification OpenAPI peuvent aussi très bien faire l’affaire. Quoi qu’il en soit, imaginer que tous les microservices communiquent entre eux uniquement via MCP, c’est aller beaucoup trop loin
    • Moi, je voyais surtout MCP comme une solution d’intégration façon plugin qui permet les function calls sans coût d’API, comme avec Claude. Si tu utilises déjà des API et que tu n’as pas d’urgence particulière, ce n’est pas vraiment une option nécessaire
    • En fait, je pense que MCP est un protocole standard qui relie le client et le modèle. Ce n’est pas juste un conteneur qui enveloppe des appels d’outils
    • Oui, avoir un serveur MCP par API n’est pas une architecture qui passe à l’échelle. En utilisant quelque chose comme nango.dev, un seul serveur peut couvrir plus de 400 API. Ça gère l’authentification, la visibilité, et fournit aussi diverses interfaces permettant des tool calls directs. (Pour info, j’en suis le fondateur)
    • J’irais même plus loin : à mon avis, toute cette culture qui consiste à forcer les LLM à produire du JSON est absurde. On dépense trop de temps et d’efforts pour les faire entrer dans un format contraignant qu’ils n’aiment pas naturellement. Un DSL textuel, pourtant bien plus restrictif, s’est révélé être une bien meilleure alternative. À l’époque de GPT 3.5, il suffisait de donner quelques exemples simples dans le prompt pour obtenir de manière fiable un DSL en anglais. Pourtant, même les modèles récents ignorent encore parfois certaines parties d’un JSON schema. On a vraiment l’impression d’enfoncer un clou rond dans un trou carré ; j’aimerais que tout le monde arrête de forcer les choses
  • Je suis vraiment ravi qu’il existe désormais une voie simple vers des serveurs MCP authentifiés. J’aimerais remercier sincèrement la communauté MCP et l’équipe d’Anthropic
    • Je ne vois pas bien pourquoi il faudrait un serveur MCP. Si un agent veut faire du RPC, pourquoi ne pas simplement utiliser du RPC ?
  • Je trouve vraiment curieux que la spécification de base soit écrite en TypeScript plutôt qu’en OpenAPI ou autre chose. J’imagine qu’il y a de bonnes raisons, mais ça reste surprenant
    • Je me demande pourquoi c’est surprenant. J’utilise beaucoup TypeScript moi aussi, mais je n’avais jamais envisagé la question sous cet angle, donc je suis curieux de savoir quelles décisions ont été prises du point de vue du design du langage
  • Je suis très heureux de voir l’introduction du challenge WWW-Authenticate. Il est désormais clair qu’un serveur MCP peut rediriger le client vers le flux OAuth du fournisseur de ressources, puis simplement recevoir l’en-tête Authorization: Bearer ...
  • Je pense que c’est <i>en grande partie</i> une complexité inutile, mais l’exécution par lots va me manquer. C’était amusant d’implémenter un mécanisme du genre « fais tout ce travail, puis réponds avec tous les résultats d’un coup ». Bien sûr, le client peut aussi regrouper lui-même les réponses batch, mais ça restait amusant
    • Oui. La fonctionnalité de batch de JSON-RPC m’avait vraiment donné une impression de « wow, c’est malin ». C’est dommage qu’elle disparaisse de la spécification, mais je comprends aussi qu’au final elle n’ajoute que de la complexité
  • Je pense que l’elicitation (traitement des prompts basé sur le raisonnement) est l’un des grands gains. L’un de mes serveurs MCP préférés est un serveur SSH que j’ai créé moi-même. Il permet d’automatiser 90 % du travail d’administration de serveurs. J’ai géré l’authentification via un fichier de configuration, mais c’est un peu pénible de devoir le modifier à la main chaque fois qu’il faut se connecter à un nouveau serveur
    • Dans ce genre de cas, on pourrait aussi utiliser quelque chose comme fabfile.org. Si la conversation n’a pas besoin d’intégrer un LLM, je pense qu’il vaut mieux la garder privée
  • Ces derniers jours, je me suis amusé à créer un wrapper de dataset avec MCP
  1. Je pense que c’est l’une des expérimentations les plus passionnantes du monde des LLM. Bien sûr, on peut faire quelque chose de similaire avec des API classiques et des tool calls, mais ce qui m’a impressionné, c’est qu’en envoyant simplement une URL MCP pour Claude à un ami peu familier avec la technique, il pouvait l’essayer en quelques clics
  2. J’utilise le SDK csharp, et comme les fonctionnalités d’authentification ne sont encore disponibles que sur une branche, tout est encore très embryonnaire. 95 % du temps passé à intégrer MCP a été absorbé par l’implémentation de l’authentification (indispensable hors build local). Ce sera sans doute mieux avec plus de documentation, mais pour l’instant c’est un processus assez lourd
  3. Il manque aussi de visibilité côté logs développeur. J’aimerais que Claude, sur le web (et non sur desktop), affiche en mode développeur les logs de requêtes/réponses pour voir ce qui est échangé et où surviennent les erreurs. J’ai passé un bon moment à me battre avec un problème de renouvellement d’authentification avant de comprendre tardivement que je journalisais le mauvais endpoint. Avec de meilleurs logs MCP, cela aurait été réglé en quelques minutes. Sur desktop et avec MCP inspector, ça fonctionne bien
  4. Ma plus grande interrogation concerne le traitement des tâches longues. Le dataset que j’expose est composé de plusieurs documents PDF. Claude ne semble pas pouvoir traiter lui-même les PDF (si quelqu’un connaît une méthode, je suis preneur !), donc pour l’instant je passe par gemini pour les convertir en texte avant de les transmettre via MCP. Les documents simples passent bien, mais les longs prennent du temps à traiter. Pour le moment, je me contente d’indiquer « traitement en cours, merci de réessayer plus tard ». Il existe bien une API de progression, mais comme il faut maintenir une connexion persistante au serveur (et que Cloudflare la coupe au bout d’un certain temps), cela semble avoir des limites pratiques. J’aimerais vraiment qu’il existe un mécanisme où le LLM revienne vérifier après x secondes et fasse autre chose en attendant, avec une sorte de « suspension temporaire de l’exécution » jusqu’à expiration du timer. Aujourd’hui, soit le LLM reste bloqué à ne rien faire tant que la connexion est maintenue, soit on renvoie avec un job ID et on obtient une réponse incomplète qui perd souvent le contexte global. Pour les tâches qui doivent durer plus de 10 minutes, cela peut devenir un obstacle majeur
  • Les tâches de longue durée restent un sujet encore discuté publiquement. À ma connaissance, MCP a bien l’intention d’y apporter une solution. Plusieurs propositions circulent, et comme on ne peut pas toujours savoir à l’avance si une tâche va être longue, séparer simplement une API spéciale pour les tâches longues ne résout pas vraiment le problème. J’ai moi-même une proposition pour traiter cela de manière plus intégrée lien de discussion
  • Je suis très heureux de voir la spécification MCP s’améliorer rapidement. À chaque nouvelle release, je constate qu’un des points qui me frustraient dans l’intégration de MCP est comblé
  • Je trouve intéressant qu’une modification de la spécification puisse être fusionnée avec une seule approbation
  • Je ne comprends pas bien ce que MCP résout réellement. Personnellement, je n’y vois qu’un rôle possible quand on veut prototyper rapidement quelque chose sur un laptop. Si je construis un programme local, je veux contrôler beaucoup plus finement l’ensemble des outils auxquels le LLM peut accéder. Si on prend par exemple un serveur MCP pour Google Calendar, MCP ne me fait pas gagner énormément de temps. Je peux utiliser la même API moi-même, et je dois de toute façon expliquer explicitement au LLM quand et comment appeler Google Calendar, donc je n’ai pas envie de déléguer ça à un tiers. Et peu importe le langage dans lequel MCP est écrit, faire tourner arbitrairement des processus dans mon environnement me met mal à l’aise. Si mon environnement est en Python et que je dois en plus demander à l’utilisateur d’installer un runtime TypeScript, ça peut poser problème. S’il y a une vulnérabilité dans le wrapper MCP, il y a aussi des inquiétudes de sécurité. En environnement serveur, c’est encore plus difficile à justifier. Pour invoquer des services sur des machines différentes sans connaître les détails d’implémentation, on a déjà une très bonne solution : le RPC. MCP donne surtout l’impression d’ajouter par-dessus un middleware très prescriptif et des problèmes de sécurité
    • Ce que je ne comprends pas, c’est pourquoi tous les MCP que j’ai vus jusqu’ici sont basés sur des commandes plutôt que sur une interface HTTP. Avec HTTP, on pourrait lancer un seul serveur et le partager à l’échelle de toute l’organisation, sans que chacun ait besoin de configurer sa propre toolchain
    • Contrairement aux approches classiques où le backend impose un flux fixe, l’avantage de MCP est que le LLM peut lui-même faire l’orchestration directement. Par exemple, lors d’une recherche web, il peut reformuler la requête et réessayer jusqu’à obtenir l’information voulue. De même, pour résoudre un problème particulier en CLI, il peut enchaîner plusieurs outils dans le bon ordre. C’est une forme d’organisation qu’un flux figé ne permet pas
    • Ce que MCP apporte, c’est un protocole standardisé pour connecter, depuis le centre LLM, des agents à diverses capacités comme les tools
    • Je suis aussi très d’accord avec une partie de cette critique. Quand on l’utilise réellement, cela donne une impression de grande lenteur. J’ai quitté mon emploi il y a deux ans pour développer un client LLM, et je n’ai toujours pas réussi à intégrer Google Calendar. Malgré tout, du point de vue utilisateur, l’utilité de MCP est justement de combler ce genre de trous temporaires. Ça me rappelle l’époque où les trois premières rangées de l’écran d’accueil de l’iPhone se ressemblaient chez tout le monde, mais où la dernière rangée était complètement différente selon les personnes. J’ai le sentiment que, à l’avenir aussi, les départements IT et les équipes de développement continueront chacun à créer des serveurs MCP adaptés à leur propre travail