### Problem/Motivation With Tool API 1.0.0-beta10, `canvas_get_component_schema` fails for any component that has no slots or no props. On a site with byte_theme that is 24 of the 41 enabled components, including heading, text, card, button and image: ``` {"component_id": "sdc.byte_theme.heading"} Tool execution failed: Object(Drupal\Core\TypedData\Plugin\DataType\Map): Output slots: This value should not be null. ``` Found in an MCP end-to-end pass (canvas_tools 1.0.0-beta1, tool 1.0.0-beta10, mcp_server 2.0.0-beta5, mcp_server_tool_bridge 1.0.0-beta3). Without this tool an agent cannot learn the prop names and shapes of those components, so it has to guess them for `canvas_update_component_props` and `canvas_add_component`. Cause: 1. `GetComponentSchemaTool` declares `props` and `slots` as `OutputDefinition(data_type: 'map')` without `required:` (src/Plugin/tool/Tool/GetComponentSchemaTool.php:43-52), and `OutputDefinition` defaults to required. `CanvasManager::getComponentSchema()` returns `[]` for a component without props, and `getSlotDefinitions()` returns `[]` for one without slots. 2. Tool API 1.0.0-beta10 validates outputs after a successful execution and turns a violation into a failure (tool #3583029, `ToolBase::failOnOutputViolations()`). canvas_tools 1.0.0-beta1 was released against `^1.0.0-beta9`, which did not validate outputs, so this is a regression from the Tool API update rather than from a canvas_tools change. 3. A required map is validated as typed data with core's NotNull constraint, and `NotNullConstraintValidator` treats an empty `ComplexDataInterface` (an empty `Map`) as NULL. The other map outputs in the module are lists of maps (`components`, `targets`, `auto_saves`, `tree`), where an empty list is valid, so they are not affected. ### Steps to reproduce 1. With Tool API 1.0.0-beta10, call `canvas_get_component_schema` with a component that has no slots, for example `{"component_id": "sdc.byte_theme.heading"}` (or `sdc.canvas_test_sdc.props-no-slots` in the test module). 2. Observed: the failure above. Expected: success with `"slots": {}`. ### Proposed resolution Declare `props` and `slots` with `required: FALSE`. This is the convention Tool API documents for maps that can be empty (its `EmptyMapOutputTool` test fixture: "The maps are optional because a required map rejects an empty value"), and what tool_belt did for the same failure in https://git.drupalcode.org/project/tool_belt/-/work_items/3616175. It works on `^1.0.0-beta9` and beta10. Tool API's output coercion already sends an empty map as `{}`. The cost is that the advertised schema no longer says the two keys are always present. Saying "always present, may be empty" is not possible yet: https://git.drupalcode.org/project/tool/-/work_items/3583043. ### Tool API: is rejecting an empty required map the right rule? This needs a decision on where the fix belongs long term. The rejection is intentional in Tool API. https://git.drupalcode.org/project/tool/-/work_items/3583040 first let both required lists and required maps be empty, then kept NotNull for maps (commit bca6986, "Keep a required map's NotNull; only a list may be empty"). The reason, documented in `EffectiveDataDefinition` and asserted by `RequiredEmptyListTest`: a map is an object with named properties, and its NotNull is what rejects `[]` for a map with required properties, because core skips the properties of an empty map (https://www.drupal.org/project/drupal/issues/3256536). Dropping it would let an empty map that is missing a required property pass validation. That reason covers maps that declare required properties. `props` and `slots` are free-form maps with no declared properties, so for them the rejection protects nothing, while the advertised schema (`object`) accepts `{}`. Options: * Keep Tool API as is and declare every map that can be empty as optional in each consuming module (this issue's proposed resolution). Every tool author has to know the rule. * Narrow the rule in Tool API: let a required map be empty when it declares no required properties, and keep NotNull for maps with required properties. That would fix all consumers and keep the protection #3583040 was after, but it needs Tool API's agreement and a release. Either way the change here is needed now, since canvas_tools depends on released Tool API versions. ### Remaining tasks * Declare `props` and `slots` optional. * Kernel test: `canvas_get_component_schema` succeeds for a component without props and for one without slots, and the formatted result sends `{}` for the empty map. * Decide whether to raise the narrower rule with Tool API. ### 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.