Repository navigation
Conversation
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
76d1c98 to
3d0cbb4
Compare
91b0686 to
16f628f
Compare
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Related to #28472
Type of change
What does this PR do?
Some setups hand MCP servers an object or array argument as a JSON string, which the server then rejects with
expected object, received string. When the advertised schema says a field is an object or array, this PR parses that JSON string back into a structured value before callingclient.callTool. Empty strings become{}/[]; invalid JSON is left untouched so the server still returns its own error. It is a no-op when the argument is already structured.How did you verify your code works?
bun test test/mcp/catalog.test.tsandbun run typecheckfrompackages/opencode;bun run lintfrom the repo root (0 errors).send-mailbody). With current models the argument always arrives as a proper object and the unfixed path already accepts it. When a JSON string is forced, the unfixed path returns the exact-32602 ... expected object, received stringand this change accepts it.Scope and limitations
This is a tolerance shim. It only does anything when an upstream component (an older model, a proxy, or a re-serializing SDK) emits a JSON string for an object/array field; otherwise it is a no-op. I could not reproduce the original failure with current models in clean OpenCode, so this is defensive rather than a guaranteed fix for a specific server. Note that next-devtools'
nextjs_calladvertisesargsastype: "string", so this change does not affect it. Schema detection is intentionally minimal:anyOf/oneOf/$refandstring | objectunions are not handled. Happy to extend, or to drop this if you'd rather not carry it.Screenshots / recordings
Not a UI change.
Checklist