Invalid schema for function. GPT models

[IvanMurzak]

Copilot stopped accepting symbols in json schema of MCP tools:

• [] - arrays
• <> - generic classes
• + - nested classes

Related

Upstream cause:

• [CRITICAL BUG] CAPIError: 400 Invalid schema for function... for GPT models github/copilot-cli#2223 — strict uri-reference validator in GPT-family clients

Same-class issues on Unity-MCP:

• Failed to validate tool f1e_GameObject_Modify: Error: tool parameters array type must have items #125 — original [] appearance (where GetTypeId was introduced)
• Failed to validate tool d95_GameObject_ModifyComponent: TypeError: Cannot use 'in' operator to search for 'type' in true #95 — same class, GameObject_ModifyComponent era
• Some tools not working in VSCode #171 — VSCode client-side parsing variant
• Cursor agent struggles with $ref in InputSchema; array fields are easier to handle when flattened #284 — flatten $ref request (wontfix)
• [CRITICAL] MCP Tool Schema Error: Missing inputSchema for Parameter-Less Tools #440 — zero-arg tools missing inputSchema
• mcp tool is incompatible with GPT-5.2-Codex #492 — GPT-5.2-Codex + MCP
• Sorry, your request failed. Please try again. #630 — '#/$defs/...ObjectRef[]' is not a 'uri-reference'
• VS Code Github Copilot - MCP Error #666 — '#/$defs/System.String[]' is not a 'uri-reference'
• Simplify data models path #676 — simplify data models path (naming verbosity; same code area, should ship together)

Related PRs:

• fix: add dummy parameter to zero-arg MCP tools for Copilot compatibility #552 (merged) — dummy parameter fix for zero-arg Copilot tools
• feat: sanitize JSON Schema $defs/$ref for strict MCP client compatibility #629 (closed, not merged) — server-side JsonSchemaSanitizer rejected on correctness grounds
• Change searchInFolders type from string[] to List<string> #667 (open) — per-tool string[] → List<string> workaround

ReflectorNet (where the fix likely lives):

• SerializedMember should respect json schema ReflectorNet#35 — SerializedMember should respect JSON Schema
• Fix SerializedMember JSON Schema to accept any value type ReflectorNet#36 — related PR
• Refactor type name retrieval to use GetTypeId method ReflectorNet#41 — refactored type-name retrieval to GetTypeId

⚠️ Warning — custom format is risky

Making a custom format for type names is dangerous because the C# type system has many edge-case shapes. Under-specification causes silent collisions (PR #629 was rejected partly for this reason). Any custom format must be:

• Injective — no two distinct types collapse to the same short name
• Round-trip clean — GetType(format(t)) == t for every t

C# syntactic shapes any custom format must cover

1. Primitive value types (System.Int32, System.Boolean, System.Double, System.Char)
2. Reference types (System.String, user classes)
3. Enum types
4. Struct types (user-defined value types)
5. Single-dimensional arrays — T[]
6. Multi-dimensional arrays — T[,], T[,,], T[,,,] (arbitrary rank)
7. Jagged arrays — T[][], T[][][], and mixed T[,][]
8. Closed generic types — List<int>, Dictionary<string, int>
9. Open generic type definitions — List<>, Dictionary<,>
10. Nested types — Outer+Inner
11. Nested generic types — Outer<T>+Inner, Outer<T>+Inner<U>
12. Deeply nested generics — List<Dictionary<string, List<int>>>
13. Nullable value types — System.Nullable<T> / int?
14. Tuples — System.ValueTuple<T1, T2, …>
15. Generic type parameters — T, U (for reflection over unbound generics)
16. Assembly-qualified names — Namespace.Type, Assembly, Version=..., Culture=..., PublicKeyToken=...
17. Global-namespace types (no namespace prefix)
18. Module types — <Module> and CLR-internal names
19. Types whose FullName contains identifier characters that could collide with the sanitizer's separators (underscores, dots, Unicode letters)
20. Pointer types — int* (unsafe)
21. ByRef types — ref int, out T, in T
22. Types from generic type definitions with constraints — List<T> where T : struct
23. Covariant / contravariant generic args — IEnumerable<out T>, IComparer<in T>
24. Types in assemblies with unusual naming — including dotted / dashed / Unicode assembly names

Solution (proposed)

During JSON Schema creation and during parsing type from name in SerializedMember and maybe in TypeUtils classes, handle the problematic symbols by replacing them with something else.

Proposed replacements:

• + → ..
• [] → __arr

(Alternative vocabularies under consideration — see #676 for related simplification work; both issues touch the same code and should ship together.)

[alexandre433]

TL;DR Issue looks like is mostly on GPT models after creating another session. Claude Models run OK in my experience.

I've just found this little think out; I've just had this issue, I'm using Copilot CLI.
I was using GPT 5.5 no issue with all, or almost all the tools, turned on.
Then I went to create another window/session to proceed with changes GPT 5.5 made for another lower thinking model to do, and I was going to do it in Sonnet 4.6 but I chose GPT 5.3 Codex, and it threw that error.

So I was thinking, but I was just using it without any issue other other session - so i created ANOTHER session and this time i tried gpt 5.4 mini - same error;
Then swapped to Claude Haiku 4.5 no errors. All tools available.

For this test I just enabled 4 that normally threw that error:

And copilot cli "proof":
GPT 5.5 -> 5.3 Codex

Me trying to remove tool by tool to see if it was only 1 issue in 1 tool:

3rd session:

• GPT 5.3 Codex > GPT 5.4 mini > error
• GPT 5.4 mini > Claude Haiku 4.5 > OK

My assumption:
Whenever you're using 1 session with the MCP, everything seems to go OK for the most part; Whenever you create another session with the same model i.e. GPT xx, it'll start throwing these errors, unless you use Claude's Models.

Hope this helps! @IvanMurzak

[IvanMurzak]

This issue is resolved in IvanMurzak/ReflectorNet#77 by using "sanitization" approach. Verified, it is harmless for normally functional LLM models, they still properly recognize the JSON schema.