Support JSON Schema enums in MCP tool inputs

Context The harnessTarget parameter for manage_wake_subscription currently requires manual injection of its valid enum values into the description string. This is because the MCP server's JSON Schema serialization drops the enum array before it reaches the agent's system prompt tool schema.

The Problem MCP native tool schemas (which follow JSON Schema Draft-07) fully support the enum keyword. However, when parsing the openapi.yaml document into an intermediate Zod schema, the Neo.mjs validation layer unconditionally maps string parameters to z.string(), entirely ignoring the enum array defined in the OpenAPI spec. Because the intermediate Zod schema loses this constraint, the downstream zodToJsonSchema serializer has no awareness of it and omits it from the final MCP tools/list payload.

The Architectural Reality The flaw resides in the translation layer located at ai/mcp/validation/OpenApiValidator.mjs inside buildZodSchemaFromNode (around line 148). When schema.type === 'string', it invokes z.string() directly without checking for schema.enum.

The Fix Update buildZodSchemaFromNode in ai/mcp/validation/OpenApiValidator.mjs. When processing schema.type === 'string', check if schema.enum is a non-empty array. If so, map it to z.enum(schema.enum) instead of z.string().

Acceptance Criteria

• buildZodSchemaFromNode correctly creates a z.enum when an enum constraint is present on string parameters in the OpenAPI schema.
• MCP servers successfully propagate enum values from openapi.yaml through the Zod validation layer and out to the tools/list response, removing the need to embed valid values inside description strings.

Out of Scope

• Supporting enums for non-string types (e.g., numbers or mixed types). Zod's z.enum strictly accepts string arrays. This ticket is narrowly focused on the primary use-case: string enum constraints.

Origin Session ID 2d08f92a-3388-4ee1-8247-587a943e294a