You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Motivation:
When using the transport, we always need to pass some context from the context to the sessionFactory or handler, but with the current implementation, the original ServerRequest is completely been ignored, it would be nice that we pass this information down.
we have some kind of options:
with ThreadLocal
With reactor's contextWrite and deferContext
with an additional parameter.
I think the 3 is better, which will not bound to any implementation.
@He-Pin thanks for providing the proposed implementation. I am thinking more about extending the McpServerExchange type to be per-request and encapsulate multiple concerns instead of adding more arguments. The exact shape will reveal itself once we have streamable http for stateless servers, which is coming.
This is really needed. Note: because of the use of the Mono/Reactor framework one cannot even use ThreadLocals as internal threads are used for everything. Separately, the use of that framework is a major limitation of this library and should be reconsidered IMO.
That's true, without this, we currently have to encode our context in the arguments (path the JSON string, and then extract from the JSON string), which is a huge pain.
In #420 I added McpTransportContext and an McpTransportContextExtractor. Can you please have a look at it and provide feedback whether something is missing/impossible to achieve with this? There is also #477 now to backport it for SSE.
I suppose some time has passed since McpTransportContext was introduced to address the concern from this issue and I'd like to close it.
@He-Pin in case you feel the above type-safety proposal is still required, can you please open this as a new issue for the community to comment on? I suppose there might be more feedback on extracting the context by now.
Activity
He-Pin commentedon May 8, 2025
I'm doing some prototyping, will send a pr later.
chemicL commentedon May 30, 2025
@He-Pin thanks for providing the proposed implementation. I am thinking more about extending the McpServerExchange type to be per-request and encapsulate multiple concerns instead of adding more arguments. The exact shape will reveal itself once we have streamable http for stateless servers, which is coming.
Randgalt commentedon Jul 15, 2025
This is really needed. Note: because of the use of the Mono/Reactor framework one cannot even use ThreadLocals as internal threads are used for everything. Separately, the use of that framework is a major limitation of this library and should be reconsidered IMO.
He-Pin commentedon Jul 16, 2025
That's true, without this, we currently have to encode our context in the
arguments(path the JSON string, and then extract from the JSON string), which is a huge pain.He-Pin commentedon Jul 16, 2025
@chemicL I'm totally fine and thankful if you can get this in the next 0.11.0 release, thanks.
134130 commentedon Jul 29, 2025
@chemicL If you don't mind, I want to take care of it.
chemicL commentedon Aug 13, 2025
In #420 I added
McpTransportContextand anMcpTransportContextExtractor. Can you please have a look at it and provide feedback whether something is missing/impossible to achieve with this? There is also #477 now to backport it for SSE.He-Pin commentedon Aug 13, 2025
@chemicL Thanks, we are actually starting using it, but I think we should add some type safe method for this, eg:
Which is more like Netty's
AttributeKeyandAttributeMap, which is typesafe.chemicL commentedon Feb 17, 2026
I suppose some time has passed since
McpTransportContextwas introduced to address the concern from this issue and I'd like to close it.@He-Pin in case you feel the above type-safety proposal is still required, can you please open this as a new issue for the community to comment on? I suppose there might be more feedback on extracting the context by now.