Skip to content

Use the 2025-06-18 elicitation capability shape#20562

Draft
abhinav-oai wants to merge 1 commit intomainfrom
abhinav/mcp-2025-06-18-elicitation-shape
Draft

Use the 2025-06-18 elicitation capability shape#20562
abhinav-oai wants to merge 1 commit intomainfrom
abhinav/mcp-2025-06-18-elicitation-shape

Conversation

@abhinav-oai
Copy link
Copy Markdown
Collaborator

Why

Codex currently negotiates MCP 2025-06-18, where the client elicitation capability is represented as an empty object. We were still serializing capabilities.elicitation.form, which belongs to the later capability shape and can cause strict 2025-06-18 servers to reject initialize with an unrecognized-field error.

This keeps the handshake aligned with the protocol version Codex actually negotiates and fixes the compatibility regression tracked in #17492.

What

  • Serialize the client elicitation capability as elicitation: {} for 2025-06-18.
  • Keep elicitation advertised for both Codex Apps and custom MCP servers.
  • Tighten regression coverage so the test asserts both the Rust value and the serialized wire shape.

Verification

  • cargo test -p codex-mcp

Next steps

  • Decide whether tool_call_mcp_elicitation=false should also suppress capability advertisement during initialize.
  • Revisit form / url capability advertisement when Codex is ready to negotiate MCP 2025-11-25, which defines that newer shape.

@mzeng-openai
Copy link
Copy Markdown
Collaborator

Can we make sure to test elicitations from connectors and custom MCPs and make sure they don't regress? For context they are supported it's just we don't advertise the mcp version as 2025-11-25

Bojun-Vvibe added a commit to Bojun-Vvibe/oss-contributions that referenced this pull request May 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants