### Problem/Motivation `drush tool:info <id> --format=json` flattens every input and output to its data type: ```json "variant": {"type": "string", "required": true, "multiple": false, "locked": false}, "props": {"type": "map", "required": false, "multiple": false, "locked": false} ``` A consumer reading that cannot tell that `variant` accepts only `info|success|warning`, or which keys `props` takes. `ToolInfoCommand::outputInfoAsJson()` builds the arrays by hand and never calls `tool.definition_serializer`, so the constraints, map properties, list items, formats, and bounds that `ContextDefinitionNormalizer` already emits (#3582972) stop at the MCP bridge and the AI connector. The CLI is the one invoker that still cannot see them. Item 1 of https://git.drupalcode.org/project/tool/-/work_items/3582943. Blocks #3583012, whose "inspect before running" step points agents at this command. ### Proposed resolution **Add a Drush invoker.** `ToolDefinitionSerializer` normalizes a `ToolInterface` instance, not a definition, because `ToolDefinitionNormalizeEvent` subscribers key on the invoker. The Drush commands pass no invoker today; `ToolRunCommand` calls `createInstance($tool_id)` bare. ```php namespace Drupal\tool\Drush; final class DrushInvoker { public const string ID = 'drush'; public static function create(): Invoker { return new Invoker(self::ID); } } ``` No capabilities. A one-shot process has no handle continuity, so `EntitiesAsHandles` stays off; #3582977 adds it together with the workflow-only filter. `tool:run`, `tool:info`, and any command that instantiates a tool pass `DrushInvoker::create()`. **Emit the schema from `tool:info --format=json`.** Inject `tool.definition_serializer`, instantiate the tool with the Drush invoker, and add two keys: ```php $tool = $this->toolManager->createInstance($tool_id, [], DrushInvoker::create()); $data['input_schema'] = $this->serializer->normalizeInputSchema($tool, include_locked: TRUE); $data['output_schema'] = $this->serializer->normalizeOutputDefinitions($tool); ``` Keep the flat `inputs` and `outputs` keys. #3583012 and downstream skills read `required`, `multiple`, and `locked` from them, and the schema does not carry `locked`. The serializer service is `@?serializer`, and Tool does not depend on `serialization`. When the module is absent, `ToolDefinitionSerializer` throws `LogicException`. `tool:info` catches nothing and emits nothing extra in that case: omit both keys and print a one-line notice on stderr, so the JSON stays parseable. **Table and markdown output.** Add a `Constraints` column to the input table: `enum` values joined with `|`, `minimum`/`maximum`, `format`, `pattern`. Render map properties as indented rows under the parent input. Same source (the normalized schema), so the human formats cannot drift from the JSON. **Tests.** Extend `ToolInfoCommandTest` with `serialization` in `$modules` and assert against `schema_matrix_tool`, which already declares `Choice` and `AllowedValues` inputs, plus a map input tool from `tool_test`. Assert `enum` and `properties` appear in `input_schema`, that `inputs` is unchanged, and that a run without `serialization` still exits 0 with valid JSON. ### Alternatives considered - **Replace `inputs`/`outputs` with the schema.** Drops `locked`, breaks the documented shape that #3583012 relies on, and forces every consumer to change on a beta release for no gain. - **Emit a Drupal-native array instead of JSON Schema.** The original #3582943 proposal. Withdrawn: Tool already ships the JSON Schema normalizer and `mcp_server_tool_bridge` consumes it, so a second format would be a parallel model with no consumer. - **Reuse the AI connector or MCP bridge invoker.** Both declare `EntitiesAsHandles`, which would make `tool:info` advertise handle-string inputs that `tool:run` cannot resolve. ### API changes `DrushInvoker` is new and `@internal` to the Drush layer. `tool:info --format=json` gains `input_schema` and `output_schema`; existing keys are unchanged. ### 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.