Support for acessing request headers from within a tool/resource/prompt

[KKonstantinov]

Is your feature request related to a problem? Please describe.
An application might need to take deterministic action by reading request headers; or a simpler use-case is where it needs to read the "traceparent" (W3C) header to store it into a database upon a tool being called.

Describe the solution you'd like
The full HTTP request object (or just the headers if not possible) to be passed to the tool/resource/prompt callbacks. The "extra" object might be a good place to do it, or an additional parameter.

Describe alternatives you've considered
Implementing request-based context to store the request headers and use that within the tool/resource seems overly complex.

[KKonstantinov]

Hi @ihrpr , have opened #557 with a non-breaking solution to this.

[pentium10]

@KKonstantinov do you have an example how to access the request headers in a tool after your changes are implemented? I am looking for a solution to my issue as well #599

[KKonstantinov]

@pentium10

I see this was already implemented in the Python SDK for MCP, however the choice in that SDK was to pass the full request as a parameter. In my PR, I've taken a limited approach just passing the headers and not the full request, however maintainers might decide to do it by passing the full request. (I am happy to update my PR to that effect, cover it with tests, etc. if confirmed).

For now, in my PR, you would be able to read it from the "requestHeaders" property in the "extra" argument, for instance:

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.requestHeaders);
    return {
      content: [{ type: "text", text: data }]
    };
  }
);

To be fair, in my use case, we are close to running off of a fork of this MCP SDK since we are needing it for production purposes, and not having access to the request headers is presenting a blocker of the current version.

[backmeupplz]

@KKonstantinov i published your changes here: https://www.npmjs.com/package/@big-whale-labs/modelcontextprotocol-sdk

tyty

[KKonstantinov]

@backmeupplz no need, a new PR is upcoming as we've discussed the changes now and with more unit testing etc. I'd wait for that one to be reviewed & merged by maintainers.

I'll link the PR when submitted and will close the other one.

[KKonstantinov]

Hi all, a new, clean PR is opened - #627.

It adds:

• The RequestInfo interface which is always passed in callbacks via the "extra" object (RequestHandlerExtra<ServerRequest, ServerNotification>)
• Unit tests for both Streamable HTTP and SSE
• The RequestInfo is a wrapper type and contains just "headers" inside for now, but it is to be used to add more as the need arises (e.g. httpMethod or any other raw request properties can be added here).

cc @ihrpr

[BastienL]

Hey @KKonstantinov,

Thank you so much for all the effort put into #627.

However, when trying to access the requestInfo from a server tool, the payload looks like:

{"signal":{},"requestId":1}

I tried querying a remote MCP server deployed through a Cloudflare worker, via OpenAI's playground and Claude Desktop. None of them contains the original request headers, such as the "API Key / Auth token" parameter in the OpenAI playground, or the env parameters in the Claude Desktop config file.

If this can help, here's how my tool is defined:

this.server.tool(
  "do-a-thing",
  { prompt: z.string().describe('The prompt') },
  async ({ prompt }, requestInfo) => {
    console.log(`Request info: ${JSON.stringify(requestInfo)}`);

    // do the thing    
  }
);

The outputted log is Request info: {"signal":{},"requestId":1}. However, I would have expected those to be available within the requestInfo parameter.

Am I missing something?

[BastienL]

Replying to myself here.

Actually, I found a way to achieve this behaviour by setting ctx.props.apiKey in the outer fetch function, and then accessing that as this.props.apiKey within the tool handler:

export default {
  fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const url = new URL(request.url);
        
    let apiKey = request.headers.get("x-api-key");
    if (!apiKey) {
        return new Response("Unauthorized", { status: 401 });
    }

    ctx.props.apiKey = apiKey;

    if (url.pathname === "/sse" || url.pathname === "/sse/message") {
      return MyMCP.serveSSE("/sse").fetch(request, env, ctx);
    }

    if (url.pathname === "/mcp") {
      return MyMCP.serve("/mcp").fetch(request, env, ctx);
    }

    return new Response("Not found", { status: 404 });
  },
};

...

this.server.tool(
  "do-a-thing",
  { prompt: z.string().describe('The prompt') },
  async ({ prompt }) => {
    const apiKey = this.props.apiKey as string;

    // do the thing    
  }
);

Looks like for my use case, using requestInfo what's the right approach eventually.