Design reliable tool actions

Use the execution description to explain when the Agent should call a tool. State the required information and what it should say after success or failure.

Write an execution description

For a callback request:

Use create_callback_request after the caller's name, reason and preferred
callback number are known and confirmed. Submit the confirmed values.
Do not invent missing fields. Confirm submission only when the tool succeeds.
If it fails, explain that submission could not be confirmed and use the
configured fallback. Do not repeat a write automatically without checking
whether the first request succeeded.

Replace create_callback_request with your tool’s name. Describe a specific next step for failures, such as an alternative way to contact the team. Mark required inputs in the schema as well.

Make inputs explicit

Give each field a clear name, the correct type and a short description. Choose String for phone numbers and Boolean for yes/no values. Store credentials under Credentials.

For dynamic email or forwarding destinations, specify the trusted source. A caller's requested destination alone is not sufficient authorization to route private data or calls anywhere.

Handle the result

Result	Agent behavior
Confirmed success	State the actual completed action.
Missing input	Ask for the missing information.
No match	Explain that nothing was found and ask a useful follow-up question.
Error or timeout	Explain the reported error. If the outcome is unclear, do not claim success or failure and offer the planned next step.

Leave Run in background off if the Agent needs to wait for the result. For API, MCP and web search tools, you can enable a short progress message. The Agent writes it to fit the conversation.

Test the whole sequence

Check assignment, input values, request, response processing and final wording. Include an error case and a second attempt after a caller correction. See API tools for the test panel and response mapping for the data the Agent receives.