Add Unified Request Context API for MCP Operations

[tzolov]

Summary

Introduce McpSyncRequestContext and McpAsyncRequestContext as unified interfaces for accessing MCP request context, providing a higher-level abstraction over the underlying MCP infrastructure.

Problem Statement

Currently, developers face several challenges:

1. Fragmented API Surface - Different parameter types required for stateful (McpSyncServerExchange/McpAsyncServerExchange) vs stateless (McpTransportContext) operations, plus separate @McpProgressToken and McpMeta handling

2. Inconsistent Patterns - Stateful and stateless operations require different APIs, making code difficult to port between modes

Proposed Solution

Introduce unified context interfaces that work seamlessly across all operation modes:

McpSyncRequestContext / McpAsyncRequestContext

Unified context interfaces providing access to the original request, server exchange (stateful) or transport context (stateless), and convenience methods for logging, progress, elicitation, sampling, and server operations. The async version uses reactive return types (Mono<T>).

Replace multiple parameters and annotations with a single context object providing built-in helpers.

Context is automatically injected when detected in method signatures by type (parameter name doesn't matter), excluded from JSON schema generation, and optional for methods that don't need it.

Unified Developer Experience

Single context parameter works in both stateful and stateless modes with the same API.

Graceful Degradation: Bidirectional operations return Optional.empty() or Mono.empty() in stateless mode or when client capabilities are missing, enabling code reuse across modes without mode-specific error handling.

Future-Proof Architecture

Add new capabilities without changing method signatures.

Backward Compatibility

All existing APIs continue to work with no breaking changes, providing a gradual migration path with deprecation warnings.