> ⚠️ **Postponed pending approval.** Part of the [Chat Fundamentals plan](https://git.drupalcode.org/project/ai/-/work_items/3586640); awaits maintainer approval ([approval issue](https://git.drupalcode.org/project/ai/-/work_items/3586639)). Targets the **1.6.x branch once it is created**. **Depends on:** [content blocks on ChatMessage (#3586643)](https://git.drupalcode.org/project/ai/-/work_items/3586643). ### Problem/Motivation Once messages carry MCP content blocks (#3586643), every consumer still needs bespoke code to turn a block into markup. Without a shared rendering path, each chatbot reinvents "how does a `resource_link` become a link", "how does a weather tool's payload become a card", and — most dangerously — "how does an entity reference become rendered entity output" with access checking done ad hoc or not at all. The ai module already leans this way informally: `ChatMessage::getRenderedTools()` exists (though it produces the OpenAI wire structure, not a render array), and the assistant processor hand-builds trusted HTML in `getPostResponseMarkup()`. What is missing is the standard Drupal answer: a plugin type that maps a data structure to a render array, so themes and modules can take over presentation. ### Proposed resolution A new plugin type in ai core: - **Attribute** `src/Attribute/ChatBlockRenderer.php` — properties: `id`, `label`, `block_types: string[]` (which MCP types the plugin handles), `weight`. - **Interface** `src/Plugin/ChatBlockRenderer/ChatBlockRendererInterface.php`: - `applies(array $block, array $context): bool` - `build(array $block, array $context): array` — returns a render array. - Context shape: `['role' => string, 'tool_name' => ?string, 'thread_id' => ?string, 'message_meta' => array]`. Because `tool_name` and the block's `_meta` are in scope, a module can register a renderer that matches `tool_name === 'get_weather'` (or a namespaced `_meta` key) and return a Twig-templated card — together with the ai_agents structured-tool-output child issue this delivers the "weather tool → Twig template" capability end to end. - **Base class** `src/Base/ChatBlockRendererBase.php`, **manager** `src/PluginManager/ChatBlockRendererPluginManager.php` (service `plugin.manager.ai.chat_block_renderer`, alter hook `hook_chat_block_renderer_info_alter()`), following the ChatProcessor plugin type's structure. - **Render service** `ai.chat_block_render` (`ChatBlockRenderService::renderBlocks(array $blocks, array $context): array`): for each block, picks the highest-weight plugin whose `applies()` returns TRUE, falling back to the default renderer for the block's type; skips blocks whose `annotations.audience` excludes `user`. - **Default renderers** in `src/Plugin/ChatBlockRenderer/`: - `TextBlockRenderer` — runs the text through a configurable text format (filtered, never raw). - `ImageBlockRenderer` / `AudioBlockRenderer` — data-URI or managed-file rendering with mime validation. - `ResourceLinkRenderer` — a link with `name`/`title`/`description`. - `EmbeddedResourceRenderer` — text resources filtered; blob resources as download affordance. - `EntityCardRenderer` — resolves `entity:` URIs (using the `_meta['drupal.org/ai.entity']` view-mode hint from `ContentBlock::entityCard()`), loads the entity, and renders via the entity view builder — **enforcing entity access with the current user and attaching full cacheability metadata** (entity cache tags/contexts bubble into the chat render). Inaccessible entities render as nothing, not as a leak. Every render array carries proper `#cache` metadata; the service documents that consumers embedding results in cached responses must bubble it. **Tests:** kernel tests per default renderer, including the access-denied and cacheability assertions on `EntityCardRenderer`; a unit test for plugin selection order (weight + `applies()`). ### Backwards compatibility Wholly new plugin type and service; no existing behavior touched. **Consumer integration note:** frontends that want server-rendered blocks call `ai.chat_block_render` and ship the resulting markup; block-aware frontends may ignore this service entirely and consume raw block JSON. Both are valid per the contract in the structured-response child issue. ### AI Assistance Yes, AI was used to explore the codebase and draft this issue.