MCP: Output schemas reject responses with extra properties (additionalProperties:false drift)

Note (2026-04-18): This ticket was re-purposed. Its original premise — hardcoded z.array(z.string()) for input arrays — was effectively addressed by #10043's recursive buildZodSchemaFromNode refactor. The ticket number is being reused because the symptom class (MCP schema validation failures) resurfaced on the output side, and the original payload never landed. See the re-purposing comment below for the audit trail.

Problem

GitHub Copilot and other strict-JSON-Schema MCP clients crash when calling output-heavy tools on the Neo MCP servers. Example reported in the wild:

• get_worker_topology → Error: Structured content does not match the tool's output schema: data/result/0 must NOT have additional properties

Confirmed by a live session against devindex. Similar failures observed for get_instance_properties, mutate_frontier, get_context_frontier.

The error is not "the tool is broken" — it's that the declared JSON Schema for the tool's response has additionalProperties: false at nested levels, and the server returns fields not in that declared set. Clients with strict schema validation (Copilot) reject the payload; lenient clients (Claude Desktop, Cursor) pass it through silently.

Forensic Trace (Three-Layer Interaction)

1. Schema drift in the OpenAPI definitions. Example: ai/mcp/server/neural-link/openapi.yaml:905-939 declares get_worker_topology items with {sessionId, appWorkerId, isSharedWorker, userAgent, environment, connectedAt}. The actual service at ai/mcp/server/neural-link/services/ConnectionService.mjs:312-317 stores {appName, connectedAt, logs, sessionId}. Two returned fields (appName, logs) aren't declared; three declared fields are never populated.

2. zod-to-json-schema emits additionalProperties: false on every z.object(...) by default. Verified:

      zodToJsonSchema(z.object({a: z.string()}))
   // → {"type":"object","properties":{"a":{"type":"string"}},"additionalProperties":false,...}

   Undeclared fields become JSON-Schema-forbidden.

3. #10043 inadvertently activated client-side strict validation. Diffed pre/post. Pre-#10043, top-level outputSchema for array responses was {type: "array"} — which violates the MCP spec (requires type: "object"). Clients likely skipped validation. #10043 correctly wrapped array responses in {result: [...]} for spec compliance, and from that point clients began validating — surfacing the latent drift that had been silently present.

Why "the tools worked before"

Not a regression in validator code per se. #10043 made validation work correctly; the underlying schema drift has been latent for months. The drift was harmless only because no one validated it strictly.

Scope — Cross-Server Sweep

Emission counts from buildOutputZodSchema + zodToJsonSchema for every operation across all 5 servers:

74/83 ops could silently reject a payload if the service ever returns a field the schema doesn't declare. Whether each one actually breaks today depends on implementation drift — the get_worker_topology/mutate_frontier/get_context_frontier/get_instance_properties failures are proof that real drift exists.

Proposed Treatment (Option C: hotfix + audit)

Step 1 — Defense-in-depth in ai/mcp/validation/OpenApiValidator.mjs (hotfix, restores all tools):

In buildZodSchemaFromNode, when emitting z.object(...) for output schemas, apply .passthrough():

zodSchema = z.object(shape).passthrough();  // emits additionalProperties: true

Input side must stay strict (agents passing extra fields should still get validation errors — contract safety). This requires splitting the shared recursion to distinguish input vs output paths, OR adding a context parameter.

Verified: zodToJsonSchema(z.object({...}).passthrough()) emits additionalProperties: true. Restores tolerance for schema drift on the server response side without loosening input-side validation.

Step 2 — Regression test: extend test/playwright/unit/ai/mcp/validation/OpenApiValidatorCompliance.spec.mjs (from #10064) with an assertion that every emitted outputSchema either (a) sets additionalProperties: true on object nodes, OR (b) is explicitly marked strict. Sibling to the existing array-has-items check.

Step 3 — Audit ticket (follow-up, not this PR): sweep actual service returns vs declared OpenAPI schemas, realign them. Step 1 tolerates drift; Step 3 fixes the drift at the source.

Avoided Traps

• Not reverting #10043. That change correctly satisfies the MCP spec; reverting would regress Copilot-style strict-validator compatibility in other ways.
• Not flipping the global zod-to-json-schema config. additionalProperties: false is correct for input schemas where contract violations should fail fast. The asymmetry (strict in, lenient out) matches the fault model: server implementations evolve independently of schemas; client contracts must stay pinned.
• Not auditing every response schema inline. 74 tools is too large a surface for a single PR. The .passthrough() hotfix buys time for a proper audit without keeping Copilot users blocked.

Related

• Sibling: #10064 (input-side items-missing issue — same MCP schema validation family, different facet)
• Supersedes original premise: #10043 addressed the nested array issue #9837 originally described
• Originally blocked: #9838 (cross-referenced from this ticket's history)

Origin Session ID

97343e6e-9d1c-4170-b3a5-6e58d41511b6 (this session, diagnosed via self-repair skill)