Begin Migration to Standard Schema

[harrysolovay]

Resolves #164

The aim of this PR is to utilize the StandardSchemaV1 interface instead of ZodType. This will allow for usage of other runtime type libraries, including Arktype, Effect Schema, Valibot and Typebox.

Important note about this PR: in places that previously accepted a record of types, we must now supply a single object type of the given vendor.

mcpServer.tool(
  "my-tool",
- {
+ z.object({
    name: z.string(),
    value: z.number(),
- },
+ }),
  async ({ name, value }) => ({

This is important because we don't know how to turn a record containing unknown standard types into an object type of that same vendor (with which we derive the JSON schema). This is unfortunately a breaking change.

TODO:

• get some initial feedback
• consider Completable utility (@jspahrsummers what is the recommended path forward here?)
• get tests passing
• consider caching toJSONSchema calls using a WeakMap keyed by the runtime type.

[mmkal]

Not associated with the project, just stumbled across this so leaving some driveby comments!

[mmkal]

This seems like a problem. The below line assumes that prompt.argsSchema is a zod type. Shouldn't this rely on the json-schema somehow (though it's a bit more complicated, it looks like Completable is an extension of zod that's internal.

At least it should be

Suggested change

	// @ts-ignore
	const field = prompt.argsSchema.shape[request.params.argument.name];
	const field = (prompt.argsSchema as ZodObject<ZodRawShape>)?.shape?.[request.params.argument.name];

And I guess standardised completable support could come later. Similar for the one below.

[mmkal]

maybe this could be non-breaking by doing

Suggested change

	argsSchema,
	argsSchema: argsSchema === undefined
	? undefined
	: argsSchema?.['~standard']
	? argsSchema
	: z.object(argsSchema),

And resurrecting PromptArgsRawShape as ts union type input