### Problem/Motivation Two calls in eca_tool fatal against the current `tool` 1.0.x. `EcaDeriver::createDefinition()` passes a `multiple:` named argument to `ListInputDefinition` and `ListOutputDefinition`, whose constructors dropped that parameter in tool#3583049, so every ECA tool event declaring `data_type: list` dies with `Error: Unknown named parameter $multiple`. `Tool::buildNativeElement()` calls `$inputDefinition->getDataDefinition()`, removed together with the `ContextDefinitionInterface` parentage in tool#3583019, so the ECA action configuration form fatals on any input that resolves to a native widget. Two further defects surfaced while reproducing those. `ToolDeriver` takes the tool ID from `$definition->id()` instead of the `ToolManager::getDefinitions()` array key. Core never writes the derivative ID onto an object plugin definition, so every derivative of a tool whose own deriver does not rewrite `id` collapses onto one ECA action and the individual tools get no action at all. And `multiple: true` on a non-list data type still reaches the Tool API constructors, which now emits a deprecation and is removed in tool 1.0.0-rc1. Separately, the derived tools declare no permission on their definition. tool#3583064 added `ToolDefinition::setPermission()` and `ToolManager::checkPermission()` as the static gate that catalogs, pickers, agent function lists and Drush use to filter tools without instantiating them, so ECA tools are currently offered to every account. Declaring the event's permission there needs a guard, because `ToolManager::processDefinition()` throws on a permission string that mixes `,` and `+` and that field is free text: one bad model would take tool discovery down site-wide. ### Proposed resolution - Build list definitions without `multiple:`, and map the YAML `multiple: true` onto a real `ListInputDefinition`/`ListOutputDefinition` here rather than letting the Tool API convert it. The annotations and a `Count` constraint describe the list, the data type and every other constraint describe its item. `fromMultiple()` is `@internal` and goes away with `multiple`, so the semantics are reproduced, not called. - Replace `getDataDefinition()` with `EffectiveDataDefinition::createFrom()`, as the Tool API's own configure and execute forms do. - Key the action deriver off the definitions array key. - Declare each derivative's permission from the event configuration, falling back to `execute eca tools` for an empty value and for a mixed-operator string, and reject a mixed-operator string in the event form. `Eca::checkAccess()` then stops re-checking the permission, since `ToolBase::access()` enforces the declared one first and combines this result with `andIf()`, and keeps only the rule a static definition cannot express: fail closed when the backing model is missing, disabled or no longer carries the event. - Add the invoker sequence step the action was missing: check the declared permission before any configured input is resolved. - Treat a list definition, not `isMultiple()`, as the multi-value case in the action configuration form. ### Remaining tasks - [ ] Review and merge ### API changes None. The `arguments`/`outputs` YAML grammar is unchanged, including the `multiple` key. ### AI usage - [x] **AI Assisted Issue:** This issue was generated with AI assistance, but was reviewed and refined by the creator.