feat(oauth): add the dynamic_tools capability from the official models endpoint - #3667
feat(oauth): add the dynamic_tools capability from the official models endpoint#3667sailist wants to merge 5 commits into
Conversation
🦋 Changeset detectedLatest commit: f791d9a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 279e72ed39
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // catalogModelToCapability reads it; stripping it here would silently | ||
| // disable tool-select for catalog-imported aliases. | ||
| "dynamically_loaded_tools", | ||
| "dynamic_tools", |
There was a problem hiding this comment.
Preserve the models.dev capability field
The models.dev catalog schema and compatible mirrors expose this as dynamically_loaded_tools; replacing that wire key with the internal dynamic_tools name causes stripModel() to discard the capability from fetched catalogs. Consequently, catalog-imported models that previously advertised support are emitted without the bit and tool selection remains disabled; retain the wire key here and translate it while normalizing the catalog.
Useful? React with 👍 / 👎.
| dynamic_tools: | ||
| declared.has('dynamic_tools') || | ||
| detected.dynamic_tools === true, |
There was a problem hiding this comment.
Continue recognizing the existing config capability
For users whose existing config.toml model aliases declare dynamically_loaded_tools, this resolver now silently ignores that declaration, so enabling the tool-select flag no longer activates progressive disclosure after upgrading. Since this is being released as a patch rather than a confirmed major change, accept both spellings during resolution and normalize to dynamic_tools internally.
AGENTS.md reference: AGENTS.md:L64-L64
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e274157fc7
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| }); | ||
| const disposable = this._register(this.registry.register(tool, { source: 'mcp' })); | ||
| const disposable = this._register( | ||
| this.registry.register(tool, { source: 'mcp', disclosure: 'deferred' }), |
There was a problem hiding this comment.
Honor deferred:false for MCP authentication tools
When a remote MCP server configured with deferred: false initially enters needs-auth while the tool-select gate is active, this branch still marks its synthetic authentication tool as deferred. AgentToolSelectService consequently hides that tool from the top-level tool list until it is selected dynamically, so the server's explicit inline-disclosure opt-out is not honored during authentication; propagate the server's configured disclosure setting here as the connected-server path does.
Useful? React with 👍 / 👎.
Related Issue
No linked issue — internal feature request.
Problem
The official Kimi Code
/modelsendpoint now returnssupports_dynamic_tools: boolper model, but the refresh/provisioning flow drops the field, so config.toml never records which models accept message-level tool declarations. Meanwhile the runtime capability vocabulary for that feature isdynamically_loaded_tools, which diverges from the upstream field name.What changed
supports_dynamic_toolsfrom the official/modelsresponse (toModelInfoinpackages/oauth/src/managed-kimi-code.ts); non-boolean or absent values are ignored, matching the existing field-tolerance style.capabilities = [ "dynamic_tools" ]in their config.toml entries via the existingcapabilitiesForModel()path; the merge/diff/write pipeline needed no changes.dynamic_tools: renameddynamically_loaded_toolsacross kosong, agent-core-v2, node-sdk, the catalog publish script, and tests (config declaration string,ModelCapabilityfield,ToolSelectServiceand human tool-select consumers). No alias mapping — old spelling is no longer recognized.supports_thinking_typefixtures/assertions inpackages/oauth/test/managed-kimi-code.test.tsto cover parsing and capability mapping (test count unchanged); renamed affected assertions elsewhere.Checklist
/approve).gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.