Zod types via `infer` make TypeScript types a lot less readable

[felixweinberger]

There's a lot of indirection in the types via Infer<...> making types in IDEs significantly less readable and ergonomic than just standard TS Types.

Should likely explore ways to improve this if possible.

[reachaadrika]

hey @felixweinberger
I would like to work on this , can you assign this to me?

[KKonstantinov]

We could define the types separately.

Then we could use the satisfies keyword to make sure they match (although because of TS's structured typing system, we would have to be careful with that as satisfies wouldn't flag any missing fields in the schemas that are otherwise optional).

Not starting from schemas and then inferring, but rather starting from types and then defining schemas to match them, would allow us to make better use of type generics, so to have proper type checking on some types. (One example could be found at #859, where currently we only do a runtime check of structuredOutput, and we could really have it checked by the type system (e.g. if you defined outputSchema, then structuredOutput is required by the type system, and we would not rely on just a runtime check). However there is a multitude of opportunities like that, and the branch is just demonstrating one use case)

If the vitest migration PR (#1015) gets merged, we could further make use of their type testing feature (https://vitest.dev/guide/testing-types).

Happy to take this on as well, if it's a priority - but would like to align on the approach beforehand as it is a not insignificant piece, while having to be very careful for not breaking any compatibility as well.

[demian85]

Can someone please help me with the types? I cannot even compile the example from the readme.
TS complains about missing types in server.registerTool that I cannot even decipher.
The one that wrote Zod types is a twisted motherf***

[BobDickinson]

I've found the inferred types in this SDK very hard to use also (they're pretty much inscrutable) - both in IDE usage and in type mismatch errors from TypeScript. Sometimes there is just no way around that if you want strong schema validation (and in some cases to drive external JSON schema or docs with high fidelity data).

However, this project has an interesting wrinkle. The core TypeScript types come from upstream: @modelcontextprotocol/modelcontextprotocl (/schemas/[xxxx]/schema.ts]. The Zod schemas in the repo appear to be manually maintained (I assumed, and was hoping, they'd just be generated from the upstream schemas). But there are tests that confirm bidirectional assignability between the upstream spec types and the corresponding inferred Zod types. And given that, my question would be why don't the APIs just use the spec types in their exports? If you want validation (or to drive docs) using the Zod schemas, go for it. But it's not clear why an SDK user should be subjected to an inferred Zod schema type when a nice, clean, native TypeScript type also exists in the project and we know that it's bidirectionally assignable. Just my $0.02.