MCP 2026-07-28 and auth.md

What the new spec means for agent authentication

Published July 4, 2026

TL;DR — MCP now mandates OAuth 2.1, removes sessions, and drops the initialization handshake. auth.md fills the gap MCP leaves open: how does an agent discover that a service exists and register for it in the first place?

What changed in MCP 2026-07-28

This is not a patch. The new MCP spec broke everything that matters about how agents authenticate — and rebuilt it from scratch on top of OAuth 2.1.

Sessions are dead

No more session tokens. No more session lifecycle. Every request now carries its own auth context via bearer tokens. Simpler, but your existing MCP integrations will break.

The initialize handshake is gone

Connect and authenticate in one step. The two-phase dance was always friction — now it's history.

OAuth 2.1, for real this time

Resource Indicators (RFC 8707), issuer verification, Protected Resource Metadata (RFC 9728). No more halfway OAuth implementations that skip the hard parts.

Three things you relied on are deprecated

Dynamic Client Registration, custom token formats, and client-side session management. If you were using DCR to onboard agents — that path is closing.

Extensions are how this grows now

New extension framework for profile-specific additions. auth.md is exactly the kind of registration layer that plugs in here — without forking MCP itself.

The gap MCP leaves open

MCP tells an agent how to authenticate once it already has credentials. But it never answers the obvious question: where do the credentials come from?

auth.md answers all three. One file, one protocol, and the agent has a path from "never heard of this service" to "authenticated and calling the API."

How auth.md complements MCP

LayerMCP handlesauth.md handles
Discovery—RFC 9728 PRM + AS metadata + /auth.md file
Registration—/agent/identity endpoint (3 types)
User Consent—RFC 8628-style claim ceremony
Token ExchangeOAuth 2.1 bearer tokensRFC 7523 JWT-bearer grant
AuthorizationOAuth 2.1 + Resource IndicatorsScopes declared in AS metadata
Revocation—RFC 7009 + RFC 8935 SET delivery

Put simply: MCP is the plumbing — how agents talk to servers once connected. auth.md is the front door — how agents get in.

The discovery trifecta

Three files at your domain root. That's it. That's what makes a service fully agent-ready.

/robots.txt

What can be crawled

/llms.txt

What can be read

/auth.md

How to register

What this means for your service

If you are building an MCP server or an API that agents will consume:

  1. Publish a /auth.md file — tells agents how to register for your service without a browser
  2. Expose RFC 9728 Protected Resource Metadata — agents discover your auth server via the standard /.well-known/oauth-protected-resource path
  3. Support at least one identity type — identity_assertion (zero-friction with a trusted provider), service_auth (email-based), or anonymous (no identity upfront)
  4. Implement the token exchange — RFC 7523 JWT-bearer grant at /oauth2/token

One command. No forms to fill. The auth-md skill generates a complete auth.md file and Protected Resource Metadata from your codebase.

Install the Skill

Or read the full specification

References