host tool definitions are currently zod-specific.
today, inputSchema is typed as ZodType, converted with zodToJsonSchema, and validated with zod-specific parsing. that makes the host tool api harder to use with other schema libraries such as effect schema, valibot, arktype, and other libraries that implement Standard Schema.
relevant places:
packages/core/src/host-tools.ts
packages/core/src/host-tools-zod.ts
packages/core/src/agent-os.ts
proposal
make host tool schemas schema-library-agnostic by supporting Standard Schema-compatible validators, instead of requiring zod specifically.
ideally the api would support:
- Standard Schema validation for runtime input parsing
- JSON Schema generation when available via Standard JSON Schema
- raw JSON Schema + custom validation as an escape hatch
- backwards compatibility for existing zod-based tool definitions
other libraries like trpc, hono etc... do a similar thing to be able to for example define route definitions with any schema library https://hono.dev/docs/guides/validation
this would:
- remove unnecessary vendor lock-in to zod
- make host tools easier to use with libraries like arktype, effect schema and other modern schema libraries
- align the api better with the broader TypeScript ecosystem, where many tools now accept Standard Schema-compatible inputs
- preserve the current zod experience while broadening compatibility
i'd be happy to implement this myself if the direction sounds good.
host tool definitions are currently zod-specific.
today,
inputSchemais typed asZodType, converted withzodToJsonSchema, and validated with zod-specific parsing. that makes the host tool api harder to use with other schema libraries such as effect schema, valibot, arktype, and other libraries that implement Standard Schema.relevant places:
packages/core/src/host-tools.tspackages/core/src/host-tools-zod.tspackages/core/src/agent-os.tsproposal
make host tool schemas schema-library-agnostic by supporting Standard Schema-compatible validators, instead of requiring zod specifically.
ideally the api would support:
other libraries like trpc, hono etc... do a similar thing to be able to for example define route definitions with any schema library https://hono.dev/docs/guides/validation
this would:
i'd be happy to implement this myself if the direction sounds good.