Skip to content
docsv0.12.0

ToolExecutedEvent

POST event (tool-runtime 0.5, event-driven retrofit): a tool call finished, successfully or via a cache short-circuit. Dispatched by {@see \Milpa\ToolRuntime\ToolRegistry::call()} as `tool.executed` — pure notification, readonly, no slot (per the family's pre/post convention: `*ing` events are stoppable, `*ed` events are audit-only). {@see \Milpa\ToolRuntime\ToolAuditLogger} subscribes to this event to log every call; other listeners (metrics, tracing, ...) may subscribe alongside it without touching {@see \Milpa\ToolRuntime\ToolRegistry}. **Cache-hit visibility invariant.** When a `tool.executing` listener short-circuits via `InterceptionSlot::shortCircuit()`, the tool's real callback never runs — but this event MUST still fire, with {@see $cacheServed} `true`. A cache hit that is invisible to `tool.executed` listeners (audit, metrics) is a blind spot, not an optimization; see {@see \Milpa\ToolRuntime\ToolRegistry::call()} for where this is guaranteed.

ToolExecutedEvent::__construct()

public function __construct(string $name, Milpa\ToolRuntime\Contracts\ToolContext $ctx, array $args, Milpa\ToolRuntime\ToolResult $result, bool $cacheServed = false):

Parameters

Parameters of __construct()
NameTypeDescription
$namestringTool name that was called
$ctxToolContextExecution context the call ran under
$argsarray<string, mixed>The (validated/clamped) arguments the call ran with
$resultToolResultThe result returned to the caller
$cacheServedboolTrue if a `tool.executing` listener short-circuited the call (the real callback never ran) and this result came from that listener instead