### Problem/Motivation Some tools only make sense inside a multi-call workflow where entity handles carry state between calls (AI conversations, MCP sessions). In a one-shot CLI process they are pointless or unusable: - A tool that mutates a passed entity without persisting it (field_set_value, entity_stub, entity_revision_add) produces in-memory state whose only consumer is a next call that never comes. - A tool whose only output is an entity (entity_load) produces a handle with nothing to pass it to. - Tools with entity _inputs_ but real side effects (entity_save, entity_delete) are useful in principle, but the drush commands have no entity upcasting, so nothing can supply the input today. Operation kind is not the discriminator: `field_set_value` is honestly `ToolOperation::Write` (it writes to the entity) yet is workflow-only, while a scalar Transform tool is perfectly CLI-appropriate. The accurate signal is **handle dependency**: entity-typed inputs and/or outputs in the tool's definitions. ### Proposed resolution - Default filter in the CLI surfaces (tool:list, tool:run, tool:info, and any future core-CLI invoker): tools with entity-typed inputs or outputs are hidden from listings and refused at run time with a message explaining why ("this tool operates on entity handles and requires a workflow-capable invoker"). - Escape hatch (`--all` on listings, `--force`-style flag on run) rather than a hard wall — because CLI handle chaining is achievable with the existing handle service, not hypothetical. ToolHandleStore is tempstore.private, which keys by uid for authenticated users, so `drush -u` invocations share handle state across processes (within tempstore expiry). The only missing pieces are invoker wiring on the established pattern: a drush invoker ID passed in ToolRunCommand::createInstance() (currently none is passed), a thin subscriber delegating to the shared EntityHandleTransformer (as the AI connector and MCP bridge each do), and a warning when running anonymous, where session-keyed tempstore gives no cross-invocation continuity. Output needs no changes — the formatted result already carries handle strings and hints. With that wiring plus the escape hatch, chained CLI workflows (load → mutate → save across drush calls) become a documented capability while the default listing stays one-shot-appropriate. - Treat inputs and outputs independently: if drush later gains ID-based entity upcasting (e.g. accepting node:5 for entity inputs), input-side tools (entity_save, entity_delete) graduate to CLI-useful while output-side workflow tools stay hidden by default. - No new API: the filter is inferred from existing input/output definitions. If the heuristic ever misfires, the follow-up is an explicit capability declaration (tool requires handle continuity; invoker declares whether it provides it) — record that as the escalation path, not the starting point. ### API changes None. Behavioral: CLI listings shrink to tools that are actually usable there; hidden tools remain fully available to workflow-capable invokers. ### AI usage (if applicable) - [x] **AI Assisted Issue:** This issue was generated with AI assistance, but was reviewed and refined by the creator. - [x] **AI Assisted Code:** This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision. - [x] **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.