Function calling (tool use)
Function calling, also called tool use, is a way for an AI agent to request a defined external action using structured inputs instead of merely describing the action in natural language. The application executes the requested function and returns a result that the agent can use in the conversation.
A tool has a name, a purpose, and an input schema. During a call, an agent might request a function that checks availability, looks up an authorized record, or creates a service request. The surrounding application validates the arguments, performs the operation, and reports success, failure, or data back to the agent. The agent then explains the result or asks for whatever information is still missing.
Function calling differs from a webhook. A function call is typically initiated because the agent needs data or an action while handling the conversation. A webhook sends an event to another system when something happens. The two can coexist in one workflow, but they solve different coordination problems.
Reliable tool use requires controls outside the prompt. Inputs should be validated, permissions should be limited, and sensitive actions should require appropriate confirmation. Operations that may be retried should be designed to avoid accidental duplicates. The agent also needs explicit behavior for timeouts, unavailable systems, empty results, and partial failures; inventing a successful outcome is never an acceptable fallback.
Latency matters on a phone call. The caller cannot see a loading indicator, so the workflow may need a brief spoken acknowledgement while a tool runs. The agent should not claim completion until the application confirms it, and it should distinguish “no result” from “the request failed.” Logs should connect the spoken exchange, tool request, validated inputs, and returned result for later review.
In practice on ThunderPhone, remote Model Context Protocol servers can be added by URL, synchronized for automatic tool discovery, and attached to agents. Static HTTP headers are supported. The supported transport is streamable HTTP; local servers that support only standard input and output are not supported.
When evaluating function calling, test malformed values, repeated requests, caller corrections, slow responses, authorization failures, and tools returning unexpected data. A polished conversation is not enough: the external action and the caller's understanding of it must both be correct.