Add transportContextProvider to McpClient.AsyncSpec

Expected Behavior

AsyncSpec should accept a context provider the same way SyncSpec does, so a context can be attached to every client operation in one place:

McpClient.async(transport)
    .transportContextProvider(() -> McpTransportContext.create(Map.of("tenant", currentTenant())))
    .build();

The setter would mirror the sync one:

public AsyncSpec transportContextProvider(Supplier<McpTransportContext> contextProvider) {
    this.contextProvider = contextProvider;
    return this;
}

and McpAsyncClient would apply the same contextWrite that the sync client already applies. Defaulting to () -> McpTransportContext.EMPTY keeps existing behavior unchanged for anyone who doesn't set it.

One caveat worth documenting either way: the supplier is evaluated at subscribe time, so for an async client, it runs on whichever thread subscribes, which may not be the thread the application thinks of as the caller.

Current Behavior

transportContextProvider only exists on SyncSpec. On main at fd00498:

// McpClient
class SyncSpec { ... }                                                                      // 163
private Supplier<McpTransportContext> contextProvider = () -> McpTransportContext.EMPTY;    // 197
public SyncSpec transportContextProvider(Supplier<McpTransportContext> contextProvider)     // 503
class AsyncSpec { ... }                                                                     // 584

AsyncSpec has no equivalent field and no equivalent method. The javadoc is upfront about it, at line 497:

There is no direct equivalent in AsyncSpec. To achieve the same result, append contextWrite(McpTransportContext.KEY, context) to any McpAsyncClient call.

That instruction works. It just puts a cross-cutting concern at every call site.

Context

For a library that needs something attached to all requests, auth or tenancy or tracing, the documented workaround isn't usable, because the library doesn't own the call sites. The application does, and one missed call is a request that goes out without the context.

Nothing errors when that happens. The request just goes out without whatever the context was carrying, and you find out from the server's response, which typically won't say "your context was empty".

The change looks small. What SyncSpec does is mechanical:

// McpSyncClient:452
private <T> Mono<T> withProvidedContext(Mono<T> action) {
    return action.contextWrite(ctx -> ctx.put(McpTransportContext.KEY, this.contextProvider.get()));
}

Every public operation on McpSyncClient routes through it, 23 call sites, from initialize() at line 190 through completeCompletion(...) at 442. McpAsyncClient would need the same contextWrite in the same places.

Alternatives considered:

Follow the javadoc and contextWrite at every call site. Works for an application that owns all its call sites. Doesn't work for a library and doesn't survive the addition of a new call site later.
Wrap McpAsyncClient in a decorator that applies contextWrite to each method. Possible, but it has to be kept in sync with the interface by hand, and it doesn't help anyone who obtains the raw client from a framework.
Use the sync client instead. This is what we do today. That's a real functional restriction, not just an inconvenience.

Is the asymmetry deliberate, or can it be reconsidered?

It was deliberate because anything can be put in the Reactor context. The McpTransportContext was a bridge between sync/async, and being able to pass thread locals into the reactor context.

I'm happy to reconsider for symmetry, but it feels dangerous to have the sync-to-async API in a pure reactive context. It'd be a massive footgun.
What are you trying to accomplish specifically ?

Thank you for taking a look and for the response!

We forward the calling end user's identity as a header on every outbound MCP request. The servers sit behind a gateway that rejects anything without it, with a 424 naming the downstream server, so it reads as unreachable rather than unauthorized.

The issue is in the handshake. It's three requests across two thread pools: the initialize POST on the caller's thread, then the SSE GET from reconnect(null) and the notifications/initialized POST on HttpClient-N-Worker-M. The identity is a request-scoped ThreadLocal, so it's there for the first request and gone for the other two, which go out anonymous and result in 424s.

SyncSpec#transportContextProvider fixes that exactly. The supplier is evaluated at subscribe time on the calling thread, and the transport reads the context back on every leg, including the reconnect. The issue I was fixing was for a sync flow (spring.ai.mcp.client.type=SYNC). For async, we configure nothing and log a warning telling people to switch to sync. That's a functional restriction we impose on users of our autoconfiguration, and from a framework perspective, we should support both. Unlike other issues I logged, this one is more forward-looking and aimed at ensuring framework feature completeness.

You're right about the footgun. Let's forget about the symmetric Supplier idea.

What do you think of Function<ContextView, McpTransportContext>, applied through deferContextual instead? A Supplier gives the implementer nothing to read from except the current thread, which, in a reactive pipeline, is the wrong place. A ContextView parameter hands them the subscriber's context, which is the right one. Getting request-scoped data into the Reactor context stays the application's job. The part a library can't do is translate it into McpTransportContext.KEY at call sites it doesn't own, and that's all the hook would add.

On extending McpAsyncClient, which you suggested on #1074: it's a concrete class with no interface and 42 public methods, and Spring AI constructs the instances, so we'd be post-processing beans into a subclass that overrides all of them and gets rechecked every minor release. It also does nothing for someone who gets the client from autoconfiguration.

If the answer stays no, let's make it clearer in the docs. The note is at McpClient.java#L497 inside SyncSpec, which makes it hard to discover for someone reading AsyncSpec or McpTransportContext. As a bare minimum, let's repeat it in both, with a line saying the asymmetry is deliberate.

The Function<ContextView, McpTransportContext> doesn't add anything - if I'm not mistaken, our implementation propagates the reactor context wherever possible. If the application can write request info to the reactor context (as you suggest), it can write an McpTransportContext instance under McpTransportContext.KEY based on request information.

This will be safely propagated in every chain.

Edit: updated the javadoc.

Clarify McpTransportContext javadoc

Navigation Menu

Repository navigation

Add `transportContextProvider` to `McpClient.AsyncSpec` #1075

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add transportContextProvider to McpClient.AsyncSpec #1075

Description

Activity

Kehrlann commented on Aug 7, 2026

iuliiasobolevska commented on Aug 8, 2026

Kehrlann commented on Aug 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Add `transportContextProvider` to `McpClient.AsyncSpec` #1075