So I wanted to test the mcp server I am writing and found mcp-probe. Tested it with my mcp server, not working … tested it against a different mcp server, working. Great so the Issue is on my end I thought … Well a few hours into debugging later it turns out it was mcp-probes fault all along!
This is the notification sent by mcp-probe:
{"jsonrpc":"2.0","method":"initialized","params":{}}
But according to the mcp docs this is how it should look like:
{
"jsonrpc": "2.0",
"method": "notifications/initialized"
}I suspect that this only works because many server implementations only check for a substring match of initialized. This is also the origin of #15.
Since mcp is a complex protocol and is only getting more complicated I suggest use rmcp client implementation instead of rolling your own mcp-core crate. Sticking to mcp-core will probably prove to be a uphill battle in the long run.
So I wanted to test the mcp server I am writing and found
mcp-probe. Tested it with my mcp server, not working … tested it against a different mcp server, working. Great so the Issue is on my end I thought … Well a few hours into debugging later it turns out it wasmcp-probesfault all along!This is the notification sent by
mcp-probe:{"jsonrpc":"2.0","method":"initialized","params":{}}But according to the
mcpdocs this is how it should look like:{ "jsonrpc": "2.0", "method": "notifications/initialized" }I suspect that this only works because many server implementations only check for a substring match of
initialized. This is also the origin of #15.Since mcp is a complex protocol and is only getting more complicated I suggest use
rmcpclient implementation instead of rolling your ownmcp-corecrate. Sticking tomcp-corewill probably prove to be a uphill battle in the long run.