davidcaldicott
02/04/2026, 12:36 PMAI Evy
02/04/2026, 12:36 PMAI Evy
02/04/2026, 12:36 PM{{user_number}}. [(1) ]()
For phone calls specifically, these system default dynamic variables are available:
- **{{direction}}**: inbound or outbound
- **{{user_number}}**: user phone number (for inbound calls this is the from_number, for outbound it's the to_number)
- **{{agent_number}}**: agent phone number (for inbound calls this is the to_number, for outbound it's the from_number)
So in your custom function, you would use {{user_number}} as the dynamic variable to pass the inbound caller's phone number as a query parameter to your webhook.
For custom functions, you can make GET, POST, PUT, PATCH, and DELETE requests and add custom headers and query parameters.AI Evy
02/04/2026, 12:36 PMAI Evy
02/04/2026, 12:36 PMdavidcaldicott
02/04/2026, 1:24 PMdavidcaldicott
02/04/2026, 1:25 PMAI Evy
02/04/2026, 1:25 PMAI Evy
02/04/2026, 1:25 PM{{user_number}} unless you explicitly configure them as const values rather than letting the LLM decide. [(1) ]()
To ensure {{user_number}} is passed correctly, you have two options:
Option 1: Use a const value in query parameters
When setting up your MCP tool, add a query parameter and toggle it to use a const value instead of a description. Set the const value to {{user_number}}. This will be applied directly without LLM interpretation. [(2) ]()
Option 2: Switch to a Custom Function
Custom functions give you more explicit control. When defining query parameters, you can switch between "parameter description" (resolved by LLM) or "const value" (applied directly) . For const values, you can use dynamic variables like {{user_number}} which will be evaluated at runtime.
The key difference: when you provide a description, the LLM decides what value to pass based on conversation context (which is why it may hallucinate a phone number) . When you use a const value with {{user_number}}, it bypasses LLM interpretation and uses the actual system variable. [(3) ]() [(2) ]()
Also, make sure your prompt explicitly instructs the agent to use the caller's phone number from the system, not to invent one. [(1) ]()AI Evy
02/04/2026, 1:25 PMAI Evy
02/04/2026, 1:25 PMdavidcaldicott
02/04/2026, 1:38 PMAI Evy
02/04/2026, 1:38 PMAI Evy
02/04/2026, 1:38 PM{{user_number}} as a const value in query parameters. However, there's an important consideration: if you're testing via web call or the chat interface, the {{user_number}} variable will be empty because there's no actual phone number associated with the session. [(1) ]()
The phone call system variables like {{user_number}}, {{agent_number}}, and {{direction}} are only available for phone calls—not web calls or chat sessions.
To verify this is the issue:
- Test with an actual phone call (inbound or outbound) rather than web testing [(2) ]()
- The {{user_number}} variable represents the user's phone number: for inbound calls it's the from_number, for outbound it's the to_number [(1) ]()
If you need to test without a real phone call, you have two options:
1. **Use agent-level default dynamic variables**: Set a default value for a custom variable in your agent configuration that will be used as a fallback when the variable isn't provided in the call request
2. **Use the Extract Dynamic Variables function**: If you need the agent to capture a phone number the user speaks during the conversation (rather than the caller ID) , you can use the extract dynamic variables feature to save it and then reference it in your custom function [(2) ]()
The agent saying "phone_number field wasn't provided" suggests the {{user_number}} variable evaluated to empty/null during your test, which confirms this is likely a web call testing issue.AI Evy
02/04/2026, 1:38 PMAI Evy
02/04/2026, 1:38 PM