place_call
Inputs include to, goal, language, approved, and request_id. The destination uses E.164 format. The language is English or Spanish. A UUID identifies the intended operation so a retry can be distinguished from a new request.
This tool is destructive because it contacts someone and may incur usage. Obtain human approval of the exact destination and task before sending approved: true. The server checks verification, consent-related prerequisites, available credits, allowed countries, calling hours, concurrency, and configured limits.
send_text
Inputs include to, body, approved, and request_id. This tool is also destructive. Show the recipient and message body to the user before requesting approval. An API key does not supply that approval by itself.
SMS segmentation and carrier behavior can affect usage. Do not use browser-side character counts as an authoritative billing record.
get_call_result
Pass the call identifier to retrieve the organization's recorded call status and available result. A missing transcript can mean the provider has not delivered it or the call did not produce one. Do not invent an outcome to fill an empty field.
list_calls
Retrieve calls visible to the authenticated organization. Use the returned identifiers to ask about a specific result. This is a read-only operation, but the records may still contain business or personal information, so do not copy them into an unrelated workspace.
Error handling
An authentication failure, a missing provider, a limit rejection, and a failed destination are different outcomes. Surface the actual category to the user. Do not automatically resubmit a new destructive request with a new identifier after a policy rejection.
Example approval language
“Call the number I approved and ask whether Tuesday morning is available. Do not confirm a booking or make a payment.”
The goal should state both the desired outcome and the boundary that must not be crossed.