fix: Replace non-standard enumNames with standard oneOf in EnumSchema

[jake-danton]

enumNames is not standard. It's use is keeping this project from updating to ajv v8, which keeps this library from running in some JS runtimes (example #689 ).

Motivation and Context

enumNames is not standard. Its use is keeping this project from updating to ajv v8, which keeps this library from running in some JS runtimes (example #689 ).

Note: requires this schema PR to go through first

How Has This Been Tested?

Ran npm test and used in local development

Breaking Changes

Will require users to update to the standard oneOf where using enumNames.

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
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[cliffhall]

Just noticing that we have ajv and zod in the same repo and wondering how this came to be and if we shouldn't just stick with zod, unless there's something ajv is giving us that zod can't, since package size is a concern.

[jake-danton]

Right now, the repo is on Zod v3 which has no concept of JSON schemas and so it uses not only ajv for reading the text JSON Schema in and validating against it, but it also uses zod-to-json-schema to convert the Zod schemas to JSON Schema text output.

Updating to Zod v4 (see #914 ) removes the need for zod-to-json-schema as v4 includes that Zod-to-JSON schema functionality now. However, it does not have JSON-to-Zod schema support or the ability to parse a JSON schema from a string and so the repo would still need ajv.compile.

If anything, the library could move off of Zod to only use ajv. I assume the main reason Zod was used was for its devX since it is a Typescript-first schema library (though that comes with some problems as well). But ajv does have the ability to define schemas, use them with Typescript, and compile them from strings to validate (as this repo already does). Developers could still use Zod themselves if they choose and handle the interop with this library where needed.

The biggest unknown is how this library would handle "completable" schemas if only going with ajv as they are currently patched into the Zod ecosystem. I assume it is doable, but it will require a refactoring of completables.

If there is interest in that route, I would be happy to help investigate what that "move off of Zod but interop with it" solution would look like.

[jake-danton]

Using ajv, schema definitions look like:

interface AjvType {
  count: number
  email?: string
}

const AjvJsonSchema: JSONSchemaType<AjvType> = {
 '$schema': 'http://json-schema.org/draft-07/schema#',
  type: "object",
  properties: {
    count: {type: "integer"},
    email: {type: "string", nullable: true, format: "email"}
  },
  required: ["count"],
  additionalProperties: false
}

And this can be achieved with Zod using:

const ZodSchema = z.object({
    count: z.number(),
    email: z.optional(z.email()),
});

/* Get the Zod `JSONSchema` */
const ZodJsonSchema = z.toJSONSchema(ZodSchema, { target: "draft-7" });

And both work with ajv.compile:

const ajv = new Ajv()
formatsPlugin(ajv);

const validateAjvJsonSchema = ajv.compile(AjvJsonSchema)
/* Just cast the Zod `JSONSchema` to Ajv's `JSONSchemaType<T>`
const validateZodJsonSchema = ajv.compile(ZodJsonSchema as JSONSchemaType<z.infer<typeof ZodSchema>>)

And it also makes this library work with Valibot (confirmed) and any other library that outputs valid JSON Schema (likely ArkType, Effect Schema, TypeBox).

[cliffhall]

Gotcha. Makes sense.

[sinclairzx81]

@jake-danton @cliffhall Hi, TypeBox developer here.

---

Right now, the repo is on Zod v3 which has no concept of JSON schemas and so it uses not only ajv for reading the text JSON Schema in and validating against it, but it also uses zod-to-json-schema to convert the Zod schemas to JSON Schema text output.

---

If anything, the library could move off of Zod to only use ajv. I assume the main reason Zod was used was for its devX since it is a Typescript-first schema library (though that comes with some problems as well). But ajv does have the ability to define schemas, use them with Typescript, and compile them from strings to validate (as this repo already does). Developers could still use Zod themselves if they choose and handle the interop with this library where needed.

---

I'm not sure if this is a good place to comment, but I wanted to reach out regarding some of these technicalities and potentially offer a solution for consideration.

Just for a bit of context, I have focused some effort this year into putting together a TypeBox offering which may enable frameworks to better integrate with JSON Schema and Standard Schema. Noting that Zod 3 and 4 (along with other popular validators such as Valibot) all fall under the Standard Schema category, while Ajv handles JSON Schema validation.

Based on this, I've seen some potential to unify both specifications under a common validation infrastructure, enabling not only Zod and JSON Schema validation and inference, but also unified support for any type validator library that implements the Standard Schema specification.

There’s a bit much to cover in a single comment thread, but I’ve put together a few reference implementations specific to type library interop if you’re interested:

Links

• Github
• Documentation
• Ecosystem
• Performance

Demos

1. JSON Schema Compile
2. TypeScript Definition Compile
3. TypeBox Compile
4. Zod Compile
5. Remote Library Embedding

---

I had been planning to put together a formal proposal for this SDK (as well as several other frameworks dealing with similar JSON Schema and Standard Schema reconciliation issues), but I wasn’t sure how receptive this SDK would be to considering TypeBox as a validation solution. This said, I do see a potential to simplify and streamline SDK validation handling, and to open the SDK up to other validator libraries (TypeBox inclusive)

At this stage, TypeBox has full Draft 7 support as well as partial support for 2019, 2020 vocabularies. I will be pushing for full 2020 spec compliance in 2026, but as far as Draft 7 compliance goes, TypeBox seems to be more compliant than Ajv in the regard it passes the full Draft 7 compliance tests from the official JSON Schema test suite. It also passes a lot of 2019, 2020 and Next Drafts.

Given the strong interest from developers in leveraging a wide range of validators, redesigning TypeBox to act as a unified host infrastructure for these libraries while maintaining strong JSON Schema compatibility seemed like a good way to innovate while offering something valuable for the wider ecosystem. This functionality was just released last week in version 1.0.

Happy to discuss more if you're interested
Cheers
S

[jake-danton]

Thanks @sinclairzx81! Typebox is definitely worth discussing. I was not aware of the full Compile and Parse capabilities that make it an alternative for AJV. Exciting stuff.

I think the goal for this library's external API should be to get it working with any libraries that export JSON Schema, including Typebox, Zod, and many others. But I want to clarify in more detail what I was saying above and then end with some questions (feel free to skip to the questions section if you are familiar with this libraries inner workings).

Clarification

This library currently uses Zod, AJV, and zod-to-json-schema. zod-to-json-schema is purely used to turn the Zod schemas users pass into the external API for tools into JSON Schema and can go away when Zod is updated to v4 (see #914).

The main tools API (and future others that need input/output schemas) is the specific path that should ideally move to just "the developer passes in a typed JSON Schema" to remove that hard requirement on Zod to call this library. One option is to just use the AJV JSONSchemaType<T> -- since there is not a more standard one -- but this library could also just have a simple non-validating JsonSchema<T> type that can be cast to and used for typing the tools APIs (or it could use one from Typebox, etc whatever is at hand). Changing those to take JSON Schema directly would enable the library to work with every library that can output valid JSON Schema (Zod, Typebox, Valibot, etc). So that would allow users to define the schemas however they want -- using any validator library or just creating them by hand. There is no requirement to support Standard Schema, even though most of the libraries do.

But Zod is also used for purely internal type validation separate from JSON Schema entirely and including very specific logic beyond simple JSON Schema-like definitions. For a good example, see ZodSafeUrlSchema which uses superRefine to validate objects passed into the API and can't be fully output to JSON Schema via Zod or zod-to-json-schema (though I believe it could be rewritten and fully represented in JSON Schema using the uri format and a string pattern rather than superRefine). This internal-only usage is pervasive (60+ Zod schema definitions) and would take a large refactor to remove Zod dependency.

AJV is strictly used internally for parsing JSON schemas and validating responses by the client for validating tool output and the server for validating elicitation output. It would be very easy to replace with another option (one that is smaller, faster, more compatible) and that has been discussed in other PRs and Issues.

Questions

So, if I am understanding your message correctly, I take it you are proposing replacing the internal usage of Zod and AJV with Typebox. For that, I think it would be very helpful to get a full understanding of the benefits in doing so -- most notably when it comes to package size and performance, but also increased compatibility. And then also get an understanding of the effort to replace the 60+ Zod schemas (~4 uses of refine, all likely doable with JSON Schema, no coerce or transform) in the library with Typebox (e.g. how much could be done with a simple migration script and how much would have to be significantly rewritten per schema).

If Typebox is smaller than AJV alone after tree-shaking (the total bundle seems slightly larger), has good performance (benchmarks look great!), has greater compatibility, and supports everything this library requires from Zod and AJV for internal functionality, then that is very promising and I would love to help drive it forward for the next major version. But if it doesn't hit those marks, I am not sure the work to refactor and re-stabilize would be justified.

Thanks for bringing up this topic! If you think Typebox hits these marks for this library and want to follow up more, I am happy to do so in a Discussion. Feel free to start one in https://github.com/jake-danton/typescript-sdk/discussions since this one doesn't have them enabled. And if we are on the same page, we can discuss doing some quick prototyping and comparisons.

[cliffhall]

Hi @sinclairzx81!

Happy to discuss more if you're interested

Interesting stuff! Choosing a major dependency such as this will be a much broader discussion than we could have here. I think a more appropriate place to carry on the discussion would be in the typescript-sdk-dev channel of the MCP Contributor Discord.