Neon MCP tools expose camelCase arguments but server requires snake_case

What version of Codex CLI is running?

codex-cli 0.147.0 (reproduced from the Codex Desktop host)

What subscription do you have?

ChatGPT (Codex Desktop; exact plan omitted)

Which model were you using?

GPT-5.6 Sol. This appears model-independent because validation fails at the connector/MCP schema boundary.

What platform is your computer?

Windows 11 Home 10.0.26200, x64

What issue are you seeing?

The official Neon Postgres plugin (1.0.0) exposes MCP tool arguments to Codex in camelCase, but the Neon MCP server validates the corresponding arguments in snake_case.

For example, Codex's host-visible declaration for run_sql requires:

{
  projectId: string;
  branchId?: string;
  databaseName?: string;
  sql: string;
}

Calling the tool with the required host-visible projectId reaches the Neon server as projectId. The server rejects it because it requires project_id:

MCP error -32602: Input validation error: Invalid arguments for tool run_sql:
[
  {
    "code": "invalid_type",
    "expected": "string",
    "received": "undefined",
    "path": ["project_id"],
    "message": "Required"
  },
  {
    "code": "unrecognized_keys",
    "keys": ["projectId"],
    "path": [],
    "message": "Unrecognized key(s) in object: 'projectId'"
  }
]

Trying the server-native spelling does not provide a workaround. The connector's host-side schema rejects/removes project_id before dispatch and reports that projectId is missing:

Parameters failed connector schema validation:
projectId [required]: Missing required property

Clamp rewrite: Removed additional property 'project_id'

This leaves no argument spelling that can pass both validation layers.

What steps can reproduce the bug?

1. Enable the official Neon Postgres plugin in Codex Desktop and authenticate it with Neon OAuth.

2. Use an existing Neon project. The project can be discovered successfully through the plugin.

3. Inspect/discover the run_sql tool. Observe that the host-visible schema requires projectId.

4. Invoke run_sql with sanitized arguments equivalent to:

   {
     "projectId": "<existing-project-id>",
     "sql": "SELECT current_database();"
   }
   

5. Observe MCP error -32602: project_id is required and projectId is unrecognized.

6. Retry with project_id instead of projectId.

7. Observe host-side connector validation removing project_id and requiring projectId.

The same pattern appears in other projected Neon tools whose original identifiers have underscores, including branch_id/branchId and database_name/databaseName.

What is the expected behavior?

Codex should preserve the Neon MCP server's original tool input schema and parameter names end-to-end. If the host intentionally camelCases MCP schemas, it must translate arguments back to the server's original field names before dispatch. A valid call must not be trapped between mutually incompatible host-side and server-side schemas.

Additional information

• Neon Postgres plugin version: 1.0.0
• Neon CLI control version: 4.13.1
• OAuth authentication and project discovery work.
• Retrying/restarting does not change the result.
• The equivalent read-only query succeeds through Neon CLI against the same account/project, isolating this from database availability, permissions, and SQL syntax.
• The Neon project has role-password storage enabled, so this is not the data-plane/password-storage issue tracked in neondatabase/mcp-server-neon#267.
• The MCP call fails during argument validation before SQL reaches PostgreSQL.
• Project IDs, credentials, connection strings, database contents, and user metadata have been removed from this report.

Possibly related Codex issues:

• https://github.com/openai/codex/issues/19155
• https://github.com/openai/codex/issues/36298
• https://github.com/openai/codex/issues/13768

Upstream Neon MCP server:

• https://github.com/neondatabase/mcp-server-neon
• https://github.com/neondatabase/mcp-server-neon/issues/267

Official Codex MCP documentation:

• https://learn.chatgpt.com/docs/extend/mcp?surface=cli

Start by reproducing the Neon run_sql call and tracing Codex's MCP tool schema projection and argument dispatch. Compare the host-visible camelCase schema with the server's snake_case schema, then verify that a valid projectId call reaches Neon as project_id without host-side validation rejecting it.