Enable parallel tool calls by default (#11031)

This commit is contained in:
Daniel 2026-01-29 01:29:15 -05:00 committed by GitHub
parent 010aba24b7
commit ed35b09aad
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
66 changed files with 153 additions and 582 deletions

View file

@ -6,13 +6,7 @@ import type { Keys, Equals, AssertEqual } from "./type-fu.js"
* ExperimentId
*/
export const experimentIds = [
"preventFocusDisruption",
"imageGeneration",
"runSlashCommand",
"multipleNativeToolCalls",
"customTools",
] as const
export const experimentIds = ["preventFocusDisruption", "imageGeneration", "runSlashCommand", "customTools"] as const
export const experimentIdsSchema = z.enum(experimentIds)
@ -26,7 +20,6 @@ export const experimentsSchema = z.object({
preventFocusDisruption: z.boolean().optional(),
imageGeneration: z.boolean().optional(),
runSlashCommand: z.boolean().optional(),
multipleNativeToolCalls: z.boolean().optional(),
customTools: z.boolean().optional(),
})

View file

@ -84,8 +84,8 @@ export interface ApiHandlerCreateMessageMetadata {
tool_choice?: OpenAI.Chat.ChatCompletionCreateParams["tool_choice"]
/**
* Controls whether the model can return multiple tool calls in a single response.
* When true, parallel tool calls are enabled (OpenAI's parallel_tool_calls=true).
* When false (default), only one tool call is returned per response.
* When true (default), parallel tool calls are enabled (OpenAI's parallel_tool_calls=true).
* When false, only one tool call is returned per response.
*/
parallelToolCalls?: boolean
/**

View file

@ -1197,7 +1197,7 @@ describe("VertexHandler", () => {
}),
}),
]),
tool_choice: { type: "auto", disable_parallel_tool_use: true },
tool_choice: { type: "auto", disable_parallel_tool_use: false },
}),
undefined,
)

View file

@ -514,7 +514,7 @@ describe("AnthropicHandler", () => {
expect(mockCreate).toHaveBeenCalledWith(
expect.objectContaining({
tool_choice: { type: "auto", disable_parallel_tool_use: true },
tool_choice: { type: "auto", disable_parallel_tool_use: false },
}),
expect.anything(),
)
@ -535,7 +535,7 @@ describe("AnthropicHandler", () => {
expect(mockCreate).toHaveBeenCalledWith(
expect.objectContaining({
tool_choice: { type: "any", disable_parallel_tool_use: true },
tool_choice: { type: "any", disable_parallel_tool_use: false },
}),
expect.anything(),
)
@ -581,7 +581,7 @@ describe("AnthropicHandler", () => {
expect(mockCreate).toHaveBeenCalledWith(
expect.objectContaining({
tool_choice: { type: "tool", name: "get_weather", disable_parallel_tool_use: true },
tool_choice: { type: "tool", name: "get_weather", disable_parallel_tool_use: false },
}),
expect.anything(),
)

View file

@ -214,9 +214,9 @@ describe("DeepInfraHandler", () => {
]),
}),
)
// parallel_tool_calls should be false when not explicitly set
// parallel_tool_calls should be true by default when not explicitly set
const callArgs = mockCreate.mock.calls[0][0]
expect(callArgs).toHaveProperty("parallel_tool_calls", false)
expect(callArgs).toHaveProperty("parallel_tool_calls", true)
})
it("should include tool_choice when provided", async () => {
@ -264,8 +264,8 @@ describe("DeepInfraHandler", () => {
// Tools are now always present (minimum 6 from ALWAYS_AVAILABLE_TOOLS)
expect(callArgs).toHaveProperty("tools")
expect(callArgs).toHaveProperty("tool_choice")
// parallel_tool_calls should be false when not explicitly set
expect(callArgs).toHaveProperty("parallel_tool_calls", false)
// parallel_tool_calls should be true by default when not explicitly set
expect(callArgs).toHaveProperty("parallel_tool_calls", true)
})
it("should yield tool_call_partial chunks during streaming", async () => {

View file

@ -82,9 +82,9 @@ describe("LmStudioHandler Native Tools", () => {
]),
}),
)
// parallel_tool_calls should be false when not explicitly set
// parallel_tool_calls should be true by default when not explicitly set
const callArgs = mockCreate.mock.calls[0][0]
expect(callArgs).toHaveProperty("parallel_tool_calls", false)
expect(callArgs).toHaveProperty("parallel_tool_calls", true)
})
it("should include tool_choice when provided", async () => {
@ -128,8 +128,8 @@ describe("LmStudioHandler Native Tools", () => {
// Tools are now always present (minimum 6 from ALWAYS_AVAILABLE_TOOLS)
expect(callArgs).toHaveProperty("tools")
expect(callArgs).toHaveProperty("tool_choice")
// parallel_tool_calls should be false when not explicitly set
expect(callArgs).toHaveProperty("parallel_tool_calls", false)
// parallel_tool_calls should be true by default when not explicitly set
expect(callArgs).toHaveProperty("parallel_tool_calls", true)
})
it("should yield tool_call_partial chunks during streaming", async () => {

View file

@ -61,7 +61,7 @@ describe("OpenAiHandler native tools", () => {
function: expect.objectContaining({ name: "test_tool" }),
}),
]),
parallel_tool_calls: false,
parallel_tool_calls: true,
}),
expect.anything(),
)

View file

@ -635,7 +635,7 @@ describe("OpenAiHandler", () => {
temperature: 0,
tools: undefined,
tool_choice: undefined,
parallel_tool_calls: false,
parallel_tool_calls: true,
},
{ path: "/models/chat/completions" },
)
@ -684,7 +684,7 @@ describe("OpenAiHandler", () => {
],
tools: undefined,
tool_choice: undefined,
parallel_tool_calls: false,
parallel_tool_calls: true,
},
{ path: "/models/chat/completions" },
)

View file

@ -99,7 +99,7 @@ describe("QwenCodeHandler Native Tools", () => {
}),
}),
]),
parallel_tool_calls: false,
parallel_tool_calls: true,
}),
)
})
@ -145,7 +145,7 @@ describe("QwenCodeHandler Native Tools", () => {
const callArgs = mockCreate.mock.calls[mockCreate.mock.calls.length - 1][0]
expect(callArgs).toHaveProperty("tools")
expect(callArgs).toHaveProperty("tool_choice")
expect(callArgs).toHaveProperty("parallel_tool_calls", false)
expect(callArgs).toHaveProperty("parallel_tool_calls", true)
})
it("should yield tool_call_partial chunks during streaming", async () => {

View file

@ -375,7 +375,7 @@ describe("UnboundHandler", () => {
}),
}),
]),
parallel_tool_calls: false,
parallel_tool_calls: true,
}),
expect.objectContaining({
headers: {
@ -435,7 +435,7 @@ describe("UnboundHandler", () => {
const callArgs = mockCreate.mock.calls[mockCreate.mock.calls.length - 1][0]
expect(callArgs).toHaveProperty("tools")
expect(callArgs).toHaveProperty("tool_choice")
expect(callArgs).toHaveProperty("parallel_tool_calls", false)
expect(callArgs).toHaveProperty("parallel_tool_calls", true)
})
it("should yield tool_call_partial chunks during streaming", async () => {

View file

@ -366,7 +366,7 @@ describe("VercelAiGatewayHandler", () => {
)
})
it("should include parallel_tool_calls: false by default", async () => {
it("should include parallel_tool_calls: true by default", async () => {
const handler = new VercelAiGatewayHandler(mockOptions)
const messageGenerator = handler.createMessage("test prompt", [], {
@ -378,7 +378,7 @@ describe("VercelAiGatewayHandler", () => {
expect(mockCreate).toHaveBeenCalledWith(
expect.objectContaining({
tools: expect.any(Array),
parallel_tool_calls: false,
parallel_tool_calls: true,
}),
)
})

View file

@ -339,7 +339,7 @@ describe("XAIHandler", () => {
}),
}),
]),
parallel_tool_calls: false,
parallel_tool_calls: true,
}),
)
})
@ -393,7 +393,7 @@ describe("XAIHandler", () => {
const callArgs = mockCreate.mock.calls[mockCreate.mock.calls.length - 1][0]
expect(callArgs).toHaveProperty("tools")
expect(callArgs).toHaveProperty("tool_choice")
expect(callArgs).toHaveProperty("parallel_tool_calls", false)
expect(callArgs).toHaveProperty("parallel_tool_calls", true)
})
it("should yield tool_call_partial chunks during streaming", async () => {

View file

@ -95,7 +95,7 @@ export abstract class BaseOpenAiCompatibleProvider<ModelName extends string>
stream_options: { include_usage: true },
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
// Add thinking parameter if reasoning is enabled and model supports it

View file

@ -146,7 +146,7 @@ export class CerebrasHandler extends BaseProvider implements SingleCompletionHan
// Native tool calling support
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
try {

View file

@ -74,7 +74,7 @@ export class DeepInfraHandler extends RouterProvider implements SingleCompletion
prompt_cache_key,
tools: this.convertToolsForOpenAI(_metadata?.tools),
tool_choice: _metadata?.tool_choice,
parallel_tool_calls: _metadata?.parallelToolCalls ?? false,
parallel_tool_calls: _metadata?.parallelToolCalls ?? true,
} as OpenAI.Chat.Completions.ChatCompletionCreateParamsStreaming
if (this.supportsTemperature(modelId)) {

View file

@ -72,7 +72,7 @@ export class DeepSeekHandler extends OpenAiHandler {
...(isThinkingModel && { thinking: { type: "enabled" } }),
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
// Add max_tokens if needed

View file

@ -90,7 +90,7 @@ export class LmStudioHandler extends BaseProvider implements SingleCompletionHan
stream: true,
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
if (this.options.lmStudioSpeculativeDecodingEnabled && this.options.lmStudioDraftModelId) {

View file

@ -321,7 +321,7 @@ export class OpenAiCodexHandler extends BaseProvider implements SingleCompletion
}
}),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
return body

View file

@ -378,7 +378,7 @@ export class OpenAiNativeHandler extends BaseProvider implements SingleCompletio
}
}),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
// Include text.verbosity only when the model explicitly supports it

View file

@ -161,7 +161,7 @@ export class OpenAiHandler extends BaseProvider implements SingleCompletionHandl
...(reasoning && reasoning),
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
// Add max_tokens if needed
@ -229,7 +229,7 @@ export class OpenAiHandler extends BaseProvider implements SingleCompletionHandl
// Tools are always present (minimum ALWAYS_AVAILABLE_TOOLS)
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
// Add max_tokens if needed
@ -348,7 +348,7 @@ export class OpenAiHandler extends BaseProvider implements SingleCompletionHandl
// Tools are always present (minimum ALWAYS_AVAILABLE_TOOLS)
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
// O3 family models do not support the deprecated max_tokens parameter
@ -382,7 +382,7 @@ export class OpenAiHandler extends BaseProvider implements SingleCompletionHandl
// Tools are always present (minimum ALWAYS_AVAILABLE_TOOLS)
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
// O3 family models do not support the deprecated max_tokens parameter

View file

@ -228,7 +228,7 @@ export class QwenCodeHandler extends BaseProvider implements SingleCompletionHan
max_completion_tokens: model.info.maxTokens,
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
const stream = await this.callApiWithRetry(() => client.chat.completions.create(requestOptions))

View file

@ -121,7 +121,7 @@ export class UnboundHandler extends RouterProvider implements SingleCompletionHa
},
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
if (this.supportsTemperature(modelId)) {

View file

@ -63,7 +63,7 @@ export class VercelAiGatewayHandler extends RouterProvider implements SingleComp
stream_options: { include_usage: true },
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
const completion = await this.client.chat.completions.create(body)

View file

@ -68,7 +68,7 @@ export class XAIHandler extends BaseProvider implements SingleCompletionHandler
...(reasoning && reasoning),
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
let stream

View file

@ -103,7 +103,7 @@ export class ZAiHandler extends BaseOpenAiCompatibleProvider<string> {
thinking: useReasoning ? { type: "enabled" } : { type: "disabled" },
tools: this.convertToolsForOpenAI(metadata?.tools),
tool_choice: metadata?.tool_choice,
parallel_tool_calls: metadata?.parallelToolCalls ?? false,
parallel_tool_calls: metadata?.parallelToolCalls ?? true,
}
return this.client.chat.completions.create(params)

View file

@ -264,51 +264,6 @@ describe("presentAssistantMessage - Image Handling in Native Tool Calling", () =
expect(textBlocks.length).toBe(0)
})
it("should send tool_result with is_error for skipped tools in native tool calling when didAlreadyUseTool is true", async () => {
// Simulate multiple tool calls with native protocol
const toolCallId1 = "tool_call_003"
const toolCallId2 = "tool_call_004"
mockTask.assistantMessageContent = [
{
type: "tool_use",
id: toolCallId1,
name: "read_file",
params: { path: "test.txt" },
},
{
type: "tool_use",
id: toolCallId2,
name: "write_to_file",
params: { path: "output.txt", content: "test" },
},
]
// First tool was already used
mockTask.didAlreadyUseTool = true
// Process the second tool (should be skipped)
mockTask.currentStreamingContentIndex = 1
await presentAssistantMessage(mockTask)
// Find the tool_result for the second tool
const toolResult = mockTask.userMessageContent.find(
(item: any) => item.type === "tool_result" && item.tool_use_id === toolCallId2,
)
// Verify that a tool_result block was created (not a text block)
expect(toolResult).toBeDefined()
expect(toolResult.tool_use_id).toBe(toolCallId2)
expect(toolResult.is_error).toBe(true)
expect(toolResult.content).toContain("was not executed because a tool has already been used")
// Ensure no text blocks were added for this rejection
const textBlocks = mockTask.userMessageContent.filter(
(item: any) => item.type === "text" && item.text.includes("was not executed because"),
)
expect(textBlocks.length).toBe(0)
})
it("should reject subsequent tool calls when a legacy/XML-style tool call is encountered", async () => {
mockTask.assistantMessageContent = [
{

View file

@ -217,32 +217,6 @@ describe("presentAssistantMessage - Unknown Tool Handling", () => {
expect(mockTask.userMessageContentReady).toBe(true)
})
it("should still work with didAlreadyUseTool flag for unknown tool", async () => {
const toolCallId = "tool_call_already_used_test"
mockTask.assistantMessageContent = [
{
type: "tool_use",
id: toolCallId,
name: "unknown_tool",
params: {},
partial: false,
},
]
mockTask.didAlreadyUseTool = true
await presentAssistantMessage(mockTask)
// When didAlreadyUseTool is true, should send error tool_result
const toolResult = mockTask.userMessageContent.find(
(item: any) => item.type === "tool_result" && item.tool_use_id === toolCallId,
)
expect(toolResult).toBeDefined()
expect(toolResult.is_error).toBe(true)
expect(toolResult.content).toContain("was not executed because a tool has already been used")
})
it("should still work with didRejectTool flag for unknown tool", async () => {
const toolCallId = "tool_call_rejected_test"
mockTask.assistantMessageContent = [

View file

@ -126,25 +126,6 @@ export async function presentAssistantMessage(cline: Task) {
break
}
// Get parallel tool calling state from experiments
const mcpState = await cline.providerRef.deref()?.getState()
const mcpParallelToolCallsEnabled = mcpState?.experiments?.multipleNativeToolCalls ?? false
if (!mcpParallelToolCallsEnabled && cline.didAlreadyUseTool) {
const toolCallId = mcpBlock.id
const errorMessage = `MCP tool [${mcpBlock.name}] was not executed because a tool has already been used in this message. Only one tool may be used per message.`
if (toolCallId) {
cline.pushToolResultToUserContent({
type: "tool_result",
tool_use_id: toolCallId,
content: errorMessage,
is_error: true,
})
}
break
}
// Track if we've already pushed a tool result
let hasToolResult = false
const toolCallId = mcpBlock.id
@ -198,10 +179,6 @@ export async function presentAssistantMessage(cline: Task) {
}
hasToolResult = true
// Only set didAlreadyUseTool when parallel tool calling is disabled
if (!mcpParallelToolCallsEnabled) {
cline.didAlreadyUseTool = true
}
}
const toolDescription = () => `[mcp_tool: ${mcpBlock.serverName}/${mcpBlock.toolName}]`
@ -441,24 +418,6 @@ export async function presentAssistantMessage(cline: Task) {
break
}
// Get parallel tool calling state from experiments (stateExperiments already fetched above)
const parallelToolCallsEnabled = stateExperiments?.multipleNativeToolCalls ?? false
if (!parallelToolCallsEnabled && cline.didAlreadyUseTool) {
// Ignore any content after a tool has already been used.
// For native tool calling, we must send a tool_result for every tool_use to avoid API errors
const errorMessage = `Tool [${block.name}] was not executed because a tool has already been used in this message. Only one tool may be used per message. You must assess the first tool's result before proceeding to use the next tool.`
cline.pushToolResultToUserContent({
type: "tool_result",
tool_use_id: toolCallId,
content: errorMessage,
is_error: true,
})
break
}
// Track if we've already pushed a tool result for this tool call (native tool calling only)
let hasToolResult = false
@ -543,10 +502,6 @@ export async function presentAssistantMessage(cline: Task) {
}
hasToolResult = true
// Only set didAlreadyUseTool when parallel tool calling is disabled
if (!parallelToolCallsEnabled) {
cline.didAlreadyUseTool = true
}
}
const askApproval = async (

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -10,27 +10,15 @@ ALL responses MUST show ANY `language construct` OR filename reference as clicka
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response.
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.
# Tool Use Guidelines
# Tool Use Guidelines
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like `ls` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
4. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.
5. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
It is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.
====

View file

@ -1,66 +1,39 @@
import { getToolUseGuidelinesSection } from "../tool-use-guidelines"
import { EXPERIMENT_IDS } from "../../../../shared/experiments"
describe("getToolUseGuidelinesSection", () => {
describe("with MULTIPLE_NATIVE_TOOL_CALLS disabled (default)", () => {
it("should include proper numbered guidelines", () => {
const guidelines = getToolUseGuidelinesSection()
it("should include proper numbered guidelines", () => {
const guidelines = getToolUseGuidelinesSection()
// Check that all numbered items are present with correct numbering
expect(guidelines).toContain("1. Assess what information")
expect(guidelines).toContain("2. Choose the most appropriate tool")
expect(guidelines).toContain("3. If multiple actions are needed")
expect(guidelines).toContain("4. After each tool use")
})
it("should include single-tool-per-message guidance when experiment disabled", () => {
const guidelines = getToolUseGuidelinesSection({})
expect(guidelines).toContain("use one tool at a time per message")
expect(guidelines).not.toContain("you may use multiple tools in a single message")
expect(guidelines).not.toContain("Formulate your tool use using")
expect(guidelines).toContain("ALWAYS wait for user confirmation")
})
it("should include simplified iterative process guidelines", () => {
const guidelines = getToolUseGuidelinesSection()
expect(guidelines).toContain("carefully considering the user's response after each tool use")
expect(guidelines).toContain("It is crucial to proceed step-by-step")
})
expect(guidelines).toContain("1. Assess what information")
expect(guidelines).toContain("2. Choose the most appropriate tool")
expect(guidelines).toContain("3. If multiple actions are needed")
})
describe("with MULTIPLE_NATIVE_TOOL_CALLS enabled", () => {
it("should include multiple-tools-per-message guidance when experiment enabled", () => {
const guidelines = getToolUseGuidelinesSection({
[EXPERIMENT_IDS.MULTIPLE_NATIVE_TOOL_CALLS]: true,
})
it("should include multiple-tools-per-message guidance", () => {
const guidelines = getToolUseGuidelinesSection()
expect(guidelines).toContain("you may use multiple tools in a single message")
expect(guidelines).not.toContain("use one tool at a time per message")
expect(guidelines).not.toContain("After each tool use, the user will respond")
})
expect(guidelines).toContain("you may use multiple tools in a single message")
expect(guidelines).not.toContain("use one tool at a time per message")
})
it("should use simplified footer without step-by-step language", () => {
const guidelines = getToolUseGuidelinesSection({
[EXPERIMENT_IDS.MULTIPLE_NATIVE_TOOL_CALLS]: true,
})
it("should use simplified footer without step-by-step language", () => {
const guidelines = getToolUseGuidelinesSection()
// When multiple tools per message is enabled, we don't want the
// "step-by-step" or "after each tool use" language that would
// contradict the ability to batch tool calls.
expect(guidelines).toContain("carefully considering the user's response after tool executions")
expect(guidelines).not.toContain("It is crucial to proceed step-by-step")
expect(guidelines).not.toContain("ALWAYS wait for user confirmation after each tool use")
})
expect(guidelines).toContain("carefully considering the user's response after tool executions")
expect(guidelines).not.toContain("It is crucial to proceed step-by-step")
expect(guidelines).not.toContain("ALWAYS wait for user confirmation after each tool use")
})
it("should include common guidance", () => {
const guidelines = getToolUseGuidelinesSection()
expect(guidelines).toContain("Assess what information you already have")
expect(guidelines).toContain("Choose the most appropriate tool")
expect(guidelines).toContain("After each tool use, the user will respond")
// No legacy XML-tag tool-calling remnants
expect(guidelines).not.toContain("<actual_tool_name>")
})
it("should not include per-tool confirmation guidelines", () => {
const guidelines = getToolUseGuidelinesSection()
expect(guidelines).not.toContain("After each tool use, the user will respond with the result")
})
})

View file

@ -1,52 +1,31 @@
import { getSharedToolUseSection } from "../tool-use"
describe("getSharedToolUseSection", () => {
describe("with MULTIPLE_NATIVE_TOOL_CALLS disabled (default)", () => {
it("should include one tool per message requirement when experiment is disabled (default)", () => {
// No experiment flags passed (default: disabled)
const section = getSharedToolUseSection()
it("should include native tool-calling instructions", () => {
const section = getSharedToolUseSection()
expect(section).toContain("You must use exactly one tool call per assistant response")
expect(section).toContain("Do not call zero tools or more than one tool")
})
it("should include one tool per message requirement when experiment is explicitly disabled", () => {
const section = getSharedToolUseSection({ multipleNativeToolCalls: false })
expect(section).toContain("You must use exactly one tool call per assistant response")
expect(section).toContain("Do not call zero tools or more than one tool")
})
it("should NOT include one tool per message requirement when experiment is enabled", () => {
const section = getSharedToolUseSection({ multipleNativeToolCalls: true })
expect(section).not.toContain("You must use exactly one tool per message")
expect(section).not.toContain("every assistant message must include a tool call")
expect(section).toContain("You must call at least one tool per assistant response")
expect(section).toContain("Prefer calling as many tools as are reasonably needed")
})
it("should include native tool-calling instructions", () => {
const section = getSharedToolUseSection()
expect(section).toContain("provider-native tool-calling mechanism")
expect(section).toContain("Do not include XML markup or examples")
})
it("should NOT include XML formatting instructions", () => {
const section = getSharedToolUseSection()
expect(section).not.toContain("<actual_tool_name>")
expect(section).not.toContain("</actual_tool_name>")
})
expect(section).toContain("provider-native tool-calling mechanism")
expect(section).toContain("Do not include XML markup or examples")
})
describe("default (native-only)", () => {
it("should default to native tool calling when no arguments are provided", () => {
const section = getSharedToolUseSection()
expect(section).toContain("provider-native tool-calling mechanism")
// No legacy XML-tag tool-calling remnants
expect(section).not.toContain("<actual_tool_name>")
})
it("should include multiple tools per message guidance", () => {
const section = getSharedToolUseSection()
expect(section).toContain("You must call at least one tool per assistant response")
expect(section).toContain("Prefer calling as many tools as are reasonably needed")
})
it("should NOT include single tool per message restriction", () => {
const section = getSharedToolUseSection()
expect(section).not.toContain("You must use exactly one tool call per assistant response")
expect(section).not.toContain("Do not call zero tools or more than one tool")
})
it("should NOT include XML formatting instructions", () => {
const section = getSharedToolUseSection()
expect(section).not.toContain("<actual_tool_name>")
expect(section).not.toContain("</actual_tool_name>")
})
})

View file

@ -1,66 +1,9 @@
import { experiments, EXPERIMENT_IDS } from "../../../shared/experiments"
export function getToolUseGuidelinesSection(experimentFlags?: Record<string, boolean>): string {
// Build guidelines array with automatic numbering
let itemNumber = 1
const guidelinesList: string[] = []
// First guideline is always the same
guidelinesList.push(
`${itemNumber++}. Assess what information you already have and what information you need to proceed with the task.`,
)
guidelinesList.push(
`${itemNumber++}. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like \`ls\` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.`,
)
// Native-only guidelines.
// Check if multiple native tool calls is enabled via experiment.
const isMultipleNativeToolCallsEnabled = experiments.isEnabled(
experimentFlags ?? {},
EXPERIMENT_IDS.MULTIPLE_NATIVE_TOOL_CALLS,
)
if (isMultipleNativeToolCallsEnabled) {
guidelinesList.push(
`${itemNumber++}. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.`,
)
} else {
guidelinesList.push(
`${itemNumber++}. If multiple actions are needed, use one tool at a time per message to accomplish the task iteratively, with each tool use being informed by the result of the previous tool use. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.`,
)
}
// Only add the per-tool confirmation guideline when NOT using multiple tool calls.
// When multiple tool calls are enabled, results may arrive batched (after all tools),
// so "after each tool use" would contradict the batching behavior.
if (!isMultipleNativeToolCallsEnabled) {
guidelinesList.push(`${itemNumber++}. After each tool use, the user will respond with the result of that tool use. This result will provide you with the necessary information to continue your task or make further decisions. This response may include:
- Information about whether the tool succeeded or failed, along with any reasons for failure.
- Linter errors that may have arisen due to the changes you made, which you'll need to address.
- New terminal output in reaction to the changes, which you may need to consider or act upon.
- Any other relevant feedback or information related to the tool use.`)
}
// Only add the "wait for confirmation" guideline when NOT using multiple tool calls.
// With multiple tool calls enabled, the model is expected to batch tools and get results together.
if (!isMultipleNativeToolCallsEnabled) {
guidelinesList.push(
`${itemNumber++}. ALWAYS wait for user confirmation after each tool use before proceeding. Never assume the success of a tool use without explicit confirmation of the result from the user.`,
)
}
// Join guidelines and add the footer
const footer = isMultipleNativeToolCallsEnabled
? `\n\nBy carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.`
: `\n\nIt is crucial to proceed step-by-step, waiting for the user's message after each tool use before moving forward with the task. This approach allows you to:
1. Confirm the success of each step before proceeding.
2. Address any issues or errors that arise immediately.
3. Adapt your approach based on new information or unexpected results.
4. Ensure that each action builds correctly on the previous ones.
By waiting for and carefully considering the user's response after each tool use, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.`
export function getToolUseGuidelinesSection(): string {
return `# Tool Use Guidelines
${guidelinesList.join("\n")}${footer}`
1. Assess what information you already have and what information you need to proceed with the task.
2. Choose the most appropriate tool based on the task and the tool descriptions provided. Assess if you need additional information to proceed, and which of the available tools would be most effective for gathering this information. For example using the list_files tool is more effective than running a command like \`ls\` in the terminal. It's critical that you think about each available tool and use the one that best fits the current step in the task.
3. If multiple actions are needed, you may use multiple tools in a single message when appropriate, or use tools iteratively across messages. Each tool use should be informed by the results of previous tool uses. Do not assume the outcome of any tool use. Each step must be informed by the previous step's result.
By carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.`
}

View file

@ -1,19 +1,7 @@
import { experiments, EXPERIMENT_IDS } from "../../../shared/experiments"
export function getSharedToolUseSection(experimentFlags?: Record<string, boolean>): string {
// Check if multiple native tool calls is enabled via experiment
const isMultipleNativeToolCallsEnabled = experiments.isEnabled(
experimentFlags ?? {},
EXPERIMENT_IDS.MULTIPLE_NATIVE_TOOL_CALLS,
)
const toolUseGuidance = isMultipleNativeToolCallsEnabled
? " You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster."
: " You must use exactly one tool call per assistant response. Do not call zero tools or more than one tool in the same response."
export function getSharedToolUseSection(): string {
return `====
TOOL USE
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples.${toolUseGuidance}`
You have access to a set of tools that are executed upon the user's approval. Use the provider-native tool-calling mechanism. Do not include XML markup or examples. You must call at least one tool per assistant response. Prefer calling as many tools as are reasonably needed in a single response to reduce back-and-forth and complete tasks faster.`
}

View file

@ -92,9 +92,9 @@ async function generatePrompt(
${markdownFormattingSection()}
${getSharedToolUseSection(experiments)}${toolsCatalog}
${getSharedToolUseSection()}${toolsCatalog}
${getToolUseGuidelinesSection(experiments)}
${getToolUseGuidelinesSection()}
${getCapabilitiesSection(cwd, shouldIncludeMcp ? mcpHub : undefined)}

View file

@ -147,14 +147,14 @@ describe("converters", () => {
})
describe("convertOpenAIToolChoiceToAnthropic", () => {
it("should return auto with disabled parallel tool use when toolChoice is undefined", () => {
it("should return auto with enabled parallel tool use by default when toolChoice is undefined", () => {
const result = convertOpenAIToolChoiceToAnthropic(undefined)
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: true })
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: false })
})
it("should return auto with enabled parallel tool use when parallelToolCalls is true", () => {
const result = convertOpenAIToolChoiceToAnthropic(undefined, true)
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: false })
it("should return auto with disabled parallel tool use when parallelToolCalls is false", () => {
const result = convertOpenAIToolChoiceToAnthropic(undefined, false)
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: true })
})
it("should return undefined for 'none' tool choice", () => {
@ -164,17 +164,17 @@ describe("converters", () => {
it("should return auto for 'auto' tool choice", () => {
const result = convertOpenAIToolChoiceToAnthropic("auto")
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: true })
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: false })
})
it("should return any for 'required' tool choice", () => {
const result = convertOpenAIToolChoiceToAnthropic("required")
expect(result).toEqual({ type: "any", disable_parallel_tool_use: true })
expect(result).toEqual({ type: "any", disable_parallel_tool_use: false })
})
it("should return auto for unknown string tool choice", () => {
const result = convertOpenAIToolChoiceToAnthropic("unknown" as any)
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: true })
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: false })
})
it("should convert function object form to tool type", () => {
@ -185,28 +185,28 @@ describe("converters", () => {
expect(result).toEqual({
type: "tool",
name: "get_weather",
disable_parallel_tool_use: true,
disable_parallel_tool_use: false,
})
})
it("should handle function object form with parallel tool calls enabled", () => {
it("should handle function object form with parallel tool calls disabled", () => {
const result = convertOpenAIToolChoiceToAnthropic(
{
type: "function",
function: { name: "read_file" },
},
true,
false,
)
expect(result).toEqual({
type: "tool",
name: "read_file",
disable_parallel_tool_use: false,
disable_parallel_tool_use: true,
})
})
it("should return auto for object without function property", () => {
const result = convertOpenAIToolChoiceToAnthropic({ type: "something" } as any)
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: true })
expect(result).toEqual({ type: "auto", disable_parallel_tool_use: false })
})
})
})

View file

@ -58,7 +58,7 @@ export function convertOpenAIToolsToAnthropic(tools: OpenAI.Chat.ChatCompletionT
* - { type: "function", function: { name } } { type: "tool", name }
*
* @param toolChoice - OpenAI tool_choice parameter
* @param parallelToolCalls - When true, allows parallel tool calls. When false (default), disables parallel tool calls.
* @param parallelToolCalls - When true (default), allows parallel tool calls. When false, disables parallel tool calls.
* @returns Anthropic ToolChoice or undefined if tools should be omitted
*
* @example
@ -67,16 +67,16 @@ export function convertOpenAIToolsToAnthropic(tools: OpenAI.Chat.ChatCompletionT
* // Returns: { type: "auto", disable_parallel_tool_use: true }
*
* convertOpenAIToolChoiceToAnthropic({ type: "function", function: { name: "get_weather" } })
* // Returns: { type: "tool", name: "get_weather", disable_parallel_tool_use: true }
* // Returns: { type: "tool", name: "get_weather", disable_parallel_tool_use: false }
* ```
*/
export function convertOpenAIToolChoiceToAnthropic(
toolChoice: OpenAI.Chat.ChatCompletionCreateParams["tool_choice"],
parallelToolCalls?: boolean,
): Anthropic.Messages.MessageCreateParams["tool_choice"] | undefined {
// Anthropic allows parallel tool calls by default. When parallelToolCalls is false or undefined,
// Parallel tool calls are enabled by default. When parallelToolCalls is explicitly false,
// we disable parallel tool use to ensure one tool call at a time.
const disableParallelToolUse = !parallelToolCalls
const disableParallelToolUse = parallelToolCalls === false
if (!toolChoice) {
// Default to auto with parallel tool use control

View file

@ -1671,7 +1671,7 @@ export class Task extends EventEmitter<TaskEvents> implements TaskLike {
? {
tools: allTools,
tool_choice: "auto",
parallelToolCalls: false,
parallelToolCalls: true,
}
: {}),
}
@ -3882,7 +3882,7 @@ export class Task extends EventEmitter<TaskEvents> implements TaskLike {
? {
tools: allTools,
tool_choice: "auto",
parallelToolCalls: false,
parallelToolCalls: true,
}
: {}),
}
@ -4099,7 +4099,7 @@ export class Task extends EventEmitter<TaskEvents> implements TaskLike {
? {
tools: contextMgmtTools,
tool_choice: "auto",
parallelToolCalls: false,
parallelToolCalls: true,
}
: {}),
}
@ -4259,8 +4259,6 @@ export class Task extends EventEmitter<TaskEvents> implements TaskLike {
const shouldIncludeTools = allTools.length > 0
const parallelToolCallsEnabled = state?.experiments?.multipleNativeToolCalls ?? false
const metadata: ApiHandlerCreateMessageMetadata = {
mode: mode,
taskId: this.taskId,
@ -4270,7 +4268,7 @@ export class Task extends EventEmitter<TaskEvents> implements TaskLike {
? {
tools: allTools,
tool_choice: "auto",
parallelToolCalls: parallelToolCallsEnabled,
parallelToolCalls: true,
// When mode restricts tools, provide allowedFunctionNames so providers
// like Gemini can see all tools in history but only call allowed ones
...(allowedFunctionNames ? { allowedFunctionNames } : {}),

View file

@ -20,7 +20,6 @@ describe("experiments", () => {
preventFocusDisruption: false,
imageGeneration: false,
runSlashCommand: false,
multipleNativeToolCalls: false,
customTools: false,
}
expect(Experiments.isEnabled(experiments, EXPERIMENT_IDS.PREVENT_FOCUS_DISRUPTION)).toBe(false)
@ -31,7 +30,6 @@ describe("experiments", () => {
preventFocusDisruption: true,
imageGeneration: false,
runSlashCommand: false,
multipleNativeToolCalls: false,
customTools: false,
}
expect(Experiments.isEnabled(experiments, EXPERIMENT_IDS.PREVENT_FOCUS_DISRUPTION)).toBe(true)
@ -42,7 +40,6 @@ describe("experiments", () => {
preventFocusDisruption: false,
imageGeneration: false,
runSlashCommand: false,
multipleNativeToolCalls: false,
customTools: false,
}
expect(Experiments.isEnabled(experiments, EXPERIMENT_IDS.PREVENT_FOCUS_DISRUPTION)).toBe(false)

View file

@ -4,7 +4,6 @@ export const EXPERIMENT_IDS = {
PREVENT_FOCUS_DISRUPTION: "preventFocusDisruption",
IMAGE_GENERATION: "imageGeneration",
RUN_SLASH_COMMAND: "runSlashCommand",
MULTIPLE_NATIVE_TOOL_CALLS: "multipleNativeToolCalls",
CUSTOM_TOOLS: "customTools",
} as const satisfies Record<string, ExperimentId>
@ -20,7 +19,6 @@ export const experimentConfigsMap: Record<ExperimentKey, ExperimentConfig> = {
PREVENT_FOCUS_DISRUPTION: { enabled: false },
IMAGE_GENERATION: { enabled: false },
RUN_SLASH_COMMAND: { enabled: false },
MULTIPLE_NATIVE_TOOL_CALLS: { enabled: false },
CUSTOM_TOOLS: { enabled: false },
}

View file

@ -236,7 +236,6 @@ describe("mergeExtensionState", () => {
preventFocusDisruption: false,
imageGeneration: false,
runSlashCommand: false,
multipleNativeToolCalls: false,
customTools: false,
} as Record<ExperimentId, boolean>,
checkpointTimeout: DEFAULT_CHECKPOINT_TIMEOUT_SECONDS + 5,
@ -253,7 +252,6 @@ describe("mergeExtensionState", () => {
preventFocusDisruption: false,
imageGeneration: false,
runSlashCommand: false,
multipleNativeToolCalls: false,
customTools: false,
})
})

View file

@ -847,10 +847,6 @@
"name": "Habilitar comandes de barra diagonal iniciades pel model",
"description": "Quan està habilitat, Roo pot executar les vostres comandes de barra diagonal per executar fluxos de treball."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Crides paral·leles a eines",
"description": "Quan està activat, el protocol natiu pot executar múltiples eines en un sol torn de missatge de l'assistent."
},
"CUSTOM_TOOLS": {
"name": "Habilitar eines personalitzades",
"description": "Quan està habilitat, Roo pot carregar i utilitzar eines TypeScript/JavaScript personalitzades des del directori .roo/tools del vostre projecte o ~/.roo/tools per a eines globals. Nota: aquestes eines s'aprovaran automàticament.",

View file

@ -847,10 +847,6 @@
"name": "Modellinitierte Slash-Befehle aktivieren",
"description": "Wenn aktiviert, kann Roo deine Slash-Befehle ausführen, um Workflows zu starten."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Parallele Tool-Aufrufe",
"description": "Wenn aktiviert, kann das native Protokoll mehrere Tools in einer einzigen Assistenten-Nachrichtenrunde ausführen."
},
"CUSTOM_TOOLS": {
"name": "Benutzerdefinierte Tools aktivieren",
"description": "Wenn aktiviert, kann Roo benutzerdefinierte TypeScript/JavaScript-Tools aus dem .roo/tools-Verzeichnis deines Projekts oder ~/.roo/tools für globale Tools laden und verwenden. Hinweis: Diese Tools werden automatisch genehmigt.",

View file

@ -901,10 +901,6 @@
"name": "Enable model-initiated slash commands",
"description": "When enabled, Roo can run your slash commands to execute workflows."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Parallel tool calls",
"description": "When enabled, the native protocol can execute multiple tools in a single assistant message turn."
},
"CUSTOM_TOOLS": {
"name": "Enable custom tools",
"description": "When enabled, Roo can load and use custom TypeScript/JavaScript tools from your project's .roo/tools directory or ~/.roo/tools for global tools. Note: these tools will automatically be auto-approved.",

View file

@ -847,10 +847,6 @@
"name": "Habilitar comandos slash iniciados por el modelo",
"description": "Cuando está habilitado, Roo puede ejecutar tus comandos slash para ejecutar flujos de trabajo."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Llamadas paralelas a herramientas",
"description": "Cuando está habilitado, el protocolo nativo puede ejecutar múltiples herramientas en un solo turno de mensaje del asistente."
},
"CUSTOM_TOOLS": {
"name": "Habilitar herramientas personalizadas",
"description": "Cuando está habilitado, Roo puede cargar y usar herramientas TypeScript/JavaScript personalizadas desde el directorio .roo/tools de tu proyecto o ~/.roo/tools para herramientas globales. Nota: estas herramientas se aprobarán automáticamente.",

View file

@ -847,10 +847,6 @@
"name": "Activer les commandes slash initiées par le modèle",
"description": "Lorsque activé, Roo peut exécuter tes commandes slash pour lancer des workflows."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Appels d'outils parallèles",
"description": "Lorsqu'activé, le protocole natif peut exécuter plusieurs outils en un seul tour de message d'assistant."
},
"CUSTOM_TOOLS": {
"name": "Activer les outils personnalisés",
"description": "Lorsqu'activé, Roo peut charger et utiliser des outils TypeScript/JavaScript personnalisés à partir du répertoire .roo/tools de votre projet ou ~/.roo/tools pour des outils globaux. Remarque : ces outils seront automatiquement approuvés.",

View file

@ -848,10 +848,6 @@
"name": "मॉडल द्वारा शुरू किए गए स्लैश कमांड सक्षम करें",
"description": "जब सक्षम होता है, Roo वर्कफ़्लो चलाने के लिए आपके स्लैश कमांड चला सकता है।"
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "समानांतर टूल कॉल",
"description": "सक्षम होने पर, नेटिव प्रोटोकॉल एकल सहायक संदेश टर्न में एकाधिक टूल निष्पादित कर सकता है।"
},
"CUSTOM_TOOLS": {
"name": "कस्टम टूल्स सक्षम करें",
"description": "सक्षम होने पर, Roo आपके प्रोजेक्ट की .roo/tools निर्देशिका या वैश्विक टूल्स के लिए ~/.roo/tools से कस्टम TypeScript/JavaScript टूल्स लोड और उपयोग कर सकता है। नोट: ये टूल्स स्वचालित रूप से स्वत:-अनुमोदित होंगे।",

View file

@ -877,10 +877,6 @@
"name": "Aktifkan perintah slash yang dimulai model",
"description": "Ketika diaktifkan, Roo dapat menjalankan perintah slash Anda untuk mengeksekusi alur kerja."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Panggilan tool paralel",
"description": "Ketika diaktifkan, protokol native dapat mengeksekusi beberapa tool dalam satu giliran pesan asisten."
},
"CUSTOM_TOOLS": {
"name": "Aktifkan tool kustom",
"description": "Ketika diaktifkan, Roo dapat memuat dan menggunakan tool TypeScript/JavaScript kustom dari direktori .roo/tools proyek Anda atau ~/.roo/tools untuk tool global. Catatan: tool ini akan disetujui otomatis.",

View file

@ -848,10 +848,6 @@
"name": "Abilita comandi slash avviati dal modello",
"description": "Quando abilitato, Roo può eseguire i tuoi comandi slash per eseguire flussi di lavoro."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Chiamate parallele agli strumenti",
"description": "Quando abilitato, il protocollo nativo può eseguire più strumenti in un singolo turno di messaggio dell'assistente."
},
"CUSTOM_TOOLS": {
"name": "Abilita strumenti personalizzati",
"description": "Quando abilitato, Roo può caricare e utilizzare strumenti TypeScript/JavaScript personalizzati dalla directory .roo/tools del tuo progetto o ~/.roo/tools per strumenti globali. Nota: questi strumenti saranno automaticamente approvati.",

View file

@ -848,10 +848,6 @@
"name": "モデル開始スラッシュコマンドを有効にする",
"description": "有効にすると、Rooがワークフローを実行するためにあなたのスラッシュコマンドを実行できます。"
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "並列ツール呼び出し",
"description": "有効にすると、ネイティブプロトコルは単一のアシスタントメッセージターンで複数のツールを実行できます。"
},
"CUSTOM_TOOLS": {
"name": "カスタムツールを有効化",
"description": "有効にすると、Rooはプロジェクトの.roo/toolsディレクトリまたはグローバルツール用の~/.roo/toolsからカスタムTypeScript/JavaScriptツールを読み込んで使用できます。注意これらのツールは自動的に承認されます。",

View file

@ -848,10 +848,6 @@
"name": "모델 시작 슬래시 명령 활성화",
"description": "활성화되면 Roo가 워크플로를 실행하기 위해 슬래시 명령을 실행할 수 있습니다."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "병렬 도구 호출",
"description": "활성화되면 네이티브 프로토콜이 단일 어시스턴트 메시지 턴에서 여러 도구를 실행할 수 있습니다."
},
"CUSTOM_TOOLS": {
"name": "사용자 정의 도구 활성화",
"description": "활성화하면 Roo가 프로젝트의 .roo/tools 디렉터리 또는 전역 도구를 위한 ~/.roo/tools에서 사용자 정의 TypeScript/JavaScript 도구를 로드하고 사용할 수 있습니다. 참고: 이러한 도구는 자동으로 자동 승인됩니다.",

View file

@ -848,10 +848,6 @@
"name": "Model-geïnitieerde slash-commando's inschakelen",
"description": "Wanneer ingeschakeld, kan Roo je slash-commando's uitvoeren om workflows uit te voeren."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Parallelle tool-aanroepen",
"description": "Wanneer ingeschakeld, kan het native protocol meerdere tools uitvoeren in één enkele assistent-berichtbeurt."
},
"CUSTOM_TOOLS": {
"name": "Aangepaste tools inschakelen",
"description": "Indien ingeschakeld kan Roo aangepaste TypeScript/JavaScript-tools laden en gebruiken uit de map .roo/tools van je project of ~/.roo/tools voor globale tools. Opmerking: deze tools worden automatisch goedgekeurd.",

View file

@ -848,10 +848,6 @@
"name": "Włącz polecenia slash inicjowane przez model",
"description": "Gdy włączone, Roo może uruchamiać twoje polecenia slash w celu wykonywania przepływów pracy."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Równoległe wywołania narzędzi",
"description": "Po włączeniu protokół natywny może wykonywać wiele narzędzi w jednej turze wiadomości asystenta."
},
"CUSTOM_TOOLS": {
"name": "Włącz niestandardowe narzędzia",
"description": "Gdy włączone, Roo może ładować i używać niestandardowych narzędzi TypeScript/JavaScript z katalogu .roo/tools Twojego projektu lub ~/.roo/tools dla narzędzi globalnych. Uwaga: te narzędzia będą automatycznie zatwierdzane.",

View file

@ -848,10 +848,6 @@
"name": "Ativar comandos slash iniciados pelo modelo",
"description": "Quando ativado, Roo pode executar seus comandos slash para executar fluxos de trabalho."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Chamadas paralelas de ferramentas",
"description": "Quando habilitado, o protocolo nativo pode executar múltiplas ferramentas em um único turno de mensagem do assistente."
},
"CUSTOM_TOOLS": {
"name": "Ativar ferramentas personalizadas",
"description": "Quando habilitado, o Roo pode carregar e usar ferramentas TypeScript/JavaScript personalizadas do diretório .roo/tools do seu projeto ou ~/.roo/tools para ferramentas globais. Nota: estas ferramentas serão aprovadas automaticamente.",

View file

@ -848,10 +848,6 @@
"name": "Включить слэш-команды, инициированные моделью",
"description": "Когда включено, Roo может выполнять ваши слэш-команды для выполнения рабочих процессов."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Параллельные вызовы инструментов",
"description": "При включении нативный протокол может выполнять несколько инструментов в одном ходе сообщения ассистента."
},
"CUSTOM_TOOLS": {
"name": "Включить пользовательские инструменты",
"description": "Если включено, Roo сможет загружать и использовать пользовательские инструменты TypeScript/JavaScript из каталога .roo/tools вашего проекта или ~/.roo/tools для глобальных инструментов. Примечание: эти инструменты будут одобрены автоматически.",

View file

@ -848,10 +848,6 @@
"name": "Model tarafından başlatılan slash komutlarını etkinleştir",
"description": "Etkinleştirildiğinde, Roo iş akışlarını yürütmek için slash komutlarınızı çalıştırabilir."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Paralel araç çağrıları",
"description": "Etkinleştirildiğinde, yerel protokol tek bir asistan mesaj turunda birden fazla araç yürütebilir."
},
"CUSTOM_TOOLS": {
"name": "Özel araçları etkinleştir",
"description": "Etkinleştirildiğinde, Roo projenizin .roo/tools dizininden veya global araçlar için ~/.roo/tools dizininden özel TypeScript/JavaScript araçlarını yükleyebilir ve kullanabilir. Not: Bu araçlar otomatik olarak onaylanacaktır.",

View file

@ -848,10 +848,6 @@
"name": "Bật lệnh slash do mô hình khởi tạo",
"description": "Khi được bật, Roo có thể chạy các lệnh slash của bạn để thực hiện các quy trình làm việc."
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "Lệnh gọi công cụ song song",
"description": "Khi được bật, giao thức native có thể thực thi nhiều công cụ trong một lượt tin nhắn của trợ lý."
},
"CUSTOM_TOOLS": {
"name": "Bật công cụ tùy chỉnh",
"description": "Khi được bật, Roo có thể tải và sử dụng các công cụ TypeScript/JavaScript tùy chỉnh từ thư mục .roo/tools của dự án hoặc ~/.roo/tools cho các công cụ toàn cục. Lưu ý: các công cụ này sẽ được tự động phê duyệt.",

View file

@ -848,10 +848,6 @@
"name": "启用模型发起的斜杠命令",
"description": "启用后 Roo 可运行斜杠命令执行工作流程。"
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "并行工具调用",
"description": "启用后,原生协议可在单个助手消息轮次中执行多个工具。"
},
"CUSTOM_TOOLS": {
"name": "启用自定义工具",
"description": "启用后 Roo 可从项目中的 .roo/tools 目录或全局工具目录 ~/.roo/tools 加载并使用自定义 TypeScript/JavaScript 工具。注意:这些工具将自动获批。",

View file

@ -856,10 +856,6 @@
"name": "啟用模型啟動的斜線命令",
"description": "啟用時Roo 可以執行您的斜線命令來執行工作流程。"
},
"MULTIPLE_NATIVE_TOOL_CALLS": {
"name": "並行工具呼叫",
"description": "啟用後,原生協定可在單個助理訊息輪次中執行多個工具。"
},
"CUSTOM_TOOLS": {
"name": "啟用自訂工具",
"description": "啟用後Roo 可以從專案中的 .roo/tools 目錄或全域工具目錄 ~/.roo/tools 載入並使用自訂 TypeScript/JavaScript 工具。注意:這些工具將自動獲得核准。",