Preparing tool connectors for a stateless protocol: navigating new authorization and discovery patterns
Preparing stateless MCP connectors means replacing assumptions about a durable handshake with explicit information on every request: protocol version, client context, credentials, and the authorization context that determines what a caller can do. Connector teams that keep session-era assumptions risk failed onboarding, incomplete tool listings, and authorization behavior that changes unexpectedly across clients.
The practical design target is straightforward: make authentication and discovery independently repeatable, let tool visibility reflect the credentials attached to the current request, and preserve enough structured metadata for clients to make correct decisions without connection state. This approach fits hosted MCP deployments as well as enterprise integrations where human users and service accounts may reach the same connector.
What stateless MCP connectors must carry on each request
The MCP specification dated 2026-07-28 describes MCP as a stateless protocol: all information required to process a request is contained in that request. The implications are architectural, not merely transport-level. A connector can no longer assume that a prior initialization exchange, an authenticated socket, or server memory associated with a connection will supply context for the next tool call.
Recent MCP architecture documentation makes per-request _meta fields central to this model. Example tool calls include the protocol version, client information, and client capabilities in _meta. Updated architecture guidance also says clients should include their identity there, shifting identity and capability signaling from implicit connection state to explicit request data.
Direct answer: Build stateless MCP connectors so every request can be evaluated independently. Include the required MCP protocol and client context in
_meta, obtain and validate authorization per request, discover OAuth metadata through protected-resource and authorization-server documents, and filter the returned tool set based on the caller’s current permissions.
This does not mean a connector must discard all operational state. It can still use caches, durable configuration, audit records, rate-limit counters, and token-validation key caches. The distinction is that such data is not an unspoken substitute for request context. If the connector needs information to authorize or execute a specific call, it should receive that information directly, retrieve it from a durable source using request-scoped identifiers, or ask for it through a defined protocol interaction.
Separate durable service state from request state
A useful implementation boundary is to classify each piece of data before adding it to the connector. Durable service state belongs to the connector or platform: tenant configuration, tool definitions, authorization-server settings, approved policies, and cached discovery documents. Request state belongs in the request or is derived from its credentials: the client identity, supported capabilities, protocol version, user or workload principal, scopes, and the requested operation.
Carry protocol compatibility explicitly.
Read the protocol version provided with the request rather than inferring it from a prior exchange.
Carry client context explicitly.
Use the request’s
_meta
information for client identity and capabilities when making compatibility or interaction decisions.
Treat credentials as per-request input.
Do not regard a previously accepted token as proof that a later call is authorized.
Keep policy evaluation local to the call.
Resolve permissions for the current token, scope set, tenant, and requested tool.
Cache safely.
Cache public or appropriately protected metadata, but never let a cache turn one caller’s authorization result into another caller’s permission.
This separation is especially important for hosted, no-code MCP endpoints. A platform may manage scaling and observability centrally while serving many endpoints with different ownership and authorization policies. Stateless processing lets infrastructure scale requests without requiring a particular connection to remain pinned to one instance, but only if every instance can make the same decision from the request and durable configuration.
Design authorization for no-session MCP requests
In a stateful design, authorization is often treated as something completed at connection time. The server authenticates a client once, attaches a principal to the connection, and trusts subsequent calls to inherit that identity. That model is not sufficient for stateless MCP, where credentials are input to each request and a connector must make authorization decisions for each request it receives.
OpenAI’s current MCP connector documentation reflects this per-request handling: a token is provided in the MCP tool’s authorization field. The same documentation notes that connector_id is deprecated for models released after September 1, 2026. For connector builders, the broader lesson is to make request-level authorization explicit rather than tying correctness to a legacy connector identity mechanism or a long-lived transport association.
Normalize credentials before enforcing policy
Enterprise callers are not always homogeneous. The same connector may be called by an interactive human flow in one case and by a service-account workflow in another. Recent implementation analysis identifies dual-persona deployments as a concrete reason to normalize credentials across ers before policy evaluation.
A 2026 gap-analysis paper identifies single-er credential extraction as one of three enterprise shortcomings in MCP SDKs. Its proposed remedy is cross-er credential normalization. The exact ers and accepted credential forms remain a deployment decision, but the connector should create one internal authorization context before it evaluates scopes, tenant boundaries, tool permissions, or downstream identity propagation.
Extract supported credential inputs from the incoming request according to your deployment policy.
Validate the selected credentials against the configured issuer, audience, signature, expiry, and other applicable token requirements.
Normalize validated claims into a single internal principal model, including caller type where relevant.
Resolve the requested tool and its policy using that principal, the target tenant or resource, and the request parameters where policy requires them.
Return only the result, interaction requirement, or error appropriate for that individual request.
Normalization should not become credential guessing. Define precedence rules when multiple credentials are present, reject ambiguous combinations when necessary, and log the decision path without recording secrets. A predictable normalization layer is often preferable to scattering er parsing logic throughout individual tools.
Use multi-round trips when context is missing
A stateless connector should not manufacture a session just because a tool invocation lacks information needed for safe execution. Google Cloud’s MCP documentation says the 2026-07-28 release changed MCP from bidirectional and stateful to stateless, while adding multi-round-trip requests for situations in which a server needs more information for a tool.
This is a better recovery pattern than storing partial authorization or tool inputs in an opaque server-side session and hoping the same client returns to it. If the server needs clarification, a missing consent-related input, or more parameters for a tool, use the applicable multi-round-trip interaction. Each resulting request can still carry the context needed for its own processing.
The limit is clear: multi-round trips solve missing information, not weak authorization design. A connector still needs a deterministic policy for validating tokens and deciding whether a principal can access a tool or a particular resource.
Implement two-stage OAuth discovery for MCP authorization
Authorization discovery should be a first-class connector capability, not an installation note hidden in setup documentation. MCP authorization-server discovery is explicitly aligned with OAuth protected-resource metadata and authorization-server metadata. MCP guidance points implementers to RFC 9728 for protected-resource metadata and says clients should use RFC 9728 guidance when selecting an authorization server.
The practical flow is two-stage. First, identify the protected resource and obtain its metadata. Then use the authorization-server information from that metadata to retrieve authorization-server metadata. Microsoft’s MCP authorization guidance describes the protected resource exposing /.well-known/oauth-protected-resource under RFC 9728, with the authorization server publishing /.well-known/oauth-authorization-server under RFC 8414.
Start with the protected resource, not a guessed issuer
Starting at the resource matters because a connector endpoint is the thing a client intends to access. Protected-resource metadata tells the client which authorization server is relevant for that resource. It avoids requiring every user or client implementer to know an issuer URL, tenant-specific authorization endpoint, or registration process before they can begin onboarding.
Recent community implementation notes identify a practical pitfall: some clients look for protected-resource metadata before authorization-server metadata. If a connector skips the .well-known/oauth-protected-resource document and only documents an authorization server, an otherwise valid configuration can fail to provide the discovery path those clients expect.
Expose protected-resource metadata at the appropriate well-known location for the MCP resource.
Publish the authorization server or servers that protect that resource in the resource metadata.
Have the client retrieve authorization-server metadata from the selected authorization server.
Use the authorization-server metadata to locate supported authorization, token, and, where available, registration capabilities.
Acquire a token for the protected resource and send it with the request that needs access.
Keep discovery distinct from tool discovery and authorization decisions. A recent registry-architecture proposal makes this boundary explicit: DNS-based registry records are scoped to discovery, while authentication, authorization, and tool capability enumeration belong to other layers. The same discipline applies to connector design. A registry or endpoint directory may help a client find a server, but it does not determine what identity the caller has or what tools that identity may use.
Try the metadata endpoints needed for interoperability
Authorization metadata discovery is not always uniform across OAuth and OpenID Connect deployments. Recent MCP discovery guidance notes interoperability issues between OAuth Authorization Server Metadata and OpenID Connect Discovery and says MCP clients must attempt multiple well-known endpoints. A robust client implementation should account for that rather than assuming one metadata document name will work everywhere.
For connector operators, the complementary responsibility is to publish correct metadata for the authorization system in use and test discovery with the client ecosystems you expect to support. Do not rely only on a browser-based login test. Automated clients need machine-readable metadata, correct issuer relationships, and reachable endpoints.
Test direct access to protected-resource metadata from an unauthenticated client context.
Verify the authorization-server references returned by that metadata.
Test the relevant RFC 8414 and OpenID Connect discovery paths supported by the authorization server.
Validate that metadata endpoint URLs, issuer values, and registration details are internally consistent.
Monitor discovery failures separately from token failures and tool-execution failures.
This two-stage pattern is increasingly treated in vendor and platform guidance as the default enterprise onboarding path for AI connectors. It replaces one-off setup instructions with a process that lets clients self-configure from published metadata.
Use dynamic client registration without weakening connector security
Dynamic client registration is a practical fit for self-serve connector onboarding. RFC 7591 defines programmatic client registration, allowing a client to obtain a client_id and, optionally, a client_secret without manual setup. In MCP deployments, this removes the need to pre-create every possible client integration before it can start an authorization flow.
Microsoft’s MCP guidance explicitly combines protected-resource discovery with dynamic registration: authorization-server metadata includes a registration_endpoint and supports RFC 7591 registration. The relationship is important. A client should not be handed a generic registration URL and expected to infer the rest of the security configuration; it should discover the relevant authorization environment from the resource it intends to access.
Choose a registration posture that matches your clients
Registration is not a requirement that every deployment must expose publicly. It is a pattern for deployments where independently deployed clients need a supported, programmatic onboarding route. A tightly controlled internal environment may pre-register known clients instead. A hosted connector platform or agency delivering endpoints to multiple customer environments may gain more from dynamic registration because manual client setup becomes a recurring operational dependency.
When dynamic registration is enabled, registration policy deserves the same care as token policy. The registration endpoint determines which applications can obtain client identities and what metadata they may submit. It should be governed, observable, and aligned with the types of clients the connector is prepared to serve.
Self-serve clients:
Dynamic registration can reduce manual coordination when clients need to connect to a newly deployed protected resource.
Pre-approved enterprise clients:
Static registration can provide a narrower control surface when all applications are known in advance.
Public versus confidential clients:
Select the appropriate model based on whether a client can safely hold credentials and on the authorization server’s supported policies.
Modern token-endpoint authentication:
Recent MCP client-ID metadata discussions include
private_key_jwt
and JWKS configuration as supported patterns.
Authorization-code protections:
Dynamic registration is often paired with PKCE and modern client-authentication approaches in connector setups.
Do not treat a registered client as a substitute for user or workload authorization. Registration identifies a client application. Access to a tool still depends on the token presented for the specific request, its scopes or permissions, the resource being accessed, and any connector-side policy.
Operationally, record registration events, registration metadata, and subsequent authorization failures in a form that supports troubleshooting. Avoid logging client secrets, access tokens, or raw authorization ers. Good observability helps distinguish a discovery error from a registration policy rejection and from an end-user consent or scope problem.
Make tool discovery authorization-aware and cacheable
Tool discovery in stateless MCP is no longer safely modeled as a one-time global list fetched after a connection becomes authenticated. Updated MCP tool-listing guidance says the available tool set may vary according to the authorization presented on the request because credentials are per-request input rather than connection state. In other words, tool discovery is part of the authorization experience.
MCP tool documentation also says servers may return only the tools permitted by the caller’s scopes. This allows a connector to avoid advertising operations the caller cannot invoke, which produces a cleaner model context and reduces avoidable authorization failures. The same guidance calls for deterministic ordering so that clients can cache tool lists reliably.
Evaluate visibility before exposing a tool
For each tool-list request, establish the caller’s authorization context first, then calculate visibility. The policy can be coarse, such as a scope granting access to a category of tools, or fine-grained, such as permissions varying by tool, tenant, or protected resource. What matters is that the decision reflects the current request instead of a stale connection-level decision.
A 2026 gap-analysis paper identifies no pre-auth tool discovery and no fine-grained per-tool authorization as two major enterprise shortcomings in MCP SDKs. It proposes an unauthenticated metadata endpoint and permission-filtered tool visibility. The paper further argues that these additions can be made without changing core protocol or SDK internals, suggesting that adapter layers are often a more practical answer than forking the protocol.
An unauthenticated metadata endpoint can be useful when it reveals only safe, non-sensitive information: the connector’s identity, documentation location, discovery instructions, or a high-level indication that authorization is required. It should not become an accidental inventory of privileged tools. Keep the boundary explicit between public onboarding metadata and the permission-filtered tool catalog.
Build a deterministic tool-list pipeline
The connector should make the same visibility decision for the same effective authorization context and then present the result in a stable order. Deterministic ordering enables a client to cache tool lists without treating harmless ordering changes as capability changes. It also makes troubleshooting easier: an operator can compare the result for two scope sets and identify whether a policy difference, rather than nondeterministic output, caused the mismatch.
Receive the tool-list request and its per-request client context and credentials.
Validate and normalize credentials into an internal authorization context.
Determine the applicable tenant, protected resource, scopes, and policy constraints.
Filter the canonical tool catalog to tools the caller is permitted to discover.
Apply a stable, documented ordering rule to the filtered result.
Return the list with no privileged tool details for unauthorized items.
Key any cache by the inputs that affect visibility, not merely by the endpoint URL.
Cache design is the hard part. A global cache of one caller’s tool list can leak capabilities or create false negatives for another caller. At minimum, cache keys need to account for the authorization context and any configuration version that affects visibility. If token expiry, revocation, tenant selection, or mutable policy can alter the result, the cache must respect those boundaries.
There is also a product trade-off. Filtering makes tool selection safer and less noisy, but it can make an assistant’s available capabilities appear to change as credentials change. That is expected behavior in a request-authorized model. Make it observable in logs and understandable in connector documentation so product teams do not misdiagnose it as random tool instability.
Add adapter layers instead of forking MCP SDKs
Connector builders often encounter enterprise requirements that are not fully represented by a basic SDK integration: multiple credential locations, onboarding metadata before authentication, tool-level permission policies, or support for both people and workloads. The temptation is to fork an SDK or add proprietary protocol semantics. The more durable approach is usually an adapter layer around a conforming MCP implementation.
The 2026 gap-analysis paper’s conclusion supports that approach: cross-er normalization, unauthenticated metadata, and permission-filtered tool visibility can be added without changing the core protocol or SDK internals. An adapter layer can accept deployment-specific identity inputs, execute standards-based OAuth discovery, construct a normalized principal, and pass the resulting policy decisions into the connector’s tool-discovery and invocation paths.
Place responsibilities at the right boundary
Edge or gateway layer:
Handle request parsing, credential extraction, token validation integration, request IDs, rate controls, and safe audit events.
Discovery layer:
Serve protected-resource metadata and direct clients to the relevant authorization-server metadata.
Authorization adapter:
Normalize claims and ers, apply tenant and scope policy, and produce a decision usable by all tools.
MCP server layer:
Process
_meta
, list permitted tools deterministically, and invoke approved tools.
Tool implementation layer:
Enforce resource-specific checks where a generic gateway policy cannot safely determine access.
This separation prevents an authorization shortcut in one tool from becoming a platform-wide exception. It also helps agencies and product teams reuse a connector framework across customers while keeping each customer’s issuers, resources, registration policy, tool policy, and audit destinations configurable.
Infrastructure still matters after a connector meets the protocol requirements. A separate 2026 design-patterns paper reports rapid MCP growth, citing more than 10,000 active servers and 97 million monthly SDK downloads as of early 2026, while concluding that the specification alone does not cover every production need. Hosted execution, observability, scaling, secret handling, policy deployment, and incident response are implementation concerns that remain outside a narrow reading of protocol messages.
Test stateless connector behavior as an end-to-end system
A connector can pass a simple tool invocation test and still fail in real client onboarding. Discovery, registration, token acquisition, credential normalization, tool listing, and tool execution form one chain. Test the chain as a client experiences it, including callers that have different scopes and callers that represent different personas.
Start with the path that requires the least prior knowledge. A new client should be able to identify the protected resource, find authorization-server metadata, determine whether dynamic registration is available, obtain valid authorization, and receive an appropriate filtered tool list. This is the path most likely to expose hidden dependence on a configured session or a manually supplied issuer URL.
A practical validation checklist
Send independent requests through different instances and confirm that authorization results remain consistent without connection affinity.
Confirm that protocol version, client identity, and client capabilities are present and handled as request-scoped
_meta
data.
Retrieve
/.well-known/oauth-protected-resource
before any authenticated tool request and validate its authorization-server reference.
Test the applicable authorization-server metadata discovery routes, including the multiple well-known endpoint behavior needed for OAuth and OpenID Connect interoperability.
If dynamic registration is offered, test registration policy, returned client metadata, and the client’s ability to complete an authorization flow.
Test PKCE and the configured token-endpoint client authentication model where those patterns apply.
Compare tool lists for callers with different scopes and verify that each list is permission-filtered and deterministically ordered.
Attempt a direct call to a hidden tool and confirm that tool invocation has its own enforcement rather than trusting discovery filtering alone.
Test human and service-account callers when the connector supports both, including credential normalization and audit attribution.
Verify that logs and traces identify discovery, registration, authorization, listing, and invocation stages without storing secrets.
Include negative tests deliberately. Try an expired token, a token for the wrong resource, incomplete scopes, missing _meta fields, malformed discovery metadata, and a client that begins discovery at the protected-resource endpoint. A stateless implementation should fail each case predictably on the request where the information is inadequate, rather than behaving differently because of what happened on a prior connection.
Finally, decide what your connector will do when policy changes between requests. Since tool visibility can change with authorization and policy, a client cache may become stale. Stable ordering makes caching practical, but it does not eliminate the need for cache invalidation or a fresh listing when permissions change. Document that behavior for product teams building assistants on top of the connector.
Plan the migration from connection-era assumptions
Most teams do not begin with a clean stateless architecture. They have existing middleware that attaches a user to a socket, an initialization handler that stores client capabilities in memory, or a static tool catalog created at service startup. Migration is easier when these dependencies are identified as explicit assumptions and replaced one at a time.
First inventory every value currently read from connection state: authenticated principal, protocol version, client identifier, capabilities, tenant, selected authorization server, consent status, and tool permissions. For each value, decide whether it must arrive in the current request, be derived from the request’s validated credentials, be loaded from durable configuration, or be requested through a multi-round-trip interaction.
Make request handling idempotent where possible and remove reliance on connection affinity.
Add per-request processing for
_meta
protocol and client context.
Move token validation and policy resolution into a reusable authorization adapter.
Publish protected-resource metadata and verify authorization-server discovery end to end.
Add dynamic registration only if your onboarding model benefits from it and your authorization server supports the desired policy.
Convert a globally static tool list into a permission-filtered, deterministically ordered result.
Instrument each stage before expanding to more clients or tenants.
Do not overcorrect by making every request expensive. Stateless does not prohibit caching metadata, verification keys, policy bundles, or non-sensitive configuration. It requires that cached data be used as a reliable input to an independently evaluable request, not as a hidden record of who a prior connection happened to be.
The resulting connector is easier to scale across workers, easier to troubleshoot from request logs, and better aligned with enterprise OAuth onboarding. More importantly, it handles authorization as a property of the current call, which is the core requirement behind stateless MCP operation.
Stateless MCP connectors need three design commitments: no-session authorization, two-stage discovery from protected resource to authorization server, and tool lists filtered by the credentials on the request. Per-request _meta gives the server the protocol and client context it needs, while OAuth metadata and, where appropriate, dynamic client registration give clients a standards-based route to configure themselves.
Build these concerns as composable layers rather than protocol forks: discovery metadata, credential normalization, policy evaluation, deterministic tool filtering, and request-level observability. That foundation lets a connector serve interactive users and service accounts, support self-serve onboarding when appropriate, and remain predictable as MCP clients and enterprise authorization requirements evolve.