feat: Add request with context support.

[He-Pin]

Motivation and Context

refs: #225

1. We will need some context information when handling the request*
2. Once this gets merged, the implementation in Spring-Ai will need changed too.

				String callResult = toolCallback.call(ModelOptionsUtils.toJsonString(request),
						new ToolContext(Map.of(TOOL_CONTEXT_MCP_EXCHANGE_KEY, exchange)));

How Has This Been Tested?

During development.

Breaking Changes

Yes, binary not compatibility

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• [x ] New feature (non-breaking change which adds functionality)
• [ x] Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• [ x] I have read the MCP Documentation
• [ x] My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[He-Pin]

@tzolov Wdyt about this, I would like to push this, thank you.

Another way to handle it is extends the WebFluxSseServerTransportProvider and then wrapping my ctx into the params of JSONRPCRequest, eg:

        final Map<String, Object> argumentsMap = new HashMap<>(callToolArguments);
        if (myMcpContext != null) {
            argumentsMap.put(CONTEXT_KEY, myMcpContext);
        }
        final var newCallToolRequest = new McpSchema.CallToolRequest(callToolRequest.name(), argumentsMap);

[qnnn]

We would also like to use this feature. If this PR is being blocked due to the breaking changes it introduces, perhaps the alternative approach mentioned in the referenced issue—based on Reactor context and ThreadLocal-based implementation could be considered instead.

[jahlbornG]

I'm interested in using these changes as well. i was looking through them. @He-Pin i'm curious as to the decision to use a ConcurrentHashMap in the MpcContext. as far as i can see, the context is created for use within a single request invocation. assuming that some initial modification is done during creation and then the context is passed to the handler, it doesn't seem like you would need additional synchronization control within the context itself? am i missing a use case which would require ongoing interaction with the context among multiple threads?

also, i assume it's an oversight, but none of the methods on McpContext are public?

[He-Pin]

We currently have to encode ctx in the params(patch the json).

[jahlbornG]

We currently have to encode ctx in the params(patch the json).

@He-Pin was that an answer to my question? if so, i don't think i understand it.

[jahlbornG]

looks like a change was committed which removes the need for this context when using the sync server: b5a1e3b