Le test Simon d’Anthropic révèle les frictions derrière les connexions MCP personnalisées

L’observateur d’Anthropic Simon Willison a connecté un serveur MCP personnalisé à Claude et ChatGPT, mais l’expérience a révélé deux parcours de configuration très différents. Son test du 29 juillet a montré que les interfaces de chat standard peuvent utiliser des outils créés par des développeurs, malgré les restrictions produit, les exigences d’hébergement distant et le travail d’autorisation.

L’expérience anthropic simon est importante car Model Context Protocol dépasse désormais le cadre des agents de programmation et des fichiers de configuration de bureau. MCP, un protocole ouvert permettant de connecter des applications d’IA à des outils et données externes, arrive dans les fenêtres de chat du quotidien. Cela élargit son audience tout en rendant les restrictions au niveau des produits plus difficiles à ignorer.

Claude présente cette connexion comme un connecteur personnalisé. ChatGPT place une fonctionnalité comparable derrière son système d’apps et ses contrôles pour développeurs. Les deux peuvent accéder à un serveur distant, mais aucun ne transforme ce serveur en plug-in universellement portable. Le protocole standardise la communication, tandis que chaque hôte conserve le contrôle sur la découverte, les autorisations, les validations et la disponibilité.

Ce que le test MCP de Simon Willison a réellement changé

Un serveur MCP personnalisé peut désormais servir à la fois Claude et ChatGPT sans obliger les utilisateurs à quitter leurs conversations web habituelles.

Willison a documenté le processus dans un test MCP personnalisé publié le 29 juillet 2026. Le résultat central était simple. Un développeur peut héberger un serveur MCP, l’enregistrer auprès des deux services et exposer ses outils dans leurs interfaces de chat habituelles.

Ce résultat distingue cette expérience des précédentes démonstrations de MCP centrées sur Claude Code, les fichiers de configuration de bureau ou des clients destinés aux développeurs. Ces environnements rendaient déjà les connexions aux outils relativement naturelles. Les produits de chat grand public standard ajoutent une couche supplémentaire de règles de compte et de contrôles d’interface.

Le serveur doit être accessible à distance. Un processus local utilisant le transport standard d’entrée et sortie ne peut pas simplement apparaître dans une session de navigateur. L’hôte a besoin d’un point de terminaison HTTP accessible sur Internet qui implémente les parties de MCP attendues par chaque client.

L’accès distant modifie le modèle de déploiement. Le développeur ne configure plus une application pour lancer un processus approuvé sur un ordinateur personnel. Il exploite un service réseau qui doit gérer la sécurité du transport, l’identité, l’autorisation, la disponibilité et potentiellement plusieurs utilisateurs.

Claude décrit ces intégrations comme des connecteurs personnalisés. Anthropic indique qu’ils peuvent connecter Claude à des outils et sources de données hébergés via des serveurs MCP distants. Ses consignes actuelles sur les connecteurs répertorient une prise en charge dans Claude et Claude Desktop pour les comptes individuels et professionnels éligibles.

ChatGPT décrit cette même capacité générale au moyen d’apps personnalisées et de connecteurs MCP. L’interface d’OpenAI distingue également la création d’une app, son test, son approbation et sa mise à disposition au sein d’un espace de travail.

Cette différence d’appellation est plus que cosmétique. « Connecteur » suggère un pont vers un service existant. « App » évoque un élément empaqueté, examiné et distribué via une surface produit contrôlée par l’hôte. MCP peut prendre en charge les deux modèles, mais les termes façonnent les attentes des utilisateurs.

Le serveur a aussi besoin de définitions d’outils utiles. Ces descriptions indiquent au modèle ce que fait chaque outil, quand il doit être appelé et quelles entrées il accepte. Un point de terminaison techniquement valide peut néanmoins fonctionner médiocrement si ses outils se chevauchent ou utilisent des descriptions vagues.

Le test de Willison a donc démontré l’interopérabilité au niveau du protocole, et non un comportement identique entre les produits. Claude et ChatGPT peuvent découvrir les mêmes capacités de base. Ils peuvent toutefois sélectionner les outils différemment, demander des validations différentes et présenter les résultats dans des interfaces différentes.

Pour les développeurs, le fait mémorable n’est pas que les deux entreprises prennent MCP en charge sous une forme ou une autre. Le changement important est qu’une même implémentation hébergée peut désormais atteindre des utilisateurs dans les deux principaux produits de chat. Cela rend les tests inter-produits réalisables sans maintenir deux protocoles d’intégration entièrement distincts.

Pourquoi le résultat anthropic simon met les deux plateformes d’IA sous pression

MCP déplace une partie de la concurrence, de l’intelligence des modèles vers le contrôle des outils, des autorisations et de la distribution.

Le résultat anthropic simon met Anthropic sous pression, car l’entreprise a créé MCP et a promu le protocole comme une norme ouverte. Claude doit rester un client de référence convaincant. Si les serveurs externes fonctionnent de manière plus prévisible ailleurs, être l’auteur du protocole ne garantira pas la préférence pour la plateforme.

OpenAI fait face à la pression inverse. L’entreprise n’est pas à l’origine de MCP, mais ChatGPT joue un rôle immense en tant que plateforme applicative. Les développeurs s’attendront à ce qu’il prenne en charge les intégrations qui fonctionnent déjà avec Claude et d’autres clients MCP.

Cela crée une opposition claire entre portabilité du protocole et contrôle de la plateforme. Les développeurs veulent décrire un outil une seule fois et le connecter à travers des produits compatibles. Les opérateurs de plateforme veulent décider quels comptes peuvent connecter des serveurs, quelles actions sont autorisées et comment les appels risqués sont examinés.

Claude propose actuellement un concept direct de connecteur personnalisé pour plusieurs types de comptes. L’usage professionnel introduit des contrôles administrateurs, car un connecteur peut exposer des données d’entreprise ou exécuter des actions. Un propriétaire peut configurer la disponibilité, tandis que les utilisateurs individuels s’authentifient toujours avec leurs propres autorisations.

ChatGPT applique une structure de déploiement plus explicite. Le guide actuel du mode développeur d’OpenAI indique que la prise en charge complète de MCP est disponible sur le web pour les clients Business, Enterprise ou Edu. Il décrit également un accès plus limité en lecture et récupération pour les utilisateurs Pro.

La distinction devient importante lorsqu’un serveur expose des opérations d’écriture. Rechercher dans une collection de documents présente un profil de risque. Mettre à jour des dossiers clients, publier du contenu ou supprimer un projet en présente un autre.

OpenAI indique que les actions d’écriture et de modification peuvent déclencher une confirmation, selon l’autorisation, le contexte et l’impact potentiel. Certaines actions particulièrement risquées peuvent être bloquées. Les administrateurs d’espace de travail contrôlent également le passage d’une app des tests privés à une disponibilité approuvée.

Anthropic conseille de même aux utilisateurs d’examiner les demandes d’outils et de n’activer que les outils pertinents pour une conversation. Cet avertissement reflète une limite fondamentale des interfaces agentiques. Une demande en langage naturel ne révèle pas toujours toutes les actions externes qu’un modèle pourrait juger nécessaires.

Ces contrôles affaiblissent la promesse de portabilité la plus simple. Un développeur peut réutiliser le serveur, les schémas et les fondations d’autorisation. Il ne peut pas supposer un accès, des parcours utilisateurs, un comportement de confirmation ou des décisions de modèle identiques.

Cette fragmentation n’est pas nécessairement un échec du protocole. MCP définit un langage commun entre clients et serveurs. Il n’impose pas à chaque hôte d’adopter les mêmes politiques produit.

Néanmoins, les frictions produit peuvent déterminer si la compatibilité du protocole compte en pratique. Une connexion cachée derrière des paramètres administrateur atteindra moins d’utilisateurs qu’une connexion disponible depuis un écran de paramètres personnels. Une implémentation en lecture seule ne peut pas remplacer un concurrent qui autorise des écritures soigneusement approuvées.

La qualité de l’invocation des outils ajoute une autre source de pression. Le modèle doit choisir le bon outil, produire des arguments valides, interpréter les erreurs et communiquer les résultats. La prise en charge d’un transport MCP ne garantit pas l’exécution fiable de la tâche de l’utilisateur.

Les développeurs devraient donc tester les mêmes prompts sur les deux plateformes. Un serveur peut exposer des outils identiques tout en produisant des schémas d’appel différents. Ces différences peuvent révéler si une description est ambiguë ou si un hôte applique des contrôles plus stricts.

La question concurrentielle plus large n’est plus de savoir si Claude ou ChatGPT peut appeler une API. Les deux plateformes le peuvent. La question est de savoir laquelle rend les capacités externes compréhensibles, gouvernables et fiables pour les utilisateurs ordinaires.

Un même protocole produit toujours deux expériences de configuration

MCP réduit la duplication du code d’intégration, mais n’élimine pas les étapes opérationnelles entourant une connexion sécurisée.

Pour Claude, le parcours de base passe par Settings et Connectors. Un utilisateur ajoute un connecteur personnalisé, fournit l’adresse du serveur distant et termine l’authentification lorsque le serveur l’exige. Les propriétaires d’espaces de travail peuvent devoir activer ou configurer le connecteur au préalable.

La documentation serveur d’Anthropic oriente les créateurs vers la spécification d’autorisation du protocole et les exemples officiels de SDK. Elle signale également la prise en charge des modèles actuels d’autorisation à distance.

Pour ChatGPT, le parcours passe par Apps et les paramètres avancés. L’utilisateur ou l’administrateur active l’accès développeur, crée une app, saisit l’URL MCP distante, choisit l’authentification et accepte l’avertissement associé à un serveur personnalisé.

Les administrateurs d’espaces de travail Business peuvent créer et déployer des apps pour leur espace de travail. Les environnements Enterprise et Edu ajoutent des contrôles fondés sur les rôles pour les développeurs et les utilisateurs. Ces règles font de la connexion un élément de gouvernance organisationnelle, et non une simple configuration personnelle.

Le centre technique commun est un point de terminaison MCP distant. Les serveurs distants modernes utilisent couramment Streamable HTTP, un transport qui véhicule les messages MCP via des requêtes HTTP et des réponses en streaming. Ce point de terminaison doit prendre en charge les échanges d’initialisation et de découverte d’outils attendus par les clients compatibles.

Les messages MCP utilisent JSON-RPC 2.0, un format structuré pour les requêtes, résultats, notifications et erreurs. Le protocole définit la manière dont un client découvre et invoque les outils. Il ne définit pas la logique métier sous-jacente de chaque outil.

Prenons un serveur de recherche privé. Il pourrait proposer un outil pour rechercher dans des documents stockés et un autre pour récupérer un enregistrement complet. Claude et ChatGPT peuvent découvrir ces définitions depuis le même point de terminaison.

Le développeur doit toujours décider qui peut rechercher quels enregistrements. Cette décision relève du serveur et de sa couche d’autorisation. Masquer un outil dans l’interface d’un client ne remplace pas l’application des contrôles d’accès à la source des données.

OAuth devient essentiel lorsque le serveur traite des données propres à l’utilisateur. Le client fait passer l’utilisateur par un flux d’autorisation, reçoit un jeton d’accès et présente ce jeton lors de l’appel au serveur MCP protégé. Le serveur valide ensuite le jeton avant de renvoyer les données.

La spécification d’autorisation de MCP exige des métadonnées de ressource protégée pour les déploiements conformes d’autorisation HTTP. Ces métadonnées indiquent à un client où se trouvent les services d’autorisation. Elles prennent en charge la découverte sans coder en dur chaque association client-serveur.

C’est à ce stade qu’une démonstration rapide devient un véritable projet d’ingénierie. Le serveur a besoin d’une adresse HTTPS stable, de métadonnées correctes, d’une gestion des redirections, d’une validation des jetons et de portées appropriées. Il a aussi besoin de messages d’erreur que les clients peuvent interpréter lorsque l’autorisation échoue.

L’enregistrement du client peut créer un autre problème de compatibilité. Certains systèmes prennent en charge l’enregistrement dynamique ou les documents de métadonnées client. D’autres attendent un identifiant client créé à l’avance. Un serveur conçu autour d’une hypothèse peut nécessiter une adaptation avant que les deux produits de chat ne s’authentifient correctement.

Une implémentation pratique devrait commencer par un outil étroit, en lecture seule. Par exemple, une équipe pourrait exposer des notes de projet approuvées via une seule fonction de recherche. Les utilisateurs pourraient demander à l’un ou l’autre assistant de retrouver des décisions antérieures sans accorder de droits de mise à jour ou de suppression.

Ce cas d’usage crée également un lien naturel avec une base de connaissances personnelle ou d’équipe. MCP peut fournir la couche d’accès, tandis que le système sous-jacent reste responsable de l’indexation, des autorisations, de la conservation et de la qualité des sources.

Une fois le chemin de lecture opérationnel, les développeurs peuvent ajouter des actions plus précises. Chaque outil d’écriture devrait avoir un objectif évident et un périmètre limité. « Mettre à jour le statut d’une tâche » est plus facile à examiner que « exécuter une opération de projet arbitraire ».

Les descriptions d’outils méritent le même soin qu’un contrat d’API. Le modèle consulte ces descriptions lorsqu’il décide d’appeler une fonction. Des noms vagues augmentent le risque de sélection incorrecte, d’appels répétés ou d’accès inutile à des données.

Les schémas d’entrée doivent également rejeter toute ambiguïté. Un outil qui modifie un compte devrait exiger un identifiant de compte stable. Il ne devrait pas se fier uniquement à un nom de client susceptible de correspondre à plusieurs enregistrements.

Les réponses devraient renvoyer suffisamment d’informations structurées pour que le modèle puisse expliquer ce qui s’est passé. Un outil d’écriture peut inclure l’objet modifié, son état précédent et son nouvel état. Cela aide l’hôte à présenter une confirmation utile.

Les tests doivent couvrir davantage que les appels réussis. Les développeurs devraient tester les jetons expirés, les autorisations révoquées, les dépendances indisponibles, les entrées malformées et les tentatives d’accès aux enregistrements d’un autre utilisateur. Les deux hôtes peuvent présenter ces échecs différemment.

Cela explique pourquoi l’ajout d’un serveur personnalisé peut sembler long malgré un protocole ouvert. MCP élimine une catégorie de duplication d’intégration. Il n’élimine pas le déploiement, l’identité, l’examen de sécurité, la configuration du produit ou l’assurance qualité.

Le véritable compromis : portabilité contre confiance

La même ouverture qui permet à un serveur d’atteindre plusieurs assistants donne aussi à ce serveur une position privilégiée entre les utilisateurs, les modèles et les systèmes sensibles.

Un serveur MCP personnalisé peut voir les entrées envoyées via ses outils. Il peut renvoyer du contenu que le modèle traite comme du contexte. S’il expose des actions, il peut également modifier des données externes sous l’identité de l’utilisateur.

Cette combinaison crée plusieurs frontières de confiance. Les utilisateurs doivent faire confiance au fournisseur de chat, à l’opérateur du serveur MCP, au service connecté et à l’implémentation de l’autorisation. Les organisations doivent également faire confiance aux descriptions qui guident le comportement du modèle.

L’injection de prompt est une préoccupation majeure. Une instruction malveillante peut être intégrée dans des données récupérées par un outil, comme un document, un ticket de support ou une page web. Le modèle pourrait interpréter ce contenu comme une directive plutôt que comme du contenu non fiable.

Le risque augmente lorsque plusieurs outils sont disponibles. Le contenu récupéré pourrait tenter de persuader le modèle d’appeler un autre outil avec des arguments sensibles. Une opération de lecture peut donc devenir l’étape initiale d’une séquence d’écriture involontaire.

Anthropic et OpenAI avertissent tous deux les utilisateurs de ne connecter que des serveurs de confiance. Ce conseil est nécessaire, mais la confiance n’est pas un contrôle de sécurité complet. Même un serveur bien intentionné peut contenir des erreurs d’autorisation ou des actions excessivement larges.

Le serveur doit valider chaque requête indépendamment. Il ne devrait jamais supposer qu’un appel est sûr parce que Claude ou ChatGPT l’a généré. Les confirmations de l’hôte peuvent aider les utilisateurs, mais elles ne remplacent pas les contrôles d’accès côté serveur.

La gestion des jetons exige une attention particulière. La spécification MCP interdit le transfert de jetons, lorsqu’un serveur transmet à un autre service un jeton destiné à un service donné. Les jetons devraient avoir une audience définie, et le serveur destinataire devrait vérifier cette audience.

Le principe du moindre privilège offre le point de départ le plus clair. Un connecteur de recherche devrait demander un accès en lecture avant de demander un accès en écriture. Un outil de calendrier ne devrait pas demander des droits de suppression lorsqu’il doit seulement répertorier les disponibilités.

Les opérations d’écriture bénéficient également d’une sémantique étroite. Un outil appelé delete_everything est manifestement dangereux, mais de larges fonctions administratives peuvent masquer une exposition similaire derrière des noms plus rassurants. Chaque action devrait correspondre à une intention utilisateur vérifiable.

Les opérations à fort impact devraient prendre en charge l’idempotence, qui empêche qu’une répétition accidentelle produise plusieurs modifications. Un modèle peut réessayer après une réponse ambiguë. Sans garde-fous, une tâche demandée peut créer des enregistrements ou des messages en double.

Les journaux d’audit sont tout aussi importants. Les opérateurs doivent savoir quel utilisateur a autorisé un appel, quel outil a été exécuté, quel objet a changé et si l’hôte a signalé une confirmation. Les journaux devraient éviter de conserver du contenu de prompt ou des secrets inutiles.

Les opérateurs de serveurs devraient séparer les données destinées aux utilisateurs des instructions de contrôle. Les résultats des outils peuvent étiqueter clairement le texte non fiable et renvoyer des champs structurés lorsque cela est possible. Les modèles restent vulnérables à la manipulation, mais une conception prudente des sorties réduit l’ambiguïté.

Les plateformes hôtes font également face à des questions non résolues. Leurs invites d’approbation doivent fournir suffisamment d’informations pour que les utilisateurs comprennent une action. Une demande générique visant à « autoriser l’accès aux outils » offre peu de protection lorsque l’outil peut effectuer plusieurs opérations.

Le comportement des outils peut changer après la connexion. Anthropic note explicitement que les développeurs de serveurs peuvent modifier les outils sans avertissement. Un utilisateur qui a approuvé un connecteur de recherche inoffensif pourrait ensuite rencontrer des capacités plus étendues depuis le même point de terminaison.

Le versionnement et la révision peuvent réduire ce risque. Les organisations peuvent figer les déploiements, surveiller les modifications de schéma et exiger une nouvelle révision lorsqu’un outil obtient un accès en écriture. Les opérateurs de serveurs publics peuvent publier des journaux de modifications et maintenir des périmètres stables.

La circulation des données soulève également une question de confidentialité. Une entreprise peut autoriser son assistant à rechercher dans des dossiers internes tout en interdisant que ces dossiers atteignent un autre sous-traitant. L’emplacement d’hébergement du serveur MCP et sa politique de conservation deviennent alors partie intégrante de la décision.

Un déploiement sécurisé exige donc plus qu’une connexion valide. Les équipes devraient documenter les catégories de données, les actions autorisées, les périmètres d’authentification, les règles de conservation, les contacts en cas d’incident et les procédures de révocation. Elles devraient également tester la manière dont chaque hôte signale l’utilisation des outils.

La démonstration anthropic simon prouve que la connectivité multiplateforme est possible. Elle ne prouve pas que chaque serveur accessible convient à la production. La compatibilité est le début de l’évaluation, pas sa fin.

Cette distinction importe aux travailleurs du savoir qui souhaitent que leur assistant préféré accède à des notes privées ou à l’historique d’un projet. Un connecteur peut réduire les copies entre les outils. Il peut aussi élargir le chemin par lequel un contexte sensible circule.

Les équipes qui évaluent ce compromis devraient commencer par des informations qu’elles peuvent se permettre d’exposer dans le cadre d’un accès contrôlé. Une collection consultable de documentation d’ingénierie approuvée est plus sûre qu’une passerelle sans restriction vers tous les systèmes internes.

Elles peuvent ensuite mesurer si l’assistant trouve les bonnes sources, respecte les autorisations et explique clairement l’utilisation des outils. L’extension devrait suivre les preuves, et non la simple disponibilité d’un point de terminaison MCP.

Ce que l’expérience Anthropic Simon indique de surveiller ensuite

Le prochain test de MCP sera de savoir si les serveurs multiplateformes deviennent des produits courants plutôt que des intégrations spécialisées assemblées via des paramètres avancés.

Le premier signal est la convergence autour de l’autorisation distante. Claude et ChatGPT doivent tous deux connecter les utilisateurs en toute sécurité sans travail d’enregistrement personnalisé pour chaque appariement. Une adoption plus large se renforcera si un déploiement OAuth conforme aux normes fonctionne de manière fiable sur les deux.

Si l’autorisation reste remplie d’exceptions propres à chaque client, la promesse de portabilité s’affaiblit. Les développeurs réutiliseront toujours des parties du serveur, mais devront maintenir des instructions de configuration, des métadonnées et des parcours de dépannage distincts.

La preuve la plus solide viendra de services ordinaires publiant un point de terminaison distant unique avec des instructions vérifiées pour plusieurs assistants. Ces services ne devraient pas obliger les utilisateurs à coller des clés API à longue durée de vie dans les paramètres de chat. Un consentement dans le navigateur devrait accorder des périmètres étroits et révocables.

Le deuxième signal est la manière dont OpenAI étend l’accès MCP complet. La documentation actuelle distingue la prise en charge complète pour les comptes professionnels gérés de capacités Pro plus limitées. Une voie personnelle plus large exercerait une pression directe sur l’expérience de connecteurs personnalisés de Claude.

Le maintien d’une forte priorité au déploiement par les administrateurs indiquerait une stratégie différente. Les apps ChatGPT fonctionneraient principalement comme des logiciels professionnels gouvernés, tandis que Claude pourrait conserver une voie plus directe pour l’expérimentation individuelle.

Aucune de ces voies n’est automatiquement meilleure. Les entreprises ont souvent besoin d’approbation, d’auditabilité et de contrôles par rôle. Les développeurs indépendants valorisent un chemin court entre un serveur déployé et une conversation opérationnelle.

Le troisième signal est la façon dont les deux plateformes gèrent les actions d’écriture. La recherche et la récupération de données permettent des démonstrations utiles, mais les actions déterminent si MCP devient une véritable couche applicative. Elles créent aussi les problèmes de sécurité et d’interface les plus difficiles.

Surveillez l’apparition de résumés d’autorisations plus clairs, d’aperçus des actions, de politiques de confirmation et de traces d’audit. Un hôte qui explique bien les effets externes peut rendre les outils d’écriture plus utilisables sans prétendre qu’ils sont sans risque.

Les développeurs devraient également surveiller si les hôtes exposent de meilleurs diagnostics. Les échecs de connexion réduisent souvent plusieurs causes possibles à une seule erreur. Le problème peut concerner la négociation de transport, les métadonnées d’autorisation, la configuration de redirection, l’audience du jeton ou la validation du schéma d’outil.

De meilleurs diagnostics raccourciraient le chemin entre un serveur local opérationnel et une intégration distante fiable. Ils réduiraient également la pression sur les opérateurs de serveurs pour rétroconcevoir les attentes différentes des hôtes.

Les systèmes de registre et de découverte représentent une autre couche importante. Un protocole ouvert n’indique pas aux utilisateurs quels serveurs sont dignes de confiance. Les répertoires organisés peuvent aider, mais ils donnent aussi aux propriétaires des plateformes un autre point de contrôle.

Un serveur répertorié par un hôte peut rester une connexion personnalisée manuelle sur un autre. Les développeurs font alors face à un problème de distribution même lorsque leur implémentation est portable. Les délais de révision et les règles de référencement peuvent devenir des facteurs de différenciation concurrentielle.

Les utilisateurs devraient donc distinguer la compatibilité d’un serveur de sa disponibilité. Un service peut techniquement fonctionner avec Claude et ChatGPT tout en restant difficile à trouver ou limité par une politique d’espace de travail.

La même distinction s’applique à la prise en charge de l’interface. Les MCP Apps peuvent renvoyer des interfaces interactives dans les hôtes compatibles, tandis que les serveurs d’outils de base échangent principalement des données structurées et du texte. Des niveaux de prise en charge différents peuvent rendre une intégration plus riche malgré l’utilisation du même protocole sous-jacent.

Pour les créateurs, la stratégie immédiate est prudente. Hébergez un serveur distant conforme aux normes, commencez par un outil de lecture étroit et testez des prompts identiques dans les deux produits. Consignez chaque différence d’authentification, de découverte, d’invocation et de gestion des erreurs.

Ensuite, introduisez une action d’écriture limitée derrière une autorisation explicite. Vérifiez que les nouvelles tentatives ne dupliquent pas les modifications et que la révocation fonctionne. Examinez exactement ce que chaque plateforme affiche avant l’exécution de l’action.

Pour les organisations, la décision devrait commencer par le flux de travail plutôt que par l’enthousiasme autour de MCP. Identifiez une tâche répétée où l’accès via le chat réduit réellement les changements d’outil ou l’effort de recherche. Définissez ensuite le périmètre minimal de données et d’actions nécessaire pour l’accomplir.

Un bon candidat pourrait rechercher des documents techniques approuvés et renvoyer des liens vers les sources. Un autre pourrait rédiger une mise à jour de projet sans la publier. Les deux créent de la valeur tout en maintenant les modifications finales sous contrôle humain.

La requête de recherche « anthropic simon » attirera probablement des lecteurs à la recherche de l’expérience précise de Simon Willison. Sa valeur durable dépasse la séquence de configuration. Le test montre où s’arrête la standardisation des protocoles et où commence la politique des plateformes.

MCP a franchi une étape importante en intégrant les interfaces standard de Claude et ChatGPT. La question suivante est de savoir si la connexion à un serveur de confiance devient simple, prévisible et accessible aux utilisateurs ordinaires.

Les développeurs peuvent contribuer à répondre à cette question dès maintenant. Choisissez un flux de travail à faible risque, créez un point de terminaison distant avec des autorisations limitées, puis comparez les deux hôtes avec les mêmes prompts de test. Les différences montreront si MCP apporte une portabilité concrète ou seulement une base technique commune.