**Current plan is in the comments: https://git.drupalcode.org/project/tool/-/work_items/3583078#note_3437724. Issue description will be updated after alignment.** ### Problem/Motivation `ToolInterface` is two things at once: a stateless definition (input/output definitions, the declared permission, requirements) and a stateful invocation (`setInputValue()`, the invoker, `execute()`, the memoized results). Every invoker - `tool:run`, the Explorer execute form, tool_ai_connector, the MCP bridge - re-implements the run sequence against that instance, and the ordering (check the declared permission, set inputs, `access()`, `execute()`) holds by documented contract (https://git.drupalcode.org/project/tool/-/work_items/3583077), not by construction. D34dMan laid out the alternative in https://git.drupalcode.org/project/tool/-/work_items/3583031#note_2976503: keep the plugin stateless, move per-call state into an invocation object, and run every invocation through one service that owns validate, access, execute. Parts of that analysis have since shipped - the value-free access answer is `ToolManager::checkPermission()` (https://git.drupalcode.org/project/tool/-/work_items/3583064), typed outcomes are `FailureCategory`, and the declaration/evaluation split is codified. The structural half is the open remainder. What one execution path would buy, beyond ordering-by-construction: * **One attach point for cross-cutting runtime features.** Human confirmation of destructive tools (the `destructive` flag exists on definitions with nowhere central to enforce it), at-most-once execution per call id, auditing/logging of every tool run. With five callers, each of these is five patches and permanent drift. * **A stateless plugin**, so definitions can be shared, cached, and reasoned about without instance lifecycle questions (the prototype-cache and shared-definition-mutation classes of bug). * **Honest result typing at the boundary**: a runner returns `ExecutableResult` with `FailureCategory`, where `access()` is forced into `AccessResultInterface`. The cost is equally real: invocation state is load-bearing (typed-data value storage from https://git.drupalcode.org/project/tool/-/work_items/3583018, memoized formatted results, instance-bound refinements), `setInputValue()`/`execute()`/`getResult()` are what the bridge and the connector build on, and the note's own assessment holds: feasible before 1.0.0, an API break after. Deprecated thin wrappers on `ToolBase` that create an invocation internally are the plausible bridge. ### Proposed resolution Decide, before rc1 freezes the API, whether 1.0.0 ships with: 1. **The runner split**: an invocation object plus one execution service, `ToolBase`'s stateful methods becoming deprecated wrappers; or 2. **The documented contract as the contract**: the invoker ordering from #3583077, revisited post-1.0 only as an additive service the stateful API delegates to. Either answer is defensible; not deciding is how it becomes an API break by default. The #3583077 implementation should be shaped as a small shared sequence helper either way, so the seam exists whichever way this lands. ### Remaining tasks * Maintainer discussion; then either a plan of record for the split or a documented decision to stay stateful for 1.0. ### AI usage (if applicable) * [x] AI Assisted Issue: This issue was generated with AI assistance, but was reviewed and refined by the creator. * [ ] AI Assisted Code: This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision. * [ ] AI Generated Code: This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human. * [ ] Vibe Coded: This code was generated by an AI and has only been functionally tested.