• 🔍 Trigger a full review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

First off, lets address the elephant in the room: the @modelcontextprotocol/sdk library is humongous compared to h3.

A required step IMHO is having support for the native JsonRPC handler, which all modern MCPs are based off. I'll soon revisit #1180 PR and see if it needs something to be addressed. Regardless of MCPs this would also enable other use-cases, since it is well-known spec and vastly adopted (especially when mixing up programming languages).

But in reality the SDK reaches that size because of the following reasons, which are part of the MCP specs:

• authorization is mostly based on JWT (either direct token or via OAuth/OIDC), this is something I've started digging deep (and ended up loving) almost one year ago support for JOSE (Javascript Object Signing and Encryption) #994
• built-in validation, not only for project-level information/data but even before accepting the incoming RPC call. It is quite hardcoded ontop of zod, its own toJsonSchema and ajv for validating it. Which they also come with their tradeoffs, not only in bundle size (you can read more about it here)
• the SDK itself is meant to be ready-to-use, not really a toolset to build-ontop, meaning that it comes with hono, express and various adapters.

There are another couple of aspects which I do not remember atm, but even just for the first two points above I would personally consider IF h3 is even the right place.

Even with forking the SDK, bringing over the bare minimum, we would still need:

• JWT reader and validator: jose or unjwt (ofc I prefer the latter, but ended up being similar size and performance, just the DX is close to what h3 offers)
• Validation library agnostic: StandardSchemaV1 support, which we have, and StandardJSONSchema which not only arrived recently but also requires dedicated linking for each validation library
• A set of cryptographically secure utilities: for example to manage PKCE challanges, string comparison, randomness and so on ends up adding its own size, even forking a small library like unsecure
• JsonRPC handler

Only at this point, once we have all these tools available (forked or added as deps) we can start building the various functions and constants, and from the experience in h3-mcp-tools (which I really miss and want to get back and develop it) I can confidently say that the final h3 size will at lest double, realistically triple, the current state.

My honest though would be to add this tooling in Nitro, which can treeshake stuff when unused anyway.

Also, for these very reason I'm considering to just close the JWE issue and related PR (#997). Iron Crypto is not my personal favorite in its topic, but the current implementation is good-enough as is, and too many people already use it.

While on the other hand JWE (and JWS) would require to be as spec-compatible as possible, which inevitable end up increasing h3 size. Not to mention that the current useSession implementation is not compatible with the OAuth spec, which I would argue that it is the most important spec to consider when working with JWTs

This is why I built, maintain and use unjwt. JWT compliant, h3 DX

Thanks for your thoughts @sandros94 ❤️

Yes, lets ship json rpc utils first!

With composable approach of h3 utils, i think we can easily make authenticated wrappers for MCP tools (which can live outside of h3 as ready to use opinionated solutions). And as for validation supporting standard schema just makes sense and comes for free.

H3 provides many treeshakable utils already. Users in Nitro can benefit from auto scanning of server/mcp/* tools + h3 as base or better wrapper packages that wrap base tools.