[BUG] Claude Code is submitting MCP requests as strings when using an SSE server
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
When connecting claude code the my MCP server via SSE, it submits the requests for endpoint that has a nested structure as stringified JSON.
2025-11-10T15:41:34.505916Z WARN rmcp::service: response error, id: 10, error: ErrorData { code: ErrorCode(-32602), message: "failed to deserialize parameters: invalid type: string \"{\\\"schedulePatternType\\\": {\\\"weekly\\\": {\\\"mon\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}, \\\"tues\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}, \\\"weds\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}, \\\"thurs\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}, \\\"fri\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}}}}\", expected struct SchedulePattern", data: None }
I notice this for other types as well... where sometimes a field is optional and it will pass in the string "null" (instead of the null value).
This issue does NOT happen on Claude Desktop for the same MCP server.
The issue does happen for stdio server as well, and for a workaround, we have a bridge that is intercepting the requests and converting them into proper JSON objects.
What Should Happen?
JSON RPC requests should be submitted as proper JSON objects
Error Messages/Logs
2025-11-10T15:41:34.505916Z WARN rmcp::service: response error, id: 10, error: ErrorData { code: ErrorCode(-32602), message: "failed to deserialize parameters: invalid type: string \"{\\\"schedulePatternType\\\": {\\\"weekly\\\": {\\\"mon\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}, \\\"tues\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}, \\\"weds\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}, \\\"thurs\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}, \\\"fri\\\": {\\\"shift\\\": {\\\"shiftType\\\": {\\\"regular\\\": {\\\"isRegular\\\": true}}, \\\"shiftTemplate\\\": {\\\"startTime\\\": {\\\"time\\\": \\\"09:00:00\\\"}, \\\"duration\\\": {\\\"seconds\\\": 28800}, \\\"breakTemplates\\\": []}}, \\\"venueId\\\": \\\"019a6e6c-db70-7308-bb4d-eaaad7e049c4\\\", \\\"roleId\\\": \\\"019a6e6c-dbd3-7c61-b32e-df0bc823d243\\\"}}}}\", expected struct SchedulePattern", data: None }
Steps to Reproduce
Have an MCP endpoint that has a nested endpoint and ask claude code to use the specified tool
Claude Model
Not sure / Multiple models
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.0.36
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
12 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Thanks for the feedback! Are you able to share an example MCP server that has this property? Or describe the shape of the tool a little more?
Keen to be able to reproduce this so we can fix it :)
I should be able to create an MRE and get it over here shortly
I accidentally closed the issue when trying to comment :(
sorry about that - looks like I don't have permission to re-open it.
Here is an MRE for the issue with a README that describes how to reproduce it:
https://github.com/rconnol/claude-code-11359-mre
Thanks again for the MRE and your patience here. After more investigation I think this is a bug with the fine-grained tool streaming beta.
If you start Claude Code with:
CLAUDE_CODE_DISABLE_FINE_GRAINED_TOOL_STREAMING=true claudethis _should_ fix things as a temporary solution. I will also be escalating with the relevant teams at Anthropic to make sure this gets fixed properly, and we may disable this beta for Claude Code until this is fixed.Okay - that does fix the issue with nested structs, but there are still two very prevalent issues that it doesn't fix. I pushed an example of these issues to the original MRE that you can test out.
It still tries to stringify the input when you use a OneOf or enum as the input.
And frequently it will try to pass the string "null" instead of the value null when there is an optional argument. This one is less deterministic and will sometimes fix itself by removing the argument or in this case it does something ill advised to "fix" the issue.
Thanks, continuing to investigate.
I can repro the issue with echo_one_of. echo and echo_optional seem to consistently work fine for me with fine-grained tool streaming disabled.
I've raised https://github.com/rconnol/claude-code-11359-mre/pull/1 to use stateless streamable http, as this makes things a lot easier to debug (e.g. can hit the server with curl)
@ollie-anthropic might you be able to look into why
echo_one_ofdoesn't work as expected?As another example of this issue, the DevRev MCP server's "update tags" tool has been broken for weeks because of this issue. They report that there's nothing they can do to work around it on their end, they need this underlying bug to be fixed.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.