Skip to content

feat: forced result tool #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jun 2, 2025
Merged

feat: forced result tool #7

merged 7 commits into from
Jun 2, 2025

Conversation

evacchi
Copy link
Contributor

@evacchi evacchi commented May 27, 2025

allow passing an optional config to next(). The allowed keys are the anthropic config keys, plus:

  • tools: Tool[] (an MCP tool def)
  • tool_choice?: string, if present, the name of exactly one tool in the tool list (either the one provided, or the one returned by the session)

@evacchi evacchi closed this May 28, 2025
@evacchi evacchi force-pushed the task-output-tool branch from 5d7b43f to 630e426 Compare May 28, 2025 13:59
evacchi added 7 commits May 28, 2025 16:01
Signed-off-by: Edoardo Vacchi <[email protected]>
Signed-off-by: Edoardo Vacchi <[email protected]>
Signed-off-by: Edoardo Vacchi <[email protected]>
Signed-off-by: Edoardo Vacchi <[email protected]>
Signed-off-by: Edoardo Vacchi <[email protected]>
Signed-off-by: Edoardo Vacchi <[email protected]>
Signed-off-by: Edoardo Vacchi <[email protected]>
@evacchi evacchi reopened this May 29, 2025
Copy link
Contributor

@chrisdickinson chrisdickinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if I follow correctly I think we might be able to reduce this down to a check for config.tools (step 4️⃣)?

const content = newMessage.content as ContentBlockParam[]
content.push(await this.call(submessage))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1️⃣ If I follow correctly, we moved the normalization of the tool call info from here...

submessageIdx: nextSubmessage,
toolCallId: submessage.id
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2️⃣ ...to here

const { tool, submessageIdx, toolCallIndex, toolCallLength, toolCallId } =
this.parseNextToolCall(stage)

content.push(await this.call(tool, toolCallId!))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3️⃣ so we can pass it directly here. But I don't see any other changes to the logic?

@@ -169,11 +172,16 @@ export class Driver {
const { response, messages, index, status, toolCallIndex } = stage
switch (status) {
case 'pending': {
const tools = config.tools?.map(mcpxToolToAnthropic) || this.#tools
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4️⃣ this would be the load-bearing change, right? (Assuming users could already pass tool_choice as a part of config?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's right. I don't love the fact that we are abusing the anthropic-specific config to pass a foreign config key. We could expose a separate "mcpToolConfig" object for this specific purpose though

@@ -38,6 +38,16 @@ export interface McpxAnthropicStage {
}


function anthropicToolCallToMcpxToolCall(submessage: any): any {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oooh, I see – this is a normalization pass to unify the return type with mcpx-openai.

Copy link
Contributor Author

@evacchi evacchi May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, technically to align it to the MCP CallToolRequest definition

@evacchi
Copy link
Contributor Author

evacchi commented May 30, 2025

if I follow correctly I think we might be able to reduce this down to a check for config.tools (step 4️⃣)?

it depends if we want to keep the tool conversion logic isolated here, or we want to duplicate it into mcp.run/api

@evacchi evacchi marked this pull request as ready for review June 2, 2025 14:35
@evacchi evacchi requested a review from chrisdickinson June 2, 2025 14:35
Copy link
Contributor

@chrisdickinson chrisdickinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to lean towards duplicating the tool call conversion logic; it’s not too heavyweight. But I think we can address that later!

@evacchi evacchi merged commit eeb0df4 into main Jun 2, 2025
@evacchi evacchi deleted the task-output-tool branch June 2, 2025 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants