MCP Tool in assistantOverrides never called
# support
j
The MCP Tool specified in the assistantOverrides is never user:
Copy code
Python
"messageResponse": {
    "assistantId": "id",
    "assistantOverrides": {
        "firstMessage": f"Hi {request.user.first_name}, how are you doing?",
        "serverMessages": ["tool-calls"],
        "transcriber": {
            "provider": "deepgram",
            "model": "nova-2",
            "language": "multi",
        },
        "model": {
            "provider": "openai",
            "model": "gpt-4o-mini",
            "tools": [
                {
                    "type": "mcp",
                    "server": {
                        "url": "https://example.com/sse",
                        "headers": {
                            "x-google-client-id": "id",
                            "x-google-client-secret": "secret",
                            "x-google-redirect-uri": "url.com",
                            "x-google-refresh-token": "secrets"
                        }
                    },
                    "metadata": {
                        "protocol": "sse",
                    }
                }
            ]
        }
    },
}
So, whenever I call the Assistant, I do see logs on the MCP Server that there is a connection created, the id/srecret/uri/token are all passed to the Server as well correctly. But somehow, the tools exposed are never user. What could be the issue?
c
Hey joris97jansen, I wanted to let you know that we're managing a high volume of support requests at the moment, so our response time might be a bit slower than usual. I truly appreciate your understanding and will get back to you as soon as possible!  Thanks again for your patience!
j
No problem, take your time! 🙂
Btw, I specify serverMessages like this
Copy code
"serverMessages": ["tool-calls"]
Because specifying it like this:
Copy code
"serverMessages": "tool-calls"
Results in an error, on the other side of the line I hear this: Couldn't get assistant, either set the AssitantId or debug your request. But the docs say that it has to be done via the second method (as a plain string). But, I never receive these serverMessages (probably because the tool is never user/called).
c
Hey, Can you send me the latest call_id? Along with that, can you provide me the duration in the recording where you had this issue?
j
Hi Praveen, which issue are you talking about? The issue with the MCP Server?
c
Hey, Sorry for the misunderstanding. Could you please explain in detail the issue you’re facing?
j
Sure! I register a users phone number using the API, in that request, I add a 'Server' and the 'serverUrl'. On that URL, I receive Server Messages, one of these messages is of type
assistant-request
. As a response, I return an
assistantId
and some
assistantOverrides
, the response looks like this:
Copy code
Python
"messageResponse": {
    "assistantId": "id"
    "assistantOverrides": {
        "firstMessage": "Hi Joris, how are you doing?",
        "serverMessages": ["tool-calls"],
        "transcriber": {
            "provider": "deepgram",
            "model": "nova-2",
            "language": "multi",
        },
        "model": {
            "provider": "openai",
            "model": "gpt-4o-mini",
            "tools": [
                {
                    "type": "mcp",
                    "server": {
                        "url": "https://example.com/sse",
                        "headers": {
                            "x-google-client-id": "id",
                            "x-google-client-secret": "secret",
                            "x-google-redirect-uri": "uri",
                            "x-google-refresh-token": "refresh_token"
                        }
                    },
                    "metadata": {
                        "protocol": "sse",
                    }
                }
            ]
        }
    },
}
Now, there are basically 2 issues: 1. The Assistant never calls/uses the MCP Server which I provide to the model. 2. The
serverMessages
entry has to be a list, not just a string (the docs say is has to be a string), which results in an error when I try to call the assistant: Couldn't get assistant, either set the AssitantId or debug your request.
c
Hey joris97jansen, I sincerely apologize for the delay in our responses this week. We experimented with some process adjustments that didn’t work as intended, and unfortunately, this caused some disruptions. That’s entirely my responsibility. Just a quick note—our team is unavailable on weekends. However, if something urgent or critical comes up, feel free to reach out to me directly, and I’ll assist you. The support issues will be resolved in the coming weeks, and starting Monday, you can expect more consistent and improved support. Thank you so much for your patience and for continuing to stick with us!
j
Are there any updates, guys?
c
Hi, First off, we want to sincerely apologize for the delay in getting back to you. We understand how frustrating it is to wait - especially when you're counting on us - and we owe you a clear explanation of what’s been happening and how we’re addressing it. Over the past few weeks, we've seen a significant increase in support requests. While this reflects exciting growth, it has also stretched our small team and exposed some real challenges in scaling our support operations. To improve your experience, we’ve taken a step back to reassess our approach. Here’s what we’re implementing: - Smarter Support Through Automation: We’re investing in our AI support systems to help you resolve issues more efficiently. Soon, our support bot will offer expanded capabilities, making it easier to access accurate, instant help—particularly for common or repetitive queries. - Expanding the Support Team: To meet growing demand, we’re adding 2–3 new team members focused on managing support volume and improving response times. - Prioritized SLAs for High-Usage Accounts: We’re introducing service level improvements for users who are growing with us: - Accounts with usage over 1,000 minutes/month will receive prioritized support. - For all general inquiries, we’re establishing a standardized 48-hour response time. We’re confident these steps will lead to faster, more reliable support and help us better serve you as you grow with us. Also, in case you still need help with this ongoing ticket, do let us know, and we will help you get this resolved as soon as possible. Thank you for your continued patience and for being part of our journey. Warm regards, Vapi Team
r
@joris97jansen any updates on this? I'm facing a similar issue
j
@RyGuy nope, I stopped sending messages to them and eventually entirely abandon the project… sorry!
r
Ahh bummer. Well I appreciate the response
3 Views