Comment vérifier le serveur MCP d’un fournisseur martech ?

Une seule ligne de JSON justifie ce billet. Je l’ai récupérée ce matin, sur une plateforme marketing que beaucoup d’équipes de commerce en ligne paient déjà.

curl https://mcp.klaviyo.com/.well-known/oauth-authorization-server

Parmi les points de terminaison ordinaires de la réponse figure "client_id_metadata_document_supported": false.

Autrement dit : le serveur MCP de Klaviyo annonce à tout client qui le lui demande qu’il ne prend pas en charge le mécanisme d’enregistrement client vers lequel le Model Context Protocol s’est déplacé il y a sept semaines, et que les clients devraient utiliser celui que la même révision a déprécié. Ce n’est ni une fuite ni un piège. C’est une déclaration de posture publique et lisible par une machine, et au 16 septembre 2026 c’est ce qui ressemble le plus à une réponse franche que vous obtiendrez, avant authentification, de l’un des trois fournisseurs martech que j’ai vérifiés.

Je dois préciser ce que ce billet est et n’est pas. Je n’ai jamais connecté le serveur MCP d’un fournisseur à l’environnement d’un client, et ceci n’est l’évaluation de sécurité du produit de personne. C’est une question d’approvisionnement accompagnée d’une procédure : quelle révision du protocole le fournisseur vend-il, et comment le savoir avant de signer ? Tout ce qui suit a été vérifié à sa source primaire le 16 septembre 2026 — trois pages de documentation de fournisseurs, deux pages de spécification et des requêtes non authentifiées que j’ai exécutées moi-même. Là où une source contredisait mes notes, la source a gagné. C’est arrivé deux fois.

La seule chose que je possède de première main, c’est l’autre côté du comptoir. Ce site enregistre ses propres outils d’agent, et c’est ainsi que j’ai découvert que la vérification ci-dessous ne fonctionnerait pas non plus sur moi.

Les citations de documentation et de spécifications sont reproduites en anglais, langue de leurs sources ; la traduction entre parenthèses est la mienne.

Réponse courte

Au 16 septembre 2026, ni Braze, ni Klaviyo, ni HubSpot n’indique dans sa documentation quelle révision du Model Context Protocol son serveur implémente, et aucun ne l’annonce à son point de terminaison avant authentification. La révision du 28 juillet 2026 définit un moyen direct d’interroger un serveur sur sa version, mais tous ceux que j’ai testés aujourd’hui renvoient d’abord une erreur d’authentification. Le signal le plus clair vient des métadonnées de Klaviyo : elles déclarent ne pas prendre en charge le mécanisme d’enregistrement client vers lequel cette révision s’est déplacée, et offrir celui qu’elle a déprécié. La vérification prend trois commandes non authentifiées et une minute, et la bonne question d’approvisionnement n’est pas « prenez-vous en charge MCP ? » : c’est quelle révision, et comment le vérifier soi-même.

Chaque fait ici porte la date de vérification du 16 septembre 2026 et une durée de vie qui se compte en semaines. Les documents de métadonnées changent sans note de version, et deux des trois pages ci-dessous ne portent aucune date de publication exploitable.

Qu’a changé la spécification MCP le 28 juillet 2026, et pourquoi un acheteur devrait-il s’en soucier ?

Le Model Context Protocol a publié le 28 juillet 2026 une révision qui a retiré la poignée de main, déprécié l’enregistrement dynamique de client et fixé la première politique de dépréciation formelle du protocole. L’annonce, signée par les mainteneurs principaux David Soria Parra et Den Delimarsky, décrit un cœur sans état : « we’ve officially retired the initialize/initialized exchange » (nous avons officiellement retiré l’échange initialize/initialized), et « Each request now travels on its own, carrying its protocol version, client identity, and client capabilities in _meta. » (chaque requête voyage désormais seule, en portant sa version de protocole, l’identité du client et ses capacités dans _meta). En Streamable HTTP, ajoute la page de versionnage, cette valeur est « also carried in the MCP-Protocol-Version header » (également portée par l’en-tête MCP-Protocol-Version). Il ne reste donc plus de poignée de main où lire une version : ou bien une version voyage avec la requête, ou bien personne n’en déclare aucune.

L’enregistrement a bougé dans la même version : « Dynamic Client Registration itself is now formally deprecated in favor of CIMD. » (l’enregistrement dynamique de client est désormais formellement déprécié au profit des CIMD.) Le billet d’août sur ce que les agents IA peuvent faire dans vos comptes publicitaires et votre CRM traite ce mécanisme en entier, et je ne le redémontre pas ici. Ce qui est neuf pour le calendrier d’un acheteur, c’est une horloge publiée : les fonctions dépréciées « remain in the specification for at least twelve months » (restent dans la spécification au moins douze mois), avec une exception de retrait accéléré de quatre-vingt-dix jours, et le retrait viendra dans « a future version » (une version future) que l’annonce ne nomme pas.

Voici ma première correction. Ma note de travail affirmait que la révision du 28 juillet, en supprimant la poignée de main, supprimait tout moyen de lire la version d’un serveur. Faux sur la seconde moitié : la poignée de main a été remplacée par des métadonnées portées par chaque requête, et non par rien, et un appel server/discover distinct existe pour les clients qui veulent poser la question d’emblée, même si la page de versionnage précise que « Calling it is optional » (son appel est facultatif) côté client. La question n’est pas devenue sans réponse ; sur ces serveurs, elle se trouve derrière le mur d’autorisation, et un acheteur en phase d’évaluation n’a pas encore de compte.

Quelle révision Braze, Klaviyo et HubSpot disent-ils mettre en œuvre ?

Aucune, par écrit, nulle part où j’ai su regarder. Chaque cellule ci-dessous a été lue sur une page de fournisseur ou dans une réponse HTTP non authentifiée le 16 septembre 2026.

Fournisseur	Point de terminaison MCP	Révision indiquée dans la doc ?	Enregistrement annoncé	`token_endpoint_auth_methods_supported`	Méthodes PKCE	Mode lecture seule documenté	Points de terminaison régionaux	Date de doc exploitable
Braze	`mcp.braze.com/mcp`, `mcp.braze.eu/mcp`	Non	`registration_endpoint` sur le serveur d’autorisation américain, aucun sur l’européen	`["none"]` sur les deux	`S256`	Non documenté ; l’accès reflète l’utilisateur du tableau de bord	États-Unis et Europe	Note de version du 23 juillet 2026, « Early access »
Klaviyo	`mcp.klaviyo.com/mcp`	Non	`registration_endpoint`, plus `client_id_metadata_document_supported: false`	`client_secret_basic`, `client_secret_post`, `none`	`plain`, `S256`	Oui, `read-only=true` en paramètre d’URL	Non documentés	La page de connexion affiche « Updated 12 days ago » ; la page de présentation a été restructurée et affiche « Updated 1 day ago »
HubSpot	`mcp.hubspot.com`	Non	Ni l’un ni l’autre, inchangé depuis le 21 août	`["client_secret_post"]`	`S256`	Non documenté	Non documentés	Aucune — la balise `last-updated` de la page contient le jeton non rendu `%2026-%0-%4`

Deux colonnes exigent un avertissement. « Révision indiquée dans la doc » signifie que j’ai cherché sur chaque page « protocol », « specification », « version » et « 2026- » sans trouver de phrase en nommant une. Cela ne signifie pas que le serveur ne met pas en œuvre 2026-07-28 — c’est une négation que personne, hors du fournisseur, ne peut prouver. Les colonnes de métadonnées décrivent ce qu’un serveur d’autorisation annonce, non ce qu’un client négocie.

Ce que chaque fournisseur dit, en revanche, mérite d’être lu de près.

Braze a lancé son serveur distant dans la note de version du 23 juillet 2026, étiquetée « Early access ». La page de documentation décrit « a secure remote connection that lets AI tools like Claude and Cursor access non-PII Braze data » (une connexion distante sécurisée qui laisse des outils IA comme Claude et Cursor accéder à des données Braze sans renseignements personnels), avertit que « Tools that expose user-level PII are not available. » (les outils exposant des renseignements personnels au niveau de l’utilisateur ne sont pas disponibles) et répond à la question des régions par « Either endpoint can reach any Braze cluster. » (l’un ou l’autre point de terminaison peut atteindre n’importe quelle grappe Braze). Aucune phrase n’indique de révision de protocole.

Klaviyo publie la documentation la plus utile des trois. Sa page de connexion nomme l’URL, le transport (« Transport: Streamable HTTP ») et, dans le même bloc, « Authentication method: OAuth (with dynamic client registration) » (méthode d’authentification : OAuth avec enregistrement dynamique de client). C’est le seul endroit où l’un des trois décrit en prose son mécanisme d’enregistrement, et il nomme celui qui est déprécié. Klaviyo documente aussi six paramètres d’URL qui modèlent la surface d’outils, dont read-only, qui « disables any tools which can perform write actions on your Klaviyo account » (désactive tout outil capable d’écrire dans votre compte Klaviyo). Aucune révision de protocole n’apparaît.

HubSpot porte toujours, aujourd’hui, la phrase « Later in 2025, we will align with MCP specification requirements for OAuth 2.1 support. » (plus tard en 2025, nous nous alignerons sur les exigences de la spécification MCP pour la prise en charge d’OAuth 2.1). C’est ce qui, sur cette page, ressemble le plus à un engagement de version, et cela nomme une année terminée depuis huit mois.

Comment vérifier un serveur soi-même, en trois commandes ?

Trois requêtes non authentifiées. Une minute, rien de touché, aucun compte requis.

Un. Demandez au point de terminaison ce qu’il protège.

curl https://mcp.braze.eu/.well-known/oauth-protected-resource

Ce sont les métadonnées de ressource protégée du RFC 9728 : l’identifiant canonique de la ressource, les portées que le serveur reconnaît et — la partie que tout le monde saute — le serveur d’autorisation auquel il délègue.

Deux. Suivez ce pointeur jusqu’au serveur d’autorisation et lisez ses métadonnées. J’ai exécuté cette commande contre HubSpot en août et j’ai raconté ce qui en revenait dans ce billet d’août ; voici la même vérification contre deux autres fournisseurs, après que la spécification a bougé sous eux tous. La seule chose à savoir est que le document ne vit pas toujours sur l’hôte MCP : mcp.braze.com/.well-known/oauth-authorization-server renvoie 404, parce que le document de ressource protégée de Braze pointe ailleurs.

Trois. Envoyez une requête non authentifiée et lisez le refus.

curl -i -X POST https://mcp.klaviyo.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -d '{"jsonrpc":"2.0","id":1,"method":"server/discover"}'

Le refus est le constat. Braze renvoie 401 avec WWW-Authenticate: Bearer resource_metadata="https://mcp.braze.com/.well-known/oauth-protected-resource/mcp", scope="mcp:tools mcp:resources mcp:operator", un défi RFC 9728 exemplaire qui remet au client le document de découverte et les portées exactes dont il a besoin. Klaviyo renvoie 401 avec error="invalid_token", HubSpot 401 en nommant ses propres métadonnées de ressource, et aucun des quatre points de terminaison n’a renvoyé d’en-tête MCP-Protocol-Version. Envoyer tools/list avec une version délibérément impossible, 1999-01-01, renvoie aussi 401, et non UnsupportedProtocolVersionError. L’autorisation est évaluée avant la négociation de version, ce qui est le comportement correct — et c’est aussi la raison pour laquelle la question de l’acheteur n’a pas de réponse avant la vente.

Ma deuxième correction s’adresse à mes notes, non à un fournisseur. Mon relevé de plus tôt aujourd’hui montrait le chemin /mcp de HubSpot renvoyant 404, ce qui ressemble à un constat sans en être un. Le guide d’intégration de HubSpot dit de se connecter « to the HubSpot MCP server at https://mcp.hubspot.com » (au serveur MCP de HubSpot à https://mcp.hubspot.com) — la racine, sans segment de chemin — et une requête POST à cette adresse renvoie 401 avec un défi en bonne et due forme. Un 404 sur une sonde MCP signifie presque toujours que vous avez deviné le chemin.

Le résultat côté Braze mérite son propre tableau : c’est la seule chose ici à laquelle je ne m’attendais pas.

Document récupéré le 16 septembre 2026	Émetteur	Point de terminaison de jeton	Point de terminaison d’enregistrement
`mcp.braze.com/.well-known/oauth-protected-resource`	nomme `https://dashboard.braze.com`	—	—
`mcp.braze.eu/.well-known/oauth-protected-resource`	nomme `https://dashboard.braze.com`	—	—
`dashboard.braze.com/.well-known/oauth-authorization-server`	`https://dashboard.braze.com`	`https://rest.iad-01.braze.com/oauth/token`	`https://rest.iad-01.braze.com/oauth/register`
`dashboard-01.braze.eu/.well-known/oauth-authorization-server`	`https://dashboard-01.braze.eu`	`https://rest.fra-01.braze.eu/oauth/token`	aucun

Relisez les deux premières lignes. Les points de terminaison MCP américain et européen nomment le même serveur d’autorisation, dont le point de terminaison de jeton est un hôte rest.iad-01.braze.com. Un serveur d’autorisation européen distinct existe à dashboard-01.braze.eu avec un point de terminaison de jeton à Francfort, mais rien dans le document de découverte du point de terminaison européen n’y dirige un client.

Soyons précis, parce que c’est le genre de constat que l’on répète mal. Une découverte OAuth et un échange de jeton ne sont pas des données clients. La documentation de Braze indique que les outils exposant des renseignements personnels ne sont pas disponibles, et qu’« Either endpoint can reach any Braze cluster. » Ce que j’ai vérifié est un fait sur une chaîne de découverte : un client qui suit les métadonnées publiées par le point de terminaison européen est dirigé vers le tableau de bord de marque américaine. Je n’ai établi ni où les données clients sont stockées, ni la moindre exposition réglementaire de qui que ce soit. C’est une question à poser à Braze, pas une réponse.

Que dit la posture d’enregistrement d’un fournisseur sur l’horloge de douze mois ?

Plus que la révision du protocole. Vous ne pouvez pas connaître la révision d’un serveur avant de vous authentifier ; vous pouvez connaître sa posture d’enregistrement en une commande, et l’enregistrement est là où la révision du 28 juillet a bougé.

Klaviyo annonce l’enregistrement dynamique et nie explicitement son remplaçant. Un registration_endpoint actif à mcp.klaviyo.com/register, et client_id_metadata_document_supported: false. Publier ce champ à false est une décision, pas un oubli.
Braze annonce l’enregistrement dynamique dans une région et aucun mécanisme dans l’autre. Aucun des deux documents de métadonnées de Braze ne contient de champ client_id_metadata_document_supported.
HubSpot n’annonce ni l’un ni l’autre, exactement comme le 21 août. Cette posture et ses conséquences sont le sujet du billet d’août, et je ne vais pas les redémontrer ici.

Maintenant l’horloge, avec prudence. Le plancher est d’au moins douze mois à compter de la dépréciation, avec une exception accélérée de quatre-vingt-dix jours, et le retrait viendra dans « une version future » que personne n’a nommée. La date la plus proche à laquelle l’enregistrement dynamique deviendrait ordinairement éligible au retrait est donc la fin de juillet 2027. Rien ne casse ce trimestre ni le prochain.

C’est précisément le point. C’est une question d’engagement de maintenance plutôt que de sécurité ou d’urgence, et la moins coûteuse à poser pendant une évaluation : un fournisseur qui annonce un mécanisme déprécié sans position publique sur son remplaçant porte un travail de migration qu’il n’a pas planifié publiquement. Vous demandez si l’équipe derrière le point de terminaison suit la spécification, et cela vous dit à quoi ressembleront trois ans de maintenance d’intégration.

Deux signaux plus modestes tombent des mêmes métadonnées et exigent de la mesure. Annoncer "none" comme méthode d’authentification au point de terminaison de jeton, comme le font Klaviyo et les deux serveurs de Braze, est ordinaire sous OAuth 2.1 pour les clients publics incapables de détenir un secret. Klaviyo annonce aussi "plain" aux côtés de "S256" dans code_challenge_methods_supported, ce qui n’équivaut pas à l’utiliser, mais cela mérite une ligne dans un questionnaire fournisseur.

Qu’est-ce qu’enregistrer des outils d’agent sur mon propre site m’a appris là-dessus ?

Que la version honnête de cette vérification a un trou, et que je me tiens dedans. Ce site expose des outils aux agents par WebMCP, enregistrés dans le navigateur avec document.modelContext.registerTool(), et chaque outil porte annotations: { readOnlyHint: true }, ce que je livre de plus proche d’une déclaration publique sur ce que la surface peut faire. Appliquez maintenant la procédure de ce billet contre moi. Il n’y a pas de .well-known/oauth-protected-resource à récupérer, puisqu’il n’y a pas d’OAuth devant un outil de navigateur. Il n’y a pas de point de terminaison où envoyer une requête. Et nulle part je n’indique quelle révision du protocole visent mes définitions d’outils. Mes outils ne lisent que des pages déjà publiques en deux formats, l’enjeu n’est donc pas le même, mais l’omission l’est : je fais exactement ce que j’ai passé la matinée à relever chez trois fournisseurs.

Six questions à mettre dans un appel d’offres à la place de « prenez-vous en charge MCP ? »

À poser dans l’ordre. Chacune nomme la défaillance qu’elle prévient.

Quelle révision de la spécification MCP votre serveur met-il en œuvre aujourd’hui, et où est-ce écrit ? Échoue parce que « nous prenons en charge MCP » nomme une famille de protocoles, pas une révision. Un serveur bâti sur une révision antérieure et un serveur bâti sur 2026-07-28 sont deux projets d’intégration différents portant les mêmes trois lettres.
Votre serveur met-il en œuvre server/discover, et est-il joignable avant authentification ? Échoue en silence. La page de versionnage le décrit comme « a mandatory RPC » (un appel obligatoire) côté serveur, mais ajoute que « Calling it is optional » (son appel est facultatif) côté client, et rien n’oblige un serveur à y répondre sans jeton : les quatre points de terminaison sondés aujourd’hui ont renvoyé 401. Exigez plutôt la révision par écrit.
Quel mécanisme d’enregistrement client votre serveur d’autorisation annonce-t-il, et quelle est votre position publiée sur les Client ID Metadata Documents ? Échoue quand vous héritez d’une voie dépréciée sans migration datée. Les métadonnées de Klaviyo y répondent par client_id_metadata_document_supported: false ; la plupart n’auront écrit la réponse nulle part, ce qui est déjà une réponse.
Quelles méthodes d’authentification au point de terminaison de jeton et quelles méthodes PKCE annoncez-vous ? Échoue au moment de l’intégration, pas de l’évaluation, et sur le client que vous avez déjà normalisé. Trois fournisseurs, trois listes différentes, et un client qui n’en parle qu’une seule ne peut pas se connecter.
Quels points de terminaison régionaux existent, et que nomme le document de découverte de chacun comme serveur d’autorisation ? Échoue sur l’hypothèse qu’un point de terminaison régional garde tout le flux régional. Les deux points de terminaison MCP de Braze nomment aujourd’hui le même serveur d’autorisation, ce qui mérite une réponse écrite du fournisseur plutôt qu’une déduction de votre part.
Quels contrôles de lecture seule ou de restriction d’outils existent, et sont-ils appliqués côté serveur ou fixés par le client ? Échoue là où personne ne regarde. Le read-only=true de Klaviyo est un paramètre dans le fichier de configuration d’un client ; quiconque modifie ce fichier le contrôle, et la documentation de Klaviyo note que ces paramètres « can’t be controlled with the listed Claude connector or the listed ChatGPT app » (ne peuvent pas être contrôlés avec le connecteur Claude ni l’application ChatGPT répertoriés) : la configuration la plus sûre n’est accessible que par la voie d’installation la plus manuelle.

Les questions un, trois et cinq sont les trois que je garderais. La grille pondérée de planifier une pile martech avant d’acheter des outils est l’endroit où elles vivent dans une vraie évaluation, les questions d’intégration de CDP, CRM et automatisation marketing en sont les cousines plus âgées, et l’évaluation interactive de pile martech couvre l’architecture qui les entoure.

Mon avis de travail

La révision du protocole n’est pas le risque, quoi qu’invite à croire un billet qui s’ouvre sur la sortie d’une spécification. Rien n’est cassé ici, rien ne cessera de fonctionner cette année, et l’enregistrement dynamique tiendra encore dix mois selon le plancher ordinaire de douze mois de la spécification.

Le constat, c’est l’impossibilité de répondre. Sept semaines après la révision la plus perturbatrice qu’ait connue ce protocole, un acheteur ne peut pas déterminer quelle révision parle le serveur d’un fournisseur martech sans posséder un compte, et le mécanisme prévu par la spécification pour y répondre se trouve derrière l’authentification sur chaque point de terminaison essayé. C’est une décision d’ingénierie raisonnable prise indépendamment par trois équipes, et son effet agrégé est que « prenez-vous en charge MCP ? » est devenue une question infalsifiable dans un processus d’approvisionnement. Le correctif n’est pas du côté fournisseur de la table : c’est de poser une question dont la réponse se vérifie. La question qui suit la posture est le prix, et les grilles tarifaires y répondent de façon encore moins stable que la documentation ne répond à celle-ci. Je les ai lues dans combien coûte vraiment une action d’agent IA.

Ce que je ne sais pas, c’est si l’un de ces serveurs met en œuvre 2026-07-28. Je supposerais que la plupart le font ou le feront bientôt, puisque les SDK de premier rang sont sortis avec la révision, mais une supposition ne vaut rien ici. Je ne sais pas non plus si le client_id_metadata_document_supported: false de Klaviyo traduit une décision ou une valeur par défaut de bibliothèque. Seul Klaviyo peut le dire.

Ce qui changerait mon avis, c’est qu’un fournisseur publie une ligne de version. Si l’un des trois ajoute une phrase nommant une révision, le tableau ci-dessus gagne un « oui », et la question intéressante devient celle de savoir si quelqu’un la tiendra à jour. C’est un meilleur problème que celui que nous avons.

Foire aux questions sur la vérification du serveur MCP d’un fournisseur

Le serveur MCP de Klaviyo prend-il en charge la spécification MCP 2026-07-28 ?

Klaviyo ne le dit pas, au 16 septembre 2026. Sa documentation nomme l’URL, le transport et la méthode d’authentification — « OAuth (with dynamic client registration) » — mais aucune révision de protocole. Les métadonnées de son serveur d’autorisation déclarent client_id_metadata_document_supported: false, donc il n’offre pas le mécanisme d’enregistrement vers lequel cette révision s’est déplacée. C’est une déclaration sur l’enregistrement, pas sur la révision mise en œuvre.

Quelle version du protocole MCP le serveur de HubSpot utilise-t-il ?

Aucune page de HubSpot que j’ai pu trouver ne l’indique au 16 septembre 2026. La page d’aperçu MCP porte toujours « Later in 2025, we will align with MCP specification requirements for OAuth 2.1 support », une ligne de feuille de route sur une année terminée. Les métadonnées d’autorisation du serveur annoncent ["client_secret_post"] et le PKCE S256, et une requête non authentifiée vers https://mcp.hubspot.com renvoie 401 avec un défi RFC 9728 et aucun en-tête de version de protocole.

L’enregistrement dynamique de client est-il encore permis après la révision MCP de juillet 2026 ?

Oui. La spécification d’autorisation 2026-07-28 dit qu’il « is deprecated and retained for backwards compatibility », et l’annonce de sortie qu’il « continues to work for backward compatibility, but will be removed in a future version ». La politique de dépréciation accorde au moins douze mois, avec une exception accélérée de quatre-vingt-dix jours ; fin juillet 2027 est donc la première éligibilité ordinaire au retrait. Aucune date de retrait n’est nommée aujourd’hui. Le billet de feuille de route des mainteneurs, daté du 22 août 2026, n’en nomme aucune non plus.

Peut-on savoir quelle révision MCP parle un serveur sans compte ?

Pas sur les quatre points de terminaison testés le 16 septembre 2026. La spécification définit server/discover comme « a mandatory RPC that returns the server’s supported protocol versions, capabilities, and identity » (un appel obligatoire renvoyant versions, capacités et identité du serveur), mais précise aussi que « Calling it is optional » côté client, et Braze, Klaviyo et HubSpot renvoient tous 401 sans authentification. Une version non prise en charge renvoie également 401 plutôt qu’une UnsupportedProtocolVersionError. L’autorisation passe en premier ; la réponse n’existe qu’une fois le compte ouvert.

Le point de terminaison MCP européen de Braze garde-t-il tout en Europe ?

Au 16 septembre 2026, ce n’est pas ce que j’ai vérifié. mcp.braze.com et mcp.braze.eu publient tous deux des métadonnées de ressource protégée nommant https://dashboard.braze.com comme serveur d’autorisation, dont le point de terminaison de jeton est https://rest.iad-01.braze.com/oauth/token ; un serveur dashboard-01.braze.eu distinct existe avec un point de terminaison de jeton à Francfort. Un échange OAuth n’est pas une donnée client, et la documentation de Braze dit que l’un ou l’autre point de terminaison peut atteindre n’importe quelle grappe. Posez la question de la résidence directement à Braze.

Sources utilisées

Vérifié à la source : 16 septembre 2026.

Réponse courte

Qu’a changé la spécification MCP le 28 juillet 2026, et pourquoi un acheteur devrait-il s’en soucier ?

Quelle révision Braze, Klaviyo et HubSpot disent-ils mettre en œuvre ?

Comment vérifier un serveur soi-même, en trois commandes ?

Que dit la posture d’enregistrement d’un fournisseur sur l’horloge de douze mois ?

Qu’est-ce qu’enregistrer des outils d’agent sur mon propre site m’a appris là-dessus ?

Six questions à mettre dans un appel d’offres à la place de « prenez-vous en charge MCP ? »