tool can give alternative definition by model

[bryanchen-d]

Pass model info into the alternativeDefinition method of ICopilotTool to allow tools to provide alternative definition based on different models passing in.

Fixes microsoft/vscode#270663

[Copilot]

Pull Request Overview

Adds model-aware alternativeDefinition support so tools can provide different LanguageModelToolInformation depending on the selected model.

• Extends ICopilotTool.alternativeDefinition to accept the current model.
• Applies alternativeDefinition in three getEnabledTools implementations before filtering.
• Updates interface documentation to mention model-based customization.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
test/base/extHostContext/simulationExtHostToolsService.ts	Adds model-aware mapping to substitute tool definitions before filtering.
src/extension/tools/vscode-node/toolsService.ts	Introduces model-based alternativeDefinition application prior to existing enable/disable logic.
src/extension/tools/node/test/testToolsService.ts	Mirrors production logic for model-driven alternativeDefinition in test service.
src/extension/tools/common/toolsRegistry.ts	Updates ICopilotTool interface and docs to accept model info in alternativeDefinition.

[pwang347]

@bryanchen-d Just an idea, would it make sense to just expose tool-specific options? e.g., for removing VERY frequently we can have a feature flag like tools.manage_todo_list.removeVeryFrequentlyClause. And then we have a way for models to pass this as an option. Thinking from the perspective that things should be easier for even external folks to make contributions, I think centralizing the per-provider/model logic would actually be ideal.

[bryanchen-d]

@bryanchen-d Just an idea, would it make sense to just expose tool-specific options? e.g., for removing VERY frequently we can have a feature flag like tools.manage_todo_list.removeVeryFrequentlyClause. And then we have a way for models to pass this as an option. Thinking from the perspective that things should be easier for even external folks to make contributions, I think centralizing the per-provider/model logic would actually be ideal.

Not sure if I follow, for models to pass options into tools, we already have inputSchema field to tell models what parameters each tool can support.

This scenario is for passing the tool definition to models before models use the tool.

Basically the challenge here is that the to-do list tool is defined in vscode while we want to modify the description in the extension based on model. Ideally we should centralize the tool definition in the extension.

[pwang347]

@bryanchen-d Just an idea, would it make sense to just expose tool-specific options? e.g., for removing VERY frequently we can have a feature flag like tools.manage_todo_list.removeVeryFrequentlyClause. And then we have a way for models to pass this as an option. Thinking from the perspective that things should be easier for even external folks to make contributions, I think centralizing the per-provider/model logic would actually be ideal.

Not sure if I follow, for models to pass options into tools, we already have inputSchema field to tell models what parameters each tool can support.

This scenario is for passing the tool definition to models before models use the tool.

Basically the challenge here is that the to-do list tool is defined in vscode while we want to modify the description in the extension based on model. Ideally we should centralize the tool definition in the extension.

@bhavyaus has been refactoring code to centralize prompts belonging to a specific provider (e.g., see https://github.com/microsoft/vscode-copilot-chat/blob/main/src/extension/prompts/node/agent/openAIPrompts.tsx). Wondering if we could also control this behaviour from that file - but I think it could probably be done as a followup since we still have a lot of areas with these model conditionals sprinkled in several other places like the base instructions.

Played around a bit with the idea here: https://github.com/microsoft/vscode-copilot-chat/pull/1681/files#diff-982afe7aa9d84aad97affd4ffbc0cab2bdda7e39338a69ec36931d413d9d3736

[bryanchen-d]

@bryanchen-d Just an idea, would it make sense to just expose tool-specific options? e.g., for removing VERY frequently we can have a feature flag like tools.manage_todo_list.removeVeryFrequentlyClause. And then we have a way for models to pass this as an option. Thinking from the perspective that things should be easier for even external folks to make contributions, I think centralizing the per-provider/model logic would actually be ideal.

Not sure if I follow, for models to pass options into tools, we already have inputSchema field to tell models what parameters each tool can support.
This scenario is for passing the tool definition to models before models use the tool.
Basically the challenge here is that the to-do list tool is defined in vscode while we want to modify the description in the extension based on model. Ideally we should centralize the tool definition in the extension.

@bhavyaus has been refactoring code to centralize prompts belonging to a specific provider (e.g., see https://github.com/microsoft/vscode-copilot-chat/blob/main/src/extension/prompts/node/agent/openAIPrompts.tsx). Wondering if we could also control this behaviour from that file - but I think it could probably be done as a followup since we still have a lot of areas with these model conditionals sprinkled in several other places like the base instructions.

Played around a bit with the idea here: https://github.com/microsoft/vscode-copilot-chat/pull/1681/files#diff-982afe7aa9d84aad97affd4ffbc0cab2bdda7e39338a69ec36931d413d9d3736

Hmm, then does the whole prompt become :

{system prompt generated given specific model provider}
{system prompt generated given specific model}
     { specialized instruction for individual tool}
...
{ tool definition}
...
{ user input}

?
Then the tool definitions will be in two different places, if we can have the tool definition generated given specific model, we can have it in one place to not confuse the models:

{system prompt generated given specific model provider}
{system prompt generated given specific model}
...
{ tool definition generated given specific model}
...
{ user input}

[roblourens]

And gpt-5-codex