Raw request propagation in tools - passed to callbacks via RequestHandlerExtra<ServerRequest, ServerNotification>

[KKonstantinov]

Request Propagation to tool/resource/prompt callbacks via RequestHandlerExtra

This PR is a substitute of the original PR (#557).

Motivation and Context

An application often times needs access to the original request headers, for example, whenever it is sitting behind a reverse proxy, and the reverse proxy is setting some headers itself.

Few real-life examples / use cases:

• Authentication may rely on request headers. In the case where the MCP server needs to act on behalf of the client to retrieve resources from a remote server or DB, thus requiring to authenticate on behalf of the client, getting the request headers is essential.
• A trace ID / correlation header is generated at the API gateway / reverse proxy later, then passed to the actual remote MCP server. The MCP server needs to utilize the traceparent to store it in logs, etc.

How Has This Been Tested?

SSE and Streamable transport - resources and tools.

Breaking Changes

No breaking changes.

Types of changes

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

Checklist

• I have read the MCP Documentation
• 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

Adding the RequestInfo type, which contains just headers for now - to be used for more raw request properties to add as we go - e.g. httpMethod, and others.

server.tool("fetch-weather", { city: z.string() },
  async ({ city }, extra) => {
    const response = await fetch('https://api.weather.com/${city}');
    const data = await response.text();
    console.log(extra.requestInfo); // contains headers
    return {
      content: [{ type: "text", text: data }]
    };
  }
);

[KKonstantinov]

Hi @ihrpr, this is the new one (replaces #557.) if we could have it reviewed/merged please, let me know if any comments.

[KKonstantinov]

Hello, let me know if anything else is needed on this PR. It's been waiting for a couple of weeks, have updated it with the latest from the branch.

[ihrpr]

Sorry about the delays in review, we are trying to catch up SDK to the latest spec release. Thank you for implementing the suggestions.

Main concern is around onmessage from optional extra parameter to required, which breaks existing transport implementations that might not provide this parameter.

[KKonstantinov]

@ihrpr updated to reflect comments.

[ihrpr]

thank you for the quick turnaround, left some inline comments

[KKonstantinov]

thank you for the quick turnaround, left some inline comments

These are done

[ihrpr]

thank you!