What's broken?
The spec doesn't cover a case it clearly should
Where in the spec or docs?
https://modelcontextprotocol.io/specification/draft/basic/transports
What should happen?
When using streamable HTTP transport there is no mechanism for getting error reports when the remote caller doesn't like the tool call response. This leads to having to change call responses until it is isolated, which is a hit/miss time sink. I wonder if there should be some way of getting error messages back to MCP server. At the moment the response is sent into the void. We could of course contact the AI vendor support , and if thats the solution, ok.
To give concrete example - Using claude desktop to connect to a remote streamable MCP server. All works fine except we noticed that some tool call responses would simply return "we received an error". Our MCP server clearly sent the RPC-reply, but something about our response broke Anthropics servers. In this case it was a Unicode character causing them to drop the response. My point isn't about that character, more that we, as developers, dont get any visibility to into this. What if responses are suddenly invalid because we use certain banned words.
- Our tool call works. (if we exclude a single Unicode character)
- The issue may well still be something we are doing, but my issue is around getting automated feedback
- the RPC request/response is complete from MCP servers viewpoint
- If the caller rejects the response overall, there is no feedback loop to the MCP server
I suspect any change will lead to AI vendors needing to make a change, so any "solution" needs to be easy to implement. My suggestion would be that we add a debug-reports URL as part of tools/initialize, AI vendors can implement or ignore. Or it could be an HTTP header, in similar vein to HTTPs Report-To
What actually happens?
ToolCall response is silently discarded
Anything else?
No response
What's broken?
The spec doesn't cover a case it clearly should
Where in the spec or docs?
https://modelcontextprotocol.io/specification/draft/basic/transports
What should happen?
When using streamable HTTP transport there is no mechanism for getting error reports when the remote caller doesn't like the tool call response. This leads to having to change call responses until it is isolated, which is a hit/miss time sink. I wonder if there should be some way of getting error messages back to MCP server. At the moment the response is sent into the void. We could of course contact the AI vendor support , and if thats the solution, ok.
To give concrete example - Using claude desktop to connect to a remote streamable MCP server. All works fine except we noticed that some tool call responses would simply return "we received an error". Our MCP server clearly sent the RPC-reply, but something about our response broke Anthropics servers. In this case it was a Unicode character causing them to drop the response. My point isn't about that character, more that we, as developers, dont get any visibility to into this. What if responses are suddenly invalid because we use certain banned words.
I suspect any change will lead to AI vendors needing to make a change, so any "solution" needs to be easy to implement. My suggestion would be that we add a debug-reports URL as part of tools/initialize, AI vendors can implement or ignore. Or it could be an HTTP header, in similar vein to HTTPs Report-To
What actually happens?
ToolCall response is silently discarded
Anything else?
No response