›_ Codex Issues
Codex Issues / #17964

MCP tools/list flattens anyOf array-or-null filter schema to scalar string

Open 💬 2 comments Opened Apr 15, 2026 by alexfazio
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Minimal repro

Tool: flywheel_list_nodes

Input used by affected clients:

  • owners: "me"

Expected canonical shape:

  • owners: ["me"]

Observed behavior:

  • Client flattens array-or-null schema (anyOf: [{"type":"array"}, {"type":"null"}]) into scalar-string guidance.
  • Server rejects scalar with list validation (owners must be an array of strings).

Why this matters

This causes first-call tool failures and requires users/agents to manually discover array wrapping despite correct server schema.

Request

Please preserve array-or-null input schema shape in surfaced MCP tool manifests/instructions for list filters.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #16841

Powered by Codex Action

HarperZ9 · 1 month ago

A small regression test for this would be valuable because array/null/list-filter shapes are easy to flatten accidentally when generating human-facing tool instructions.

The contract I would test is:

  • source schema contains anyOf: [{ type: array, items: { type: string } }, { type: null }] for a filter field;
  • surfaced tool manifest/instructions preserve that the accepted non-null value is an array of strings;
  • generated examples use owners: ["me"], not owners: "me";
  • client-side validation rejects the scalar before dispatch if the schema is available locally;
  • the same test covers oneOf/nullable variants if those are normalized internally.

In Project Telos MCP freshness checks, this is the kind of bug I would classify as tool-surface drift rather than server failure: the server contract is correct, but the host-visible action surface changed shape. A behavior probe with a fixture server that exposes array-or-null filters would make the failure reproducible without depending on the original flywheel_list_nodes server.