To implement MCP input validation correctly, we must use zod. The core challenge is that the inputSchema returned by the tools/list discovery endpoint must be a JSON-serializable object, while the actual validation requires a live zod schema object.
This ticket covers the refactoring of the tool service to manage both schema types: the zod schema for server-side validation and its JSON Schema representation for client-facing discovery.
Acceptance Criteria
- The
zod and zod-to-json-schema packages are added as dependencies to package.json.
toolService.mjs is refactored to generate a zod schema for each tool's input based on the openapi.yaml file.- The service then converts the
zod schema to a standard JSON Schema object using zod-to-json-schema.
- The
listTools function is updated to return the plain JSON Schema object in the inputSchema field of each tool.
- The
callTool function is updated to use the internal zod schema to validate arguments via .parse() before executing the tool handler.
To implement MCP input validation correctly, we must use
zod. The core challenge is that theinputSchemareturned by thetools/listdiscovery endpoint must be a JSON-serializable object, while the actual validation requires a livezodschema object.This ticket covers the refactoring of the tool service to manage both schema types: the
zodschema for server-side validation and its JSON Schema representation for client-facing discovery.Acceptance Criteria
zodandzod-to-json-schemapackages are added as dependencies topackage.json.toolService.mjsis refactored to generate azodschema for each tool's input based on theopenapi.yamlfile.zodschema to a standard JSON Schema object usingzod-to-json-schema.listToolsfunction is updated to return the plain JSON Schema object in theinputSchemafield of each tool.callToolfunction is updated to use the internalzodschema to validate arguments via.parse()before executing the tool handler.