Skip to main content
Tool Call Hooks provide fine-grained control over tool execution during agent operations. These hooks allow you to intercept tool calls, modify inputs, transform outputs, implement safety checks, and add comprehensive logging or monitoring.

Overview

Tool hooks are executed at two interception points: Write them with the @on decorator. The legacy @before_tool_call / @after_tool_call decorators keep working unchanged — both styles register on the same engine and run in one ordered chain.

Hook Signature

Unlike the boundary and step points, the tool-call points pass the rich ToolCallHookContext directly as the hook argument (there is no separate ctx.payload): mutate ctx.tool_input in place before the call, and return a string to replace the result after it. When a call is blocked, the tool does not run and the agent receives "Tool execution blocked by hook. Tool: <name>" as the result — the run continues. POST_TOOL_CALL hooks still fire on blocked calls, so monitoring hooks see every attempt.

Tool Hook Context

The ToolCallHookContext object provides comprehensive access to tool execution state:
For typed tool outputs, tool_result is the string the agent sees. By default, this is JSON. If the tool uses custom formatting, it can be Markdown or another string. Use raw_tool_result when your hook needs the typed object or dictionary; it is not affected by result replacement. The context also exposes request_human_input(prompt, default_message), which pauses live console updates and collects input from the terminal — useful for approval gates.

Modifying Tool Inputs

Important: Always modify tool inputs in-place:

Registration Methods

1. Global Hooks

Apply to all tool calls across all crews. Use tools= / agents= filters to scope a hook:

2. Crew-Scoped Hooks

Apply the same decorator to a method inside a @CrewBase class to scope the hook to that crew only:

Common Use Cases

1. Safety Guardrails

2. Human Approval Gate

3. Input Validation and Sanitization

4. Result Sanitization

5. Tool Usage Analytics

6. Rate Limiting

Hook Management

The legacy management API (register_before_tool_call_hook, unregister_before_tool_call_hook, clear_before_tool_call_hooks, clear_all_tool_call_hooks, get_before_tool_call_hooks, and their after_ counterparts) operates on the same underlying registries, so either API can manage hooks registered by the other.

Legacy Decorators

The original per-point decorators keep working unchanged and run in the same registration-order chain as @on hooks:
Differences from @on:
  • Blocking is return False from a before hook — equivalent to raising HookAborted, but without a custom reason or source for telemetry. The agent sees the same "Tool execution blocked by hook" message.
  • Signatures are point-specific: before hooks return bool | None, after hooks return str | None. The context object is the same ToolCallHookContext.
  • Filters and crew-scoping work the same way: @before_tool_call(tools=[...], agents=[...]), and applying the decorator to a @CrewBase method scopes it to that crew.
Prefer @on for new code; keep the legacy style where it is already in use — there is no behavioral penalty.

Best Practices

  1. Keep hooks focused and fast — they run on every tool call
  2. Modify in-place — always mutate ctx.tool_input, never replace the dict
  3. Prefer filters over conditionalstools= / agents= keep hook bodies small
  4. Abort loudly — raise HookAborted with a meaningful reason and source; any other exception is swallowed (fail-open)
  5. Use type hints — annotate with ToolCallHookContext for IDE support
  6. Clear hooks in tests — call clear_all_hooks() between test runs

Troubleshooting

Hook Not Executing

  • Verify the hook is registered before crew execution
  • Check whether an earlier hook blocked the call (subsequent pre hooks don’t run)
  • Check tools= / agents= filters against the actual tool name and agent role

Input Modifications Not Working

  • Use in-place modifications: ctx.tool_input['key'] = value
  • Don’t replace the dict: ctx.tool_input = {}

Result Modifications Not Working

  • Return the modified string from a POST_TOOL_CALL hook
  • Returning None keeps the original result

Tool Blocked Unexpectedly

  • Check all pre hooks for HookAborted / return False conditions
  • The abort reason and source appear on the HookDispatchedEvent telemetry