> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threetone.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Tool execution

> Review authored timing, interruption, and error settings while keeping configuration checks separate from live execution evidence.

Execution settings describe when a tool should run and how the conversation should handle its result. Review them alongside the action's input schema and the service that performs the work.

<Note>
  The settings below are configuration contracts. They do not prove working scheduling, background execution, speech timing, retries, or live tool calls. See [current availability](/agents-platform/overview#current-availability) before building a conversation integration.
</Note>

## Timing and response settings

| Field | Authored choices |
| - | - |
| `execution_mode` | `immediate`, `post_tool_speech`, or `async` on tool types that expose it. |
| `response_timeout_secs` | Requested response timeout; allowed ranges differ by tool type. |
| `interruption_mode` | `allow`, `disable_during_tool`, or `disable_during_tool_and_turn`. |
| `pre_tool_speech` | `auto`, `force`, or `off`. |
| `tool_call_sound` | Optional supported sound identifier. |
| `tool_call_sound_behavior` | `auto` or `always`. |
| `tool_error_handling_mode` | `auto`, `summarized`, `passthrough`, or `hide`. |

For client tools, also review `expects_response`. MCP tools have their own approval policy. Use the exact tool schema instead of copying settings across tool types.

## Prepare a result contract

<Steps>
  <Step title="Define success">
    Specify which result proves that the action completed. For a write operation, include a stable record identifier or another way your service can check the final state.
  </Step>

  <Step title="Define uncertainty">
    Decide what happens when a timeout occurs after the service may have accepted a request. A timeout is not proof of failure. Design duplicate-request handling in the service that owns the action.
  </Step>

  <Step title="Review error exposure">
    Avoid returning credentials, private records, or internal diagnostics in an error intended for the conversation. Do not depend on a saved error-handling mode as proof that sensitive output will be removed.
  </Step>

  <Step title="Separate the checks">
    First reopen the dashboard tool to confirm its saved settings. Next inspect the agent's attachment in a draft. Keep actual invocation and result verification pending until the relevant execution path is available.
  </Step>
</Steps>

Tool management, including execution-history reads, currently rejects personal API keys. Use the supported dashboard workflow. An empty execution list is not proof that a configured tool was tested successfully.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does async create a background job?" id="faq-tool-execution-async">
    The enum records the requested mode. This guide does not establish a released background-execution mechanism, retry policy, or delivery guarantee.
  </Accordion>

  <Accordion title="Can I retry every failed call automatically?" id="faq-tool-execution-retry">
    A write may have completed even if its response was lost. Your service needs a way to recognize repeated requests and inspect uncertain outcomes before retrying.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.