fix(agent): correlate Responses tool arguments by item ID by Elioooon · Pull Request #2556 · mcp-use/mcp-use · GitHub
Skip to content

fix(agent): correlate Responses tool arguments by item ID - #2556

Closed
Elioooon wants to merge 5 commits into
mcp-use:mainfrom
Elioooon:fix/openai-responses-stream-item-id
Closed

Elioooon wants to merge 5 commits into
mcp-use:mainfrom
Elioooon:fix/openai-responses-stream-item-id

Conversation

@Elioooon

@Elioooon Elioooon commented Sep 16, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Fixes #2550. OpenAI Responses streaming identifies response.function_call_arguments.delta and .done events with item_id, while the created function-call item carries the downstream call_id. Buffering by call_id therefore discarded valid argument events and caused MCPAgent.stream() to emit no tool-call steps.

The parser now buffers events by item_id (with call_id as a compatibility fallback), retains the function item\u0027s call_id for the ready payload and subsequent tool output, and rejects ambiguous/missing correlations instead of silently attaching data to a different call.

Design and boundaries

  • item_id is the primary correlation key because it is the Responses event contract; call_id remains accepted for compatibility producers.
  • The public tool-call payload still uses call_id, so driver/executor call sites keep their existing identity contract.
  • This changes only streamed function-call argument correlation. It does not alter non-streaming response parsing or provider request formatting.

Validation

  • pnpm exec vitest run src/llm/__tests__/openai-responses.test.ts — 9 passed
  • pnpm run build — tsup build and declaration generation passed
  • git diff --check origin/main...HEAD

The local Node is 22.16.0 while the workspace declares >=22.22.2; the focused tests and build completed despite that version warning. CI remains the full matrix.


Summary by cubic

Fixes OpenAI Responses streaming so tool argument events are correlated by item_id, restoring tool-call steps that MCPAgent.stream() previously dropped.

The parser now keys buffers by item_id, accepts call_id only when it uniquely identifies one output item, and drops unknown or ambiguous correlations instead of attaching data to the wrong call. The public tool-call payload still uses call_id, so driver/executor call sites keep their existing identity contract.

Bug Fixes

  • Correlates streamed function-call argument events by item_id, with call_id accepted only for unambiguous compatibility producers.
  • Preserves call_id in the public tool-call payload so driver/executor call sites keep their existing identity contract.

Written for commit ea58ab9. Summary will update on new commits.

Review in cubic

@pkg-pr-new

pkg-pr-new Bot commented Sep 16, 2026 •

Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

All reported issues were addressed across 3 files

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

Comment thread libraries/typescript/packages/agent/src/llm/providers/openai-responses.ts Outdated

@MohammedAlkindi MohammedAlkindi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The findCallBuffer ambiguity guard is the right call. Returning undefined when a compatibility call_id matches two buffers drops the event instead of attaching arguments to the wrong call, and the third test pins exactly that case.

All three new tests should fail tsc. ResponsesTurnParams declares input: unknown[] as required and has no messages member, and each new case calls streamResponsesTurn({ config, messages: [], tools: [] }). Vitest strips types rather than checking them, so they pass at runtime because fetch is mocked and the missing input just serializes as undefined. I raised this on #2553 and re-checked it against openai-responses.ts on main today rather than assuming it carried over. Swapping messages for input in all three cases fixes it.

#2551 is still open and fixes the same bug by keying on item_id without the call_id fallback. That leaves three PRs for one event-correlation bug, differing only on whether the old call_id lookup survives. Picking one looks more useful than reviewing all three diffs in parallel.


Generated by Claude Code

@Elioooon

Copy link
Copy Markdown
Contributor Author

@Elioooon Elioooon closed this Sep 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

2 participants