How Do You Check a Martech Vendor’s MCP Server?

One line of JSON is the reason this post exists. I fetched it this morning, from a marketing platform a lot of e-commerce teams already pay for.

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

Among the ordinary endpoints in the response sits "client_id_metadata_document_supported": false.

In plain terms: Klaviyo’s MCP server is telling every client that asks that it does not support the client registration mechanism the Model Context Protocol moved to seven weeks ago, and that clients should use the one the same revision deprecated. That is not a leak or a gotcha. It is a public, machine-readable statement of posture, and on September 16, 2026 it is the closest thing to a straight answer any of the three martech vendors I checked will give you before you authenticate.

I should say what this post is and is not. I have not connected a vendor’s MCP server to a client environment, and this is not a security assessment of anybody’s product. It is a procurement question with a procedure attached: which revision of the protocol is the vendor selling, and how do you find out before you sign. Everything below was verified at its primary source on September 16, 2026 — three vendor documentation pages, two specification pages, and unauthenticated requests I ran myself. Where a source disagreed with my notes, the source won. That happened twice.

The one thing I have first-hand is the other side of the counter. This site registers agent tools of its own, which is how I found out that the check below would not work on me either.

Quick answer

As of September 16, 2026, none of Braze, Klaviyo or HubSpot states in its documentation which revision of the Model Context Protocol its server implements, and none discloses one at its endpoint before authentication. The July 28, 2026 revision defines a direct way for a client to ask a server its version, but every endpoint I tested today answers with an authentication error first. The clearest signal available is Klaviyo’s own server metadata, which reports that it does not support the client registration mechanism that revision moved to, and offers the one it deprecated. So checking a vendor takes three unauthenticated commands and about a minute, and the right procurement question is not "do you support MCP" — it is which revision, and how you can verify it yourself.

Every fact here has a verification date of September 16, 2026 and a shelf life measured in weeks. Vendor metadata documents change without a changelog entry, and two of the three pages below carry no usable published date at all.

What changed in the MCP specification on July 28, 2026, and why should a buyer care?

The Model Context Protocol shipped a revision on July 28, 2026 that retired the handshake, deprecated Dynamic Client Registration and set the protocol’s first formal deprecation policy. The announcement, by lead maintainers David Soria Parra and Den Delimarsky, describes a stateless core: "we’ve officially retired the initialize/initialized exchange," and "Each request now travels on its own, carrying its protocol version, client identity, and client capabilities in _meta." On Streamable HTTP, the versioning page adds, that value is "also carried in the MCP-Protocol-Version header". So there is no handshake left to read a version from: either a version travels with the request, or nobody states one.

Registration moved in the same release: "Dynamic Client Registration itself is now formally deprecated in favor of CIMD." The August post on what AI agents can do in your ad accounts and CRM works through that mechanism in full, so I will not re-derive it here. What is new for a buyer’s timeline is a published clock: deprecated features "remain in the specification for at least twelve months," with a ninety-day expedited-removal exception, and removal comes "in a future version" the announcement does not name.

Here is my first correction. My working note said the July 28 revision removed the handshake and therefore any way to read a server’s version. Wrong on the second half: the handshake was replaced by per-request metadata, not by nothing, and a separate server/discover RPC exists for clients that want to ask up front, though the versioning page adds that "Calling it is optional" for the client. The question did not become unanswerable; on these servers the answer sits behind the authorization wall, and a buyer running an evaluation does not yet have an account.

Which revision do Braze, Klaviyo and HubSpot say they implement?

None of them, in writing, anywhere I could find. Every cell below was read off a vendor page or an unauthenticated HTTP response on September 16, 2026.

Vendor	MCP endpoint	Doc states a revision?	Registration advertised	`token_endpoint_auth_methods_supported`	PKCE methods	Documented read-only switch	Regional endpoints	Usable doc date
Braze	`mcp.braze.com/mcp`, `mcp.braze.eu/mcp`	No	`registration_endpoint` on the US authorization server, none on the EU one	`["none"]` on both	`S256`	Not documented; access mirrors the dashboard user	US and EU	Release note July 23, 2026, "Early access"
Klaviyo	`mcp.klaviyo.com/mcp`	No	`registration_endpoint`, plus `client_id_metadata_document_supported: false`	`client_secret_basic`, `client_secret_post`, `none`	`plain`, `S256`	Yes, `read-only=true` as a URL query parameter	Not documented	Connection page shows "Updated 12 days ago"; the overview page was restructured and shows "Updated 1 day ago"
HubSpot	`mcp.hubspot.com`	No	Neither mechanism, unchanged since August 21	`["client_secret_post"]`	`S256`	Not documented	Not documented	None — the page’s `last-updated` meta tag holds the unrendered token `%2026-%0-%4`

Two columns need a warning. "Doc states a revision" means I searched each page for "protocol", "specification", "version" and "2026-" and found no sentence naming one. It does not mean the server fails to implement 2026-07-28, a negative nobody outside the vendor can prove and not the claim here. The metadata columns describe what an authorization server advertises, not what a client negotiates.

What each vendor does say is worth reading closely.

Braze launched its remote server in the July 23, 2026 release note, labelled "Early access". The documentation page describes "a secure remote connection that lets AI tools like Claude and Cursor access non-PII Braze data," warns that "Tools that expose user-level PII are not available," and answers the regions question with "Either endpoint can reach any Braze cluster." No sentence states a protocol revision.

Klaviyo publishes the most useful documentation of the three. Its connection page names the URL, the transport ("Transport: Streamable HTTP") and, in the same block, "Authentication method: OAuth (with dynamic client registration)". That is the only place any of the three describes its registration mechanism in prose, and it names the deprecated one. Klaviyo also documents six query parameters that shape the tool surface, including read-only, which "disables any tools which can perform write actions on your Klaviyo account". No protocol revision appears.

HubSpot still carries, today, the sentence "Later in 2025, we will align with MCP specification requirements for OAuth 2.1 support." It is the closest thing on the page to a version commitment, and it names a year that ended eight months ago.

How do you check a server yourself, in three commands?

Three unauthenticated requests. About a minute, nothing touched, no account needed.

One. Ask the endpoint what it protects.

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

This is RFC 9728 protected-resource metadata: the canonical resource identifier, the scopes the server recognises, and — the part people skip — which authorization server it delegates to.

Two. Follow that pointer to the authorization server and read its metadata. I ran this command against HubSpot in August and wrote up what came back in that August post; this is the same check against two more vendors, after the specification moved under all of them. The one thing to know is that the document does not always live on the MCP host: mcp.braze.com/.well-known/oauth-authorization-server returns 404, because Braze’s protected-resource document points somewhere else.

Three. Send one unauthenticated request and read the rejection.

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"}'

The rejection is the finding. Braze returns 401 with WWW-Authenticate: Bearer resource_metadata="https://mcp.braze.com/.well-known/oauth-protected-resource/mcp", scope="mcp:tools mcp:resources mcp:operator", a textbook RFC 9728 challenge handing a client the discovery document and the exact scopes it needs. Klaviyo returns 401 with error="invalid_token", HubSpot 401 naming its own resource metadata, and not one of the four endpoints returned an MCP-Protocol-Version header. Sending tools/list with a deliberately impossible version of 1999-01-01 also returns 401, not UnsupportedProtocolVersionError. Authorization is evaluated before version negotiation, which is correct behaviour and also why the buyer’s question has no pre-sales answer.

My second correction is to my own notes, not to a vendor. My probe from earlier today recorded HubSpot’s /mcp path returning 404, which reads like a finding and is not one. HubSpot’s integration guide says to connect "to the HubSpot MCP server at https://mcp.hubspot.com" — the root, no path segment — and POSTing there returns 401 with a proper challenge. A 404 on an MCP probe almost always means you guessed the path.

The Braze result deserves its own table; it is the one thing here I did not expect.

Document fetched, September 16, 2026	Issuer	Token endpoint	Registration endpoint
`mcp.braze.com/.well-known/oauth-protected-resource`	names `https://dashboard.braze.com`	—	—
`mcp.braze.eu/.well-known/oauth-protected-resource`	names `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`	none

Read the first two rows again. Both the US and the EU MCP endpoints name the same authorization server, whose token endpoint is a rest.iad-01.braze.com host. A separate European authorization server exists at dashboard-01.braze.eu with a Frankfurt token endpoint, but nothing in the EU endpoint’s discovery document points a client at it.

Be exact about what that means, because this kind of finding gets repeated badly. An OAuth discovery and token exchange is not customer data. Braze’s documentation says tools exposing user-level PII are not available, and says "Either endpoint can reach any Braze cluster." What I verified is a fact about a discovery chain: a client following the EU endpoint’s published metadata is directed to the US-branded dashboard. I have not established where customer data is stored or processed, and I am not characterising anyone’s regulatory exposure. It is a question to ask Braze, not an answer.

What does a vendor’s registration posture tell you about the twelve-month clock?

More than the protocol revision does. You cannot learn a server’s revision before you authenticate; you can learn its registration posture in one command, and registration is where the July 28 revision moved.

Klaviyo advertises Dynamic Client Registration and explicitly denies the replacement. A live registration_endpoint at mcp.klaviyo.com/register, and client_id_metadata_document_supported: false. Publishing that field as false is a decision, not an oversight.
Braze advertises Dynamic Client Registration on one region and no registration mechanism on the other. Neither Braze metadata document contains a client_id_metadata_document_supported field at all.
HubSpot advertises neither, exactly as it did on August 21. That posture and its consequences are the subject of the August post, and I am not going to re-derive them here.

Now the clock, carefully. The floor is at least twelve months from deprecation, with a ninety-day expedited exception, and removal comes "in a future version" that nobody has named. The earliest ordinary date on which Dynamic Client Registration becomes eligible for removal is late July 2027. Nothing breaks this quarter or next.

That is the point. This is a maintenance-commitment question rather than a security or urgency question, and the cheapest one to ask during an evaluation: a vendor advertising a deprecated mechanism with no published position on its replacement is carrying migration work it has not scheduled in public. You are asking whether the team behind the endpoint tracks the specification, and that tells you what three years of integration maintenance will feel like.

Two smaller flags fall out of the same metadata and need proportion. Advertising "none" as a token endpoint auth method, as Klaviyo and both Braze servers do, is ordinary under OAuth 2.1 for public clients that cannot hold a secret. Klaviyo also advertises "plain" beside "S256" in code_challenge_methods_supported, which is not the same as using it, but it earns a line in a vendor questionnaire.

What did registering agent tools on my own site teach me about asking this?

That the honest version of this check has a hole in it, and I am standing in it. This site exposes tools to agents through WebMCP, registered in the browser with document.modelContext.registerTool(), and each tool carries annotations: { readOnlyHint: true }, the closest thing I ship to a public statement of what the surface can do. Now run this post’s procedure against me. There is no .well-known/oauth-protected-resource to fetch, because there is no OAuth in front of a browser-side tool. There is no endpoint to POST to. And nowhere do I state which revision of the protocol my tool definitions target. My tools only read pages that are already public in two formats, so the stakes are not the same, but the omission is: I am doing exactly what I spent this morning noting that three vendors do.

Six questions to put in an RFP instead of "do you support MCP?"

Ask these in order. Each names the failure it prevents.

Which revision of the MCP specification does your server implement today, and where is that stated in writing? Fails because "we support MCP" names a protocol family, not a revision. A server built to an earlier revision and one built to 2026-07-28 are different integration projects wearing the same three letters.
Does your server implement server/discover, and is it reachable before authentication? Fails silently. The versioning page calls it "a mandatory RPC" for servers but adds that "Calling it is optional" for clients, and nothing obliges a server to answer it without a token: all four endpoints I probed today returned 401. Get the revision in writing instead.
Which client registration mechanism does your authorization server advertise, and what is your published position on Client ID Metadata Documents? Fails when you inherit a deprecated path with no dated migration. Klaviyo’s metadata answers it with client_id_metadata_document_supported: false; most vendors will not have written the answer anywhere, which is itself the answer.
Which token endpoint authentication methods and PKCE methods do you advertise? Fails at integration time, not evaluation time, and on the client you already standardised on. Three vendors, three different lists, and a client that speaks only one of them cannot connect.
Which regional endpoints exist, and what does each endpoint’s discovery document name as its authorization server? Fails on the assumption that a regional endpoint keeps the whole flow regional. Both of Braze’s MCP endpoints name the same authorization server today, which deserves a written answer from the vendor rather than an inference from you.
Which read-only or tool-scoping controls exist, and are they enforced server-side or set by the client? Fails where nobody looks. Klaviyo’s read-only=true is a query parameter in a client’s configuration file, so whoever edits that file controls it, and Klaviyo’s documentation notes those parameters "can’t be controlled with the listed Claude connector or the listed ChatGPT app" — the safest configuration is only available through the more manual setup path.

Questions one, three and five are the three I would keep. The weighted scorecard in how to plan a martech stack before buying tools is where they belong on a real evaluation, the integration questions in CDP vs. CRM vs. marketing automation are their older cousins, and the interactive martech stack assessment covers the surrounding architecture.

My working take

The protocol revision is not the risk, whatever a post opening on a specification release invites you to assume. Nothing here is broken, nothing stops working this year, and Dynamic Client Registration is good for another ten months under the specification’s ordinary twelve-month floor.

The finding is the unanswerability. Seven weeks after the most disruptive revision this protocol has had, a buyer cannot determine which revision a martech vendor’s server speaks without an account, and the specification’s own mechanism for answering that is behind the login on every endpoint I tried. That is a reasonable engineering decision made independently by three teams, and its aggregate effect is that "do you support MCP?" has become an unfalsifiable question inside a procurement process. The fix is not on the vendors’ side of the table: it is to ask a question with a checkable answer. The question after posture is price, and the rate cards answer it even less stably than the documentation answers this one. I read them in what one AI agent action actually costs.

What I do not know is whether any of these servers implements 2026-07-28. I would guess most do or soon will, since the Tier 1 SDKs shipped with the revision, but a guess is worth nothing here. Nor do I know whether Klaviyo’s client_id_metadata_document_supported: false reflects a decision or a library default. Only Klaviyo can say.

What would change my take is one vendor publishing a version line. If any of the three adds a sentence naming a revision, the table above gains a "yes", and the interesting question becomes whether anyone keeps it current. That is a better problem than the one we have.

Frequently asked questions about checking a vendor’s MCP server

Does Klaviyo’s MCP server support the 2026-07-28 MCP specification?

Klaviyo does not say, as of September 16, 2026. Its documentation names the URL, the transport and the authentication method — "OAuth (with dynamic client registration)" — but no protocol revision. Its authorization server metadata declares client_id_metadata_document_supported: false, so it does not offer the registration mechanism that revision moved to. That is a statement about registration, not about the revision implemented.

Which MCP protocol version does HubSpot’s MCP server use?

Not stated on any HubSpot page I could find on September 16, 2026. The MCP overview page still says "Later in 2025, we will align with MCP specification requirements for OAuth 2.1 support," a roadmap line about a year that has ended. The server’s authorization metadata advertises ["client_secret_post"] and PKCE S256, and an unauthenticated request to https://mcp.hubspot.com returns 401 with an RFC 9728 challenge and no protocol version header.

Is Dynamic Client Registration still allowed after the July 2026 MCP revision?

Yes. The 2026-07-28 authorization specification says it "is deprecated and retained for backwards compatibility," and the release announcement says it "continues to work for backward compatibility, but will be removed in a future version." The deprecation policy gives deprecated features at least twelve months, with a ninety-day expedited exception, so late July 2027 is the earliest ordinary removal eligibility. No named removal date exists today, and the maintainers’ August 22, 2026 roadmap post names none either.

Can I tell which MCP revision a server speaks without an account?

Not on the four martech endpoints I tested on September 16, 2026. The specification defines server/discover as "a mandatory RPC that returns the server’s supported protocol versions, capabilities, and identity", though the same page adds that "Calling it is optional" for a client, and Braze, Klaviyo and HubSpot all return 401 to it unauthenticated. Sending a deliberately unsupported version also returns 401 rather than an UnsupportedProtocolVersionError. Authorization is evaluated first, so the answer exists only after you have an account.

Does Braze’s EU MCP endpoint keep everything in Europe?

As of September 16, 2026, that is not what I verified. Both mcp.braze.com and mcp.braze.eu publish protected-resource metadata naming https://dashboard.braze.com as their authorization server, whose token endpoint is https://rest.iad-01.braze.com/oauth/token; a separate dashboard-01.braze.eu server exists with a Frankfurt token endpoint. An OAuth exchange is not customer data, and Braze’s documentation says either endpoint can reach any cluster. Ask Braze about residency directly.

Sources I used

Verified at source: September 16, 2026.