Conversation
bolinfest
added a commit
that referenced
this pull request
Mar 27, 2026
## Why `codex-tools` already owned the shared JSON schema parser and the MCP tool schema adapter, but `core/src/tools/spec.rs` still parsed dynamic tools directly. That left the tool-schema boundary split in two different ways: - MCP tools flowed through `codex-tools`, while dynamic tools were still parsed in `codex-core` - the extracted dynamic-tool path initially introduced a dynamic-specific parsed shape even though `codex-tools` already had very similar MCP adapter output This change finishes that extraction boundary in one step. `codex-core` still owns `ResponsesApiTool` assembly, but both MCP tools and dynamic tools now enter that layer through `codex-tools` using the same parsed tool-definition shape. ## What changed - added `tools/src/dynamic_tool.rs` and sibling `tools/src/dynamic_tool_tests.rs` - introduced `parse_dynamic_tool()` in `codex-tools` and switched `core/src/tools/spec.rs` to use it for dynamic tools - added `tools/src/parsed_tool_definition.rs` so both MCP and dynamic adapters return the same `ParsedToolDefinition` - updated `core/src/tools/spec.rs` to build `ResponsesApiTool` through a shared local adapter helper instead of separate MCP and dynamic assembly paths - expanded `core/src/tools/spec_tests.rs` so the dynamic-tool adapter test asserts the full converted `ResponsesApiTool`, including `defer_loading` - updated `codex-rs/tools/README.md` to reflect the shared parsed tool-definition boundary ## Test plan - `cargo test -p codex-tools` - `cargo test -p codex-core --lib tools::spec::` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/15944). * #15953 * __->__ #15944
aibrahim-oai
approved these changes
Mar 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
This continues the
codex-toolsmigration by moving one more piece of generic tool-definition bookkeeping out ofcodex-core.The earlier extraction steps moved shared schema parsing into
codex-tools, butcore/src/tools/spec.rsstill had to supply tool names separately and perform ad hoc rewrites for deferred MCP aliases. That meant the crate boundary was still awkward: the parsed shape coming back fromcodex-toolswas missing part of the definition thatcodex-coreultimately needs to assemble aResponsesApiTool.This change introduces a named
ToolDefinitionincodex-toolsso both MCP tools and dynamic tools cross the crate boundary in the same reusable model.codex-corestill owns the finalResponsesApiToolassembly, but less of the generic tool-definition shaping logic stays behind incore.What changed
ParsedToolDefinitionwith a namedToolDefinitionincodex-rs/tools/src/tool_definition.rscodex-rs/tools/src/tool_definition_tests.rsforrenamed()andinto_deferred()parse_dynamic_tool()andparse_mcp_tool()to returnToolDefinitioncodex-rs/core/src/tools/spec.rsso it adaptsToolDefinitionintoResponsesApiToolinstead of rewriting names and deferred fields inlinecodex-rs/tools/README.mdto reflect the named tool-definition modelTest plan
cargo test -p codex-toolscargo test -p codex-core --lib tools::spec::