### Problem/Motivation On cores before 11.1, `ContextDefinitionNormalizer` builds the JSON Schema for a plain `InputDefinition` or `OutputDefinition` declared with `data_type: 'map'` as a string: ```json {"type": ["string", "null"], "description": "Options: A map declared on the plain output class.", "title": "Options"} ``` On 11.1 and later the same definition is `{"type": "object", "properties": {}}`. Only plain definitions are affected. `MapInputDefinition` and `MapOutputDefinition`, with or without property definitions, are `MapDataDefinition` subclasses and take the map branch at src/Normalizer/ContextDefinitionNormalizer.php:181, which emits an object on every core. A plain definition with `data_type: 'map'` is a `DataDefinition`, so it falls through to the typed-data branch at line 204: 1. `getTypedData()` creates a `Map` and asks the serializer for its `json_schema`. 2. On cores before 11.1 the serializer picks `LegacyTypedDataNormalizer`, registered at priority 1000 for every `TypedDataInterface` (tool.services.yml:57-60, src/Normalizer/LegacyTypedDataNormalizer.php:104). It has no arm for `Map`, so it returns `[]` (line 82). `MapDefinitionNormalizer` would handle `Map`, but it is registered at priority 100 (tool.services.yml:52-55) and is never reached. 3. The empty result is falsy, the data type is not `any`, so the fallback at ContextDefinitionNormalizer.php:252-255 advertises `{"type": "string"}`. The list data type had the same problem and is already special-cased by data type at line 155 (`$object->getDataType() === 'list'`). Maps have no equivalent. Plain `map` declarations are common. tool_belt declares 28 of them: 8 inputs (`entity_create`, `entity_update` and `entity_stub` `base_fields`/`fields`, `field_set_value` list items, `log_message` `context`, `image_effect_add` `settings`) and 20 outputs (`entity_field_values` `field_values` and `referenced_entities`, `entity_bundle_field_definitions`, `entity_list` result items, `system_status`, and more). On Drupal 10.6 and 11.0: * Inputs: the schema asks for a string. A server that validates arguments against the input schema (mcp_server does, through mcp/sdk) rejects the object the tool needs. A string that passes the schema is then rejected by Tool API: "Invalid values given. Values must be represented as an associative array." * Outputs: `structuredContent` carries an object where the `outputSchema` says string, which a client that validates structured results rejects. Tool API's own tests catch this. On 10.6.18, `AdvertisedOutputSchemaConformanceTest::testOutputsMatchTheirAdvertisedSchema` fails on `empty_map_output_tool.options` (an empty map sent as `{}` does not match the string schema), and `AdvertisedSchemaAcceptanceTest::testSchemaValidValuesAreAccepted` and `::testLlmShapedValuesAreAccepted` fail on `plain_structure_tool.options`. CI did not report it because the previous-major PHPUnit job never runs. ### Steps to reproduce On Drupal 10.6 (or 11.0) with Tool API 1.0.x: 1. Enable `tool` and `tool_test`. 2. Normalize the input and output schema of `plain_structure_tool`: ```php $tool = \Drupal::service('plugin.manager.tool')->createInstance('plain_structure_tool'); $serializer = \Drupal::service('tool.definition_serializer'); $serializer->normalizeInputSchema($tool); $serializer->normalizeOutputSchema($tool); ``` 3. Observed: `options` (input) and `summary` (output) are `{"type": ["string", "null"], ...}`. `profile` and `stats`, declared with the map classes, are objects. 4. Expected: `options` and `summary` are `{"type": ["object", "null"], "properties": {}, ...}`, as on 11.1+. Or run `tests/src/Kernel/Matrix/AdvertisedOutputSchemaConformanceTest.php` and `tests/src/Kernel/Matrix/AdvertisedSchemaAcceptanceTest.php` on Drupal 10.6. ### Proposed resolution Treat a definition whose data type is `map` as a map in `ContextDefinitionNormalizer::getNormalizationSchema()`, the way line 155 already treats the `list` data type: ```php elseif ($object instanceof MapDataDefinition || $object->getDataType() === 'map') { $schema = ['type' => 'object']; $properties = $object instanceof MapDataDefinition ? $object->getPropertyDefinitions() : []; // ... existing property loop, empty-properties object and map constraints. } ``` This gives the same schema on every core and applies `applyMapConstraintSchema()` to plain maps too. Adding a `Map` arm to `LegacyTypedDataNormalizer` would also fix the string, but only on the legacy path, and plain maps would keep getting scalar constraint handling. ### Remaining tasks * Implement the data-type check and confirm on 10.6 that both matrix tests above pass. * Check which other data types reach the string fallback on the legacy path (for example `binary` and `language_reference` also come out as `string` on 10.6) and decide whether any of them need their own arm. * Get the previous-major PHPUnit job running so this stays covered. ### 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.