# Problem/Motivation `SetEntityLayout` declares its `sections` input — and `EditEntityLayout` its `operations` input — with `data_type: 'map'`. Both are consumed as **ordered lists**: - `sections` is iterated and handed to `LayoutBuilderHelper::buildLayout()`. - `operations` is applied in sequence, and its `section_index` / `block_index` keys refer to positions. Both input descriptions already document an array ("Array of sections…", "Array of operations…"). The Tool API has a first-class `list` data type for this (`ListInputDefinition`, plus a `ListAdapter` plugin). Two separate schema generators consume Tool API input definitions, and both map `map` to a JSON Schema `object` and `list` to an `array`: - `Drupal\tool\Normalizer\ToolDefinitionSerializer::normalizeInputSchema()` — used by `tool_ai_connector`, i.e. the in-Drupal AI agent path. - `Drupal\mcp_server_tool_bridge\Plugin\Derivative\McpToolConfigDeriver::convertInputDefinitionToSchema()` — used when tools are exposed over MCP. Because both inputs are declared `map`, both generators emit `"type": "object"`, and the documented array payload is rejected by validation. Over MCP this is a hard failure — the tool cannot be called at all: ``` Invalid parameters for tool 'tool_api__set_entity_layout': Property '/sections': Invalid type. Expected `object`, but received `array`. ``` Passing a delta-keyed object instead (`{"0": {...}, "1": {...}}`) does not help: `json_decode()` turns it into a PHP list, which fails the same check. # Steps to reproduce Without MCP, inspect the generated schema: ```php $tool = \Drupal::service('plugin.manager.tool') ->createInstance('tool_layout_builder:set_entity_layout'); $schema = \Drupal::service('tool.definition_serializer')->normalizeInputSchema($tool); // $schema['properties']['sections']['type'] === 'object' // expected: 'array' ``` Or over MCP: 1. Expose `tool_layout_builder:set_entity_layout` by creating an `mcp_server_tool_bridge.mcp_tool_config` entity for it. 2. Call it with the payload shape given in the input description, for example: ```json { "entity_type": "node", "entity_id": 1, "sections": [ { "layout": "layout_onecol", "blocks": [ {"type": "text_one_col", "region": "content", "fields": {"field_title": "Hello"}} ] } ] } ``` 3. The call is rejected by JSON Schema validation before the plugin executes. # Proposed resolution Change `data_type: 'map'` to `data_type: 'list'` for: - `sections` in `src/Plugin/tool/Tool/SetEntityLayout.php` - `operations` in `src/Plugin/tool/Tool/EditEntityLayout.php` Both generators then emit `"type": "array"`, matching what the descriptions already promise and what the plugins already consume. Verified on Drupal 11.4.6 with `tool` 1.0.0-beta6 and `mcp_server_tool_bridge` 1.0.0-beta1: after the change, a two-section layout — a `text_one_col` block and a `cta` block, each with title, rich text and a link field — applied successfully to a node over MCP and rendered correctly. Worth noting the fix helps both consumers. The in-Drupal AI path was also receiving `"type": "object"` for these inputs, so this is not a trade-off between the MCP and agent paths. # Remaining tasks - Review. - Consider adding an `item_definition` so the schema describes a section's shape structurally, instead of relying on the prose description. # User interface changes None. # API changes None to the accepted payload. It was always documented and consumed as an array; only the declared type is corrected so that validation matches. Strictly, a caller that previously sent a delta-keyed object would now be rejected — but that shape never validated in practice. # Data model changes None.