Is your feature request related to a problem? Please describe.
In the enterprise world it is fairly common to send ad-hoc headers across services so that they can handle the request accordingly. For example, we could be sending an internal sessionId (different from the MCP's protocol sessionId) so that the tool can retrieve additional internal data; another typical use case is to send a scenario or userType based on which the tool will act differently. This is information that we do *not want to send to the LLM as it could be quite complex and could easily lead to hallucination and token consumption, therefore it won't be part of the tool's advertised schema.

Describe the solution you'd like
We have seen changes to add authInfo to the tool callback (commit and PR for SSE)

While this is certainly a step in the right direction, there are still some limitations:

1. We are now overloading the IncomingMessage type (req: IncomingMessage & { auth?: AuthInfo }) and this only covers the auth part of it (which we certainly need).

2. Ideally, there should be a separate context object that has auth but also an open set of properties (say Record<string, any>); the middleware can then, as needed, populate this info (from headers) and forward the constructed object to the transport.

Describe alternatives you've considered
We have been able to work around this by having a MCPWrapper class with internal properties, that

1. the middleware sets based on headers
2. the tool callback can then reference the instance properties

While this works, it is less than ideal and it would be beneficial for the TS-SDK to offer a clear contract.