I've been fighting with trying to stand up a custom MCP server for a good portion of the day today. I have a very basic MCP server stood up using Anthropic's [typescript SDK](https://github.com/modelcontextprotocol/typescript-sdk), and I'm getting 400s responses when testing the tool in the Vapi dashboard. The error that I'm receiving is:

{
  "error": "Failed to connect to MCP server: SSE error: Non-200 status code (400)"
}

The troubleshooting steps I've gone through are a bit too numerous to list, but I have yet to figure out the incantation to get a successful response. The best I had was a 200 at one point that sent the same error code. I'm not sure what I'm missing here. I can use API or function calls of course, but that comes with some pretty serious drawbacks, so it'd be great if I can use what's here. Has anyone here successfully done this? My other clients connect fine, so it's kinda looking like the standard isn't correctly implemented on Vapi's side. The github repo suggests Vapi rolled its own server rather than using the SDK, so is this unspported/intentional?

You’re likely getting the 400 error because your Express app isn’t parsing JSON bodies—add bodyParser.json() middleware before handling /messages, so req.body is properly populated for the MCP SDK.

This isn't the case here, unfortunately. I was already using

express.json

, which replaces

bodyParser.json

. Just in case it was an edge case, I tried the

body-parser

package as well, but that didn't change anything, unfortunately. Also, like I mentioned, SDK-built clients work just fine (I've been running other services against my MCP server). Is there a way I can get more detailed logs from the test? Seeing the full request might help me diagnose. With the request being sent through vapi's proxy, I'm not sure if there's something I could potentially be missing.

Try logging full request headers and bodies in Express, verify Content-Type is application/json, check for middleware conflicts, and use Vapi’s logs or API (/logs) to inspect the actual request sent through their proxy..

Ah... While I was putting together some responses for you, I found the answer. It seems that VAPI's using the legacy SSE transport rather than the streamable HTTP transport for its MCP tool integration. I changed transports and it works fine. This should have been super obvious from the error message, but I was only aware of the two newer transports (streamable and io) and thought that SSE was synonymous with Streamable HTTP. Whoops. You're on the VAPI team, right? Any idea when the newer transport will be supported/migrated to?

Yes, VAPI currently uses legacy SSE transport for MCP tool integration, and while the newer Streamable HTTP transport offers improvements, there is no update yet for the migration timeline.

Got it. Thanks! It's easy enough to switch when it happens.

Glad the issue was resolved. Please reach out to us if you have any other questions regarding this issue