simplify return types

[christophsturm]

Is your feature request related to a problem? Please describe.
the d.ts files are currently way too complex, for example this is one method of the client api.

    listPrompts(params?: ListPromptsRequest["params"], options?: RequestOptions): Promise<z.objectOutputType<z.objectUtil.extendShape<z.objectUtil.extendShape<{
        _meta: z.ZodOptional<z.ZodObject<{}, "passthrough", z.ZodTypeAny, z.objectOutputType<{}, z.ZodTypeAny, "passthrough">, z.objectInputType<{}, z.ZodTypeAny, "passthrough">>>;
    }, {
        nextCursor: z.ZodOptional<z.ZodString>;
    }>, {
        prompts: z.ZodArray<z.ZodObject<{
            name: z.ZodString;
            description: z.ZodOptional<z.ZodString>;
            arguments: z.ZodOptional<z.ZodArray<z.ZodObject<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, "passthrough", z.ZodTypeAny, z.objectOutputType<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, z.ZodTypeAny, "passthrough">, z.objectInputType<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, z.ZodTypeAny, "passthrough">>, "many">>;
        }, "passthrough", z.ZodTypeAny, z.objectOutputType<{
            name: z.ZodString;
            description: z.ZodOptional<z.ZodString>;
            arguments: z.ZodOptional<z.ZodArray<z.ZodObject<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, "passthrough", z.ZodTypeAny, z.objectOutputType<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, z.ZodTypeAny, "passthrough">, z.objectInputType<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, z.ZodTypeAny, "passthrough">>, "many">>;
        }, z.ZodTypeAny, "passthrough">, z.objectInputType<{
            name: z.ZodString;
            description: z.ZodOptional<z.ZodString>;
            arguments: z.ZodOptional<z.ZodArray<z.ZodObject<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, "passthrough", z.ZodTypeAny, z.objectOutputType<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, z.ZodTypeAny, "passthrough">, z.objectInputType<{
                name: z.ZodString;
                description: z.ZodOptional<z.ZodString>;
                required: z.ZodOptional<z.ZodBoolean>;
            }, z.ZodTypeAny, "passthrough">>, "many">>;
        }, z.ZodTypeAny, "passthrough">>, "many">;
    }>, z.ZodTypeAny, "passthrough">>;

Describe the solution you'd like
a very simple fix would be to just create aliases for the return types and use them:

type ListPromptsResult = z.infer<typeof ListPromptsResultSchema>;
 async listPrompts(
    params?: ListPromptsRequest["params"],
    options?: RequestOptions,
  ): Promise<ListPromptsResult> {
    return this.request(
      { method: "prompts/list", params },
      ListPromptsResultSchema,
      options,
    );
  }

Describe alternatives you've considered
a even better version IMO would be to not use zod at all for the return types, just declare typescript types, and let typescript check if they are compatible.

[jspahrsummers]

There are already aliases for return types. Have you tried SDK version 1.1.1, incorporating #114? It should make this case better, more akin to just using TS types (but still using Zod under the hood).

[christophsturm]

I tried building the git main branch and saw the complex types in the generated d.ts file for example in dist/*/client/index.d.ts. Then I declared the return type of the method and the problem went away.

[punkpeye]

Related #182

These types would be a lot more straightforward if it didn't use .passthrough().

[dgieselaar]

Hey folks, inferring types from zod schemas is very expensive computationally, and seems unnecessary for a library. Ideally you just have static types - should be fairly easy to generate. I'm sure there are scripts that do this.

[benjaminjkraft]

These are still pretty bad, even with #114:

• hovering on the API methods still shows hundreds of lines of zod nonsense
• in some of our typecheck configurations the types hit TS complexity limits and collapse to any

Would you be amenable to a PR to simply write out the types that the API exposes explicitly? They aren't that complicated.

[punkpeye]

Just removing passthrough would make these types 10x better.

I ended up re-typing all types locally.

[benjaminjkraft]

Yep, I just wrote a type locally for what I wanted -- which caused me to realize some of our code was already wrong, because, again, the types were complex enough that TS gave up!

[benjaminjkraft]

With my good friend Claude, and a bit over twelve dollars of my employer's money to power him, I made a PR for this: #612

[punkpeye]

Needed a workaround because the types from the SDK itself are truly hard to work with:

https://github.com/punkpeye/mcp-types