### Problem/Motivation ToolDefinition accepts output definitions declared as core context definitions (and, since #3583019, as input-family definitions), converting them through `OutputDefinition::fromContextDefinition()` with a deprecation. #3583015 added the conversion, and #3583019 kept it: the ai_automators conversion could not be confirmed, and removing the shim there would have turned those declarations into a `TypeError` mid-beta. Until now the deprecation message and the `@internal` note on `fromContextDefinition()` pointed at #3583019 and #3583015, neither of which removes the shim (review feedback on !174). This issue is the removal target those pointers now reference. This issue also takes over step 2 of [#3583049](https://git.drupalcode.org/project/tool/-/work_items/3583049): removing `multiple`. #3583049 closed when its step 1 MR merged, which left step 2 without an open work item. Step 1 deprecated `multiple: TRUE` in beta10 for removal in rc1, and the plan always had both removals land together. Five call sites still trigger that deprecation: * `ToolDefinition::addInputDefinition()` and `::addOutputDefinition()` * `MapDefinitionBase`, for input and output properties * `TypedInputsTrait`, when a refiner returns a `multiple` definition ### Proposed resolution Remove both before rc1, in one MR. **1. The output shim.** * Confirm the remaining consumers declare real output definitions: the eight canvas_tools outputs that go through the shim today, and ai_automators. * Remove the conversion branch in `ToolDefinition`, then `OutputDefinition::fromContextDefinition()` and its deprecation. * A core context definition or input definition declared as an output then fails by parameter type. **2. `multiple`** (from #3583049 step 2): * `isMultiple()`/`setMultiple()` on `InputDefinitionInterface` and `OutputDefinitionInterface`, their implementation in `ToolDataDefinitionTrait`, and the `$multiple` constructor parameter on every definition class. * `ListInputDefinition::fromMultiple()`, `ListOutputDefinition::fromMultiple()`, and the five conversions listed above. * The `isMultiple()` half of each branch in the normalizer, `validateInputValue()`, `EffectiveDataDefinition::createFrom()` (including the `@todo Fix upstream` copy), the entity handle transformer and subscriber, `RecursiveToolValueTransformSubscriber`, `InputTypeCoercionSubscriber` and `tool:info`. The list half stays. * The #3583002 carve-out for "multiple refined to a list." Once both sides are lists, the normal item-type narrowing check covers it. `ToolContextDefinition` in `tool_ai_connector` keeps setting core's `multiple` when the wrapped definition is a list. The ai module boundary is the only place the flag still exists. ### Remaining tasks * [ ] Confirm the canvas_tools and ai_automators conversions. * [ ] Confirm no downstream tool still declares `multiple: TRUE`: tool_belt, both bridges, canvas_tools, ai_agents. * [ ] MR removing the shim and `multiple`. ### API changes Removed: * Acceptance of core context definitions and input definitions declared as outputs (the `@internal` `OutputDefinition::fromContextDefinition()` and the #3583015 deprecation window). * `isMultiple()`/`setMultiple()` on `InputDefinitionInterface` and `OutputDefinitionInterface`, and the `$multiple` constructor parameter. Declare a `ListInputDefinition` or `ListOutputDefinition` instead. Unchanged: the advertised JSON Schema, the ai module boundary. ### 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.