feat: Add RawHttpServerAdapter for HTTP frameworks

[Njuelle]

This PR introduces a RawHttpServerAdapter to facilitate the integration of the MCP SDK's StreamableHTTPServerTransport with Node.js web frameworks like Fastify and Express. It also includes tests for this new adapter, an example server using Fastify, and updates to the README.

Motivation and Context

This PR addresses my issue #441

While the SDK's StreamableHTTPServerTransport uses native Node.js HTTP objects (which is foundational), directly integrating it with frameworks that have their own request/response abstractions can be verbose. The new RawHttpServerAdapter simplifies this by providing a reusable Transport implementation. It's designed for frameworks that expose the raw Node.js request/response objects (e.g., via request.raw), making it significantly easier to use the MCP SDK with popular choices like Fastify. This improves versatility, promotes wider adoption, and streamlines HTTP-based MCP server setup.

How Has This Been Tested?

• Unit tests for RawHttpServerAdapter have been added (src/server/raw-http-adapter.test.ts), mocking the underlying StreamableHTTPServerTransport to verify correct interaction and lifecycle management.
• A new example server using Fastify (src/examples/server/simpleFastifyServer.ts) has been created and manually tested to ensure it:
  • Initializes correctly with the RawHttpServerAdapter.
  • Exposes tools, resources, and prompts as defined.
  • Handles MCP initialize, tools/call, readResource, and prompts/get requests correctly over HTTP.
  • Supports Server-Sent Events (SSE) for streaming responses and notifications.
  • Handles session management via the underlying transport.

Breaking Changes

None. This change is additive and does not alter existing interfaces or functionality in a breaking way.

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 (based on the unit tests added)
• I have added appropriate error handling (within the example and adapter for standard HTTP errors)
• I have added or updated documentation as needed (README updated with the new adapter)

Additional context

• The RawHttpServerAdapter is designed to be generic for any Node.js framework that exposes the raw IncomingMessage and ServerResponse objects (e.g., request.raw, reply.raw in Fastify; req, res in Express).
• The Fastify example (simpleFastifyServer.ts) now mirrors the tools, resources, and prompts from the simpleStreamableHttp.ts example to provide a comparable demonstration of functionality using a different web server setup.
• The decision to name the adapter RawHttpServerAdapter (and the file raw-http-adapter.ts) was made to clearly indicate its reliance on raw Node.js HTTP objects.

Fixes #441

[rbonestell]

Excellent contribution @Njuelle, I greatly appreciate this enhancement to support Fastify!

[vinnymac]

Minor nitpick provided this is an example, but this library targets NodeJS 18+, so you should be able to safely use await setTimeout(1000); here instead of implementing a sleep function.

See documentation for more info

[Njuelle]

you're right !
done :)

[ihrpr]

Thank you for contributing. Sorry, adding adapter brings additional complexity to maintaining the project. Instead of this adapter, consider documenting how to use StreamableHTTPServerTransport directly with frameworks, or create framework-specific adapters that handle their unique request/response patterns properly.

[rbonestell]

You explicitly support Express but feel that supporting Fastify (which countless enterprise organizations and platforms utilize) introduces undue maintenance complexity? This was a very elegant abstraction to support the most common NodeJS ecosystem HTTP services... what's the point of directly supporting Express then instead of requiring developers to implement their own adapters for all HTTP providers?

[QuantGeekDev]

@rbonestell

This is prety cool. Do you mind if I try to re-use some of this in MCP Framework?

[rbonestell]

@rbonestell

This is prety cool. Do you mind if I try to re-use some of this in MCP Framework?

This isn't my work, I've just been anxiously awaiting this functionality for my own projects.

You'll want to ask the author @Njuelle