bug with MCP calls
# support
v
anyone noticing MCP tool call changes > # ngrokfree_tool_test__lookup until now it was > # ngrokfree.tool_test__lookup the replacement of '.' with a '_' is breaking our existing flow { "name": "ngrokfree_tool_test__lookup", "role": "tool_call_result", "time": 1746636833664, "result": "[\n {\n \"type\": \"text\",\n \"text\": \"Unknown tool: ngrokfree_tool_test__lookup\"\n }\n]", "toolCallId": "call_iMChXkDpJYpfz0TKL1bnb0z8", "secondsFromStart": 22.45 }
v
Yes, there's a confirmed change in Vapi's tool naming convention from using periods (
.
) to underscores (
_
). According to [Discord discussions](https://discord.com/channels/1211482211119796234/1334114042876264518), this is affecting other users too. To fix your flow, update all tool references to use the new format:
Copy code
javascript
// Old format
"ngrokfree.tool_test__lookup"

// New format
"ngrokfree_tool_test__lookup"
Source: - [Discord discussion](https://discord.com/channels/1211482211119796234/1334114042876264518)
Yes, there's a confirmed change in Vapi's tool naming convention from using periods (
.
) to underscores (
_
). According to [Discord discussions](https://discord.com/channels/1211482211119796234/1334114042876264518), this is affecting other users too. To fix your flow, update all tool references to use the new format:
Copy code
javascript
// Old format
"ngrokfree.tool_test__lookup"

// New format
"ngrokfree_tool_test__lookup"
Source: - [Discord discussion](https://discord.com/channels/1211482211119796234/1334114042876264518)
v
but the issue is rthe prefix ngrokfree. is decided by VAPI not us
so we want to avoid any hardcoding here
ngrokfree. is taken from the MCP url we provided
k
Hello Vinod, I am following up on our discussion to confirm if this issue is still blocking you.
v
Shubham not able to find a way forward on this, there is no hack I can apply on my side as i tried to tell you earlier
we use FastMCP as our MCP wrapper serving via /sse
now your VAPI MCP client is goofing things up & sending jsonrpc like this { "method": "tools/call", "params": { "name": "ngrokfree_tool_appointment__upcoming", "arguments": { "patient_id_type": "mrn", "patient_id": "204106" } }, "jsonrpc": "2.0", "id": 1 }
with the name prefix. having _ that earlier had a dot
it all worked before & nto anymore
other mcp clients we have are working just fine
can u ask your team to test the namespace analogy again, i was able to fix this with a hack & interceptor (dont like that hack)
no one will like that IMHO as its adding a weird dependency to assume a namespace & do replace when i find that in jsonrpc calls
basically i am stripping ngrokfree_ from the inbound jsonrpc payload
y
I think the real problem is that they use to modify the tool names to server.tool\_name before injecting it to the model and when model is calling the tool I am assuming they used to remove it but now it's the "server_" is not removed anymore and it's causing the mcp to not recognize the tool.
v
yeah bad hack but will live with it for now
s
@Yassine @vinod So the Steps to Reproduce are: - Setup an MCP server (like FastMCP) serving via /sse - Configure Vapi to use this MCP server - When the model makes a tool call, it uses the format ngrokfree_tool_appointment__upcoming - The MCP server expects tool_appointment__upcoming (without namespace) - The namespace stripping logic in Vapi is looking for a dot (.) but the name has an underscore (_) - The tool call fails with "Unknown tool" error
@vinod @Yassine if my understand is correct, then the issue is: the bug is in the actual code execution path where it expects a dot but receives an underscore. This means when models call a tool like
ngrokfree_tool_test__lookup
, it's not being properly processed because the code is looking for` ngrokfree.tool_test__lookup`.
Let me know so I can raise this with the team.
y
I think the code should be looking for tool_test__lookup the ngrokfree is the server name
s
fyi
the primary purpose of the namespace prefix system is to support scenarios where an assistant has multiple MCP integrations.
@Yassine could you please confirm whether my understanding is correct, as stated above?
y
to be honnest I don't know how tool calls are handled from VAPIs side: but If the tool call reaches the MCP server with the name=server.tool_name the server won't recognize the tool name, but if its able to identify the server name and removes it before the tool call (which i think was the case before yesterday) then yes that would work.
can you please share how you did it our prod is broken for two days now
v
sure on your MCP server write a http handler that will intercept the jsonrpc payload
then just strip off any prefix you see before your function/tool name
also remodel your tool name to help we use ___tool_name
we strip off anything before _
i told these folks that their design is flawed but at some point they will review it
we are using /sse transport
y
that's smart, thanks @vinod !
s
@Yassine @vinod the bug has been fixed, apologies for the inconvience.
The bug occurred because while tools were being registered with underscore-based namespaces
(ngrokfree_tool_name)
, the code that processes tool calls was still looking for dot-based namespaces
(ngrokfree.tool_name)
when stripping the namespace to send just tool_name to the actual MCP server.
Let me know if you need more help or have questions.
i
Hi, I still can't connect my mcp server, is this fix live now?
k
Yes @issac the fix is live. Could you please describe the issue your facing and steps to reproduce it?
i
@Shubham Bajaj I have my own mcp server, and I am using the typescript package modelcontextprotocol/sdk. I was initially only using the StreamableHTTPServerTransport, but I've added the backward compatibility with the SSEServerTransport class. Neither is working with vapi still. Both crashing, when running List MCP Tools, with the message: "error": "Failed to connect to MCP server: SSE error: Failed to fetch"
k
Hey, Could you please schedule a brief call at your convenience so we can discuss this matter in detail? Kindly use the following link to book a suitable time: .
2 Views