The 2026-07-28 version of MCP is stateless, adds a mandatory discovery request, and deprecates sampling and protocol level logging. For a buyer, that means a connector's behavior is easier to reason about per request, but you should confirm which protocol version a vendor supports and where its logs go.
The changes that matter
This summary comes from the current architecture overview, which describes protocol version 2026-07-28. Check the specification for the full list, because this is not a complete changelog.
- Stateless requests. Every request carries the protocol version and the capabilities relevant to it, so a server can process each one without relying on earlier requests.
- Discovery. Servers advertise supported versions and capabilities through a mandatory discover request. Clients may send it before anything else.
- Sampling deprecated. Sampling let a server ask the client's model for a completion. The page says new implementations should integrate directly with model provider APIs.
- Logging deprecated. The page says new implementations should log to standard error for local servers or use OpenTelemetry.
- Opt in change notices. Clients open a subscription stream to receive tool list changes.
What each means for you
| Change | Buyer impact |
|---|---|
| Stateless | Fewer hidden session assumptions, but each call must carry authorization |
| Discover request | Version and capability checks become routine |
| Sampling deprecated | Fewer cases where a server drives your model, which reduces one risk path |
| Logging guidance | Ask the vendor about OpenTelemetry and audit logs, not protocol log messages |
| Subscriptions | Tool list changes still need your own review routine |
Why the sampling change is relevant
Sampling gave servers a way to request model completions through the client, which raised questions about who controls the model's input. Moving away from it narrows that path. Treat it as one less thing to review, not as a guarantee, since servers can still return text that influences the model.
Questions to ask
- Which protocol versions does the connector support?
- Does it rely on any deprecated feature?
- How do you produce audit logs, given the logging guidance?
- How do you handle clients that speak an older version? The page says a server rejects an unsupported version with an error that lists the versions it does accept.
What did not change
The security basics still apply: tools are model controlled, there should be a human able to deny calls, annotations are untrusted, servers must validate input and sanitize output, and tokens must be issued for the server that receives them.
How to use this in a procurement conversation
You do not need to memorize protocol details. Ask the vendor to state in writing which protocol version the connector implements, whether any deprecated feature is in use, and how it plans to move to newer versions. A vendor that can answer in a sentence has probably thought about it.
Also ask which chat apps they have tested the connector with. A server can be correct for the specification and still behave differently across clients, for example in how a client caches the tool list or handles subscriptions. Ask to see the tool list as each client displays it, and compare.
A worked example: reading the discovery response
The architecture overview includes an example discovery exchange. In plain words, a client sends a request that carries the protocol version, its own name and the capabilities it supports. The server answers with the versions it supports, its capabilities and its name and version. In the example the server declares that it supports tools, and that it can notify clients when the tool list changes. It also supports resources.
What does a buyer learn from this? Three things. The server can state which protocol versions it speaks, so you can ask for that in writing. The server declares whether it offers tools, resources or prompts, which tells you what to review. And the response can say how long it may be cached, so a client may not ask again for a while.
Step by step: a version check for a pilot
- Ask the vendor which protocol version their connector implements.
- Ask the chat provider which versions its app supports for custom connectors. Provider documentation may not say, so ask in writing.
- If the versions differ, ask what happens. The architecture page says a server rejects an unsupported version with an error that lists the versions it supports, and the client can retry.
- Test the connection and note any error.
- Ask the vendor about deprecated features in use.
- Record the answers with dates.
- Repeat at renewal.
Table: old assumption versus current description
| Topic | Older assumption | Current description |
|---|---|---|
| State | A connection holds session state | Each request carries what the server needs |
| Capability discovery | Negotiated at connection start | Discover request, optional, cacheable |
| Server asks the model for text | Sampling available | Deprecated, new work should call model providers directly |
| Server log messages to clients | Protocol logging | Deprecated, use standard error or OpenTelemetry |
| Change notices | Always on | Opt in through a subscription stream |
Treat this as a reading aid and confirm the details in the specification, because specifications get revised.
What stays the same for security review
Whether the protocol is stateless or not, you still need to know who can call each tool, with what scopes, with what logging. The specification continues to say there should be a human able to deny tool calls, that annotations are untrusted unless the server is trusted, and that servers must validate inputs, enforce access controls, rate limit and sanitize outputs.
Why stateless helps reviewers a little
When each request carries what the server needs, a reviewer can reason about a single request without wondering what an earlier request set up. The specification also gives guidance for servers that need to carry state between calls: use explicit handles, validate the caller on every use, and do not treat a handle as proof of identity. That last point matters for audit, since a guessed handle must never open someone else's data.
Keep expectations realistic
Spec versions roll out unevenly. Some clients and servers lag. A connector that works today with an older version may need changes later. Ask for a support commitment in the contract, not only in marketing copy.
Where Safeguard fits
Safeguard offers an MCP Guardrail for policy on agent tool calls, independent of protocol version. Check protocol support details with the vendor directly. The free scan needs no connector at all.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice where the server declares what it supports, then think about how you would record that for your own review.
Quick check
Does a newer protocol version make a connector safe?
No. Security depends on authorization, scopes, tool design and your controls.
Where do I read the full change list?
In the official MCP specification pages. This post covers only what the architecture overview states.
Does a newer version mean my existing connector stops working?
Not necessarily. Servers can accept older versions, and the documentation describes a retry with a supported version. Ask the vendor about their plan.
Sources
Last reviewed: 19 October 2026.
