fix(core): accept fenced JSON in tool call arguments

[TokuiNico]

Summary

Accept Markdown-fenced JSON in tool call arguments when using with_structured_output. This aligns the structured-output path with the robustness already present in PydanticOutputParser, while keeping strictness for incomplete payloads.

Changes

• Use parse_json_markdown in parse_tool_call for the non-partial path (no partial fill).
• Keep strict json.loads under the hood; malformed/incomplete JSON still raises.
• Add unit tests covering:
  • Normal JSON
  • Fenced JSON
  • Incomplete JSON (expected to error)

Rationale

• Models may wrap JSON in json ... fences. PydanticOutputParser already tolerates this via parse_json_markdown; with_structured_output should behave similarly so users get consistent parsing across pathways.
• We deliberately avoid parse_partial_json here to prevent accidentally accepting truncated tool arguments.

Testing

• All core unit tests pass locally. The new tests specifically verify:
  • Normal JSON parses successfully
  • Fenced JSON parses successfully
  • Incomplete JSON raises OutputParserException

Backwards Compatibility

• No API changes. For already-valid JSON arguments, behavior is unchanged. This only increases robustness for fenced JSON content.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
langchain	Ignored	Preview		Sep 20, 2025 0:49am

[codspeed-hq]

CodSpeed WallTime Performance Report

Merging #33012 will not alter performance

_{Comparing TokuiNico:fix/core-tool-args-fenced-json (1332130) with master (90280d1)¹}

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

Summary

✅ 13 untouched

Footnotes

1. No successful run was found on master (f2b0afd) during the generation of this report, so 90280d1 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩