Add Support for GPT Codex

[jaredbroad]

Pretty awesome coding agent support from openAi now.

https://help.openai.com/en/articles/11096431-openai-codex-cli-getting-started

[jaredbroad]

Alex M's draft suggestion:

QuantConnect MCP client guidelines

1. After calling create_project, store the returned projectId in
   context.projectId.

   • Subsequent create_compile, create_backtest, read_project,
     read_backtest, etc., should default to this stored value unless
     an explicit projectId is provided.

2. After create_compile, store the compileId in context.compileId.

   • create_backtest should use this compileId by default.

3. After create_backtest, store backtestId in context.backtestId.

   • read_backtest, read_backtest_chart, read_backtest_orders,
     read_backtest_insights, update_backtest, and delete_backtest
     should all reuse context.backtestId when no ID is passed.

4. Clear context.projectId, context.compileId, and context.backtestId
   when a new project is created or when the user explicitly resets the session.

5. Every tool call must continue to include all required fields (projectId,
   compileId, backtestId) in the request body sent to the MCP server.
   The client is responsible for auto-populating them from the stored context.

[alexmahrou]

Thanks @jaredbroad — I think I’ve narrowed it down and here’s a clean fix path

TL;DR
Codex’s MCP adapter is failing to convert tools because each tool’s inputSchema is missing a top‑level "type": "object" (and a few places use "integer"). Strict clients (Codex) require object‑shaped params; permissive clients (Inspector/Claude Desktop) often accept looser schemas, which is why this only surfaces in Codex. The durable fix is to emit strict, Draft‑07‑style object schemas for every tool input.

---

What I’m seeing

• Repeated error in Codex: MCP tool to OpenAI tool: Error("missing field \type`", line: 0, column: 0)`.
• tools/list shows inputSchema with properties but no top‑level type: object.
• Some fields use JSON Schema "integer"; Codex prefers "number" (integer‑like behavior can be expressed via multipleOf: 1).

Why this happens

• OpenAI/strict MCP clients expect tool parameters to be a single object:
  { "type": "object", "properties": {…}, "required": […], "additionalProperties": false }.
• If type is missing (or schema composition is complex), Codex refuses to adapt the tool to OpenAI’s function/tool format and throws the error above.

---

Proposed fixes (server‑side preferred)

A) Emit strict object schemas via typed models (recommended)

• Define a Pydantic BaseModel for each tool’s args and use it as the single parameter to @mcp.tool().
• Conventions that keep compatibility with Codex and Anthropic:
  • Top‑level type: object (Pydantic ensures this).
  • Avoid integer; prefer number + multipleOf: 1 if integer‑like.
  • Explicit required (by field presence) and additionalProperties: false.
  • Avoid unions/oneOf for inputs; keep inputs boring and explicit.

B) Temporary shim (if refactor needs time)

• Intercept tools/list and, for each tool’s inputSchema:
  • Inject "type": "object" when missing.
  • Rewrite any "type": "integer" → "type": "number" (optionally add multipleOf: 1).
• This unblocks Codex immediately while you migrate tools to typed models.

C) Keep MCP modern

• No need to downgrade MCP or mutate tool descriptors (e.g., forcing tool["type"] = "function"). The issue is the params schema, not the tool descriptor.

---

Validation steps

1. Inspector: tools/list must show each tool’s inputSchema.type == "object" and additionalProperties == false.
2. Codex: Connect and call a few tools—conversion should succeed (no missing field type).
3. Optional test: Add a small test that recursively asserts no type == "integer" appears in any tool schema.

---

Client context behavior (agreeing with the guideline Jared opened)

Stateful defaults on the client side reduce friction while keeping wire calls explicit.

• After create_project → store context.projectId.
• Default read_project, create_compile, create_backtest, etc., to context.projectId unless an explicit projectId is passed.
• After create_compile → store context.compileId; have create_backtest default to this.
• After create_backtest → store context.backtestId; default read/update/delete_backtest* calls to it when no ID is passed.
• Clear context.{projectId,compileId,backtestId} on new project creation or explicit session reset.
• Important: The client must still send all required IDs in the request body to the MCP server—just auto‑populate them from the stored context unless overridden by the user.

---

Net effect

• Strict, object‑shaped schemas make the server portable across clients (Codex/Anthropic) and remove the recurring conversion error.
• The client‑side context pattern matches typical IDE/agent UX and keeps calls deterministic on the wire.

Happy to open a follow‑up PR with either the Pydantic refactor or the interim shim if that’s helpful.

[jaredbroad]

master...alexmahrou:mcp-server:codex/fix-mcp-tool-schemas-for-codex-compatibility