A tool node carries two names: the node-type label the editor stamps into `data.label` at creation, and the author's per-instance override in the reserved config key `instanceTitle` (with `instanceDescription` beside it). `NodeMetadataResolver::injectReservedConfigProperties()` injects both into every node's config schema — "Override the default node title for this instance." / "Override the default description for this instance." — and the editor's node components resolve display as `config.instanceTitle || data.label` and `config.instanceDescription || metadata.description`. `ToolProjector` reads neither. An author who renames a tool node and writes it a description in the config panel sees that text on the canvas, and the model is told the node type's name and the plugin's description instead. Found on `dev-2.x` `4561e3b8`. ## Where it drops `modules/flowdrop_runtime/src/Service/Runtime/ToolProjector.php:116-128` — the only place a model-facing tool definition is built: ```php $label = $node->getLabel() !== "" ? $node->getLabel() : $toolNodeId; // data.label — the type label [$pluginDescription, $schema] = $this->describe($node, $graph); // $processor->getDescription() $description = implode(" — ", array_filter([$label, $pluginDescription])); $bindings[] = new ToolBinding( ToolName::fromLabel($label), $toolNodeId, $description, $schema, sprintf("%s (%s)", $label, $toolNodeId), $invoker, ); ``` `$node->getConfig()` is consulted in `describe()` only to narrow the parameter schema (`ToolParameterScope::fillableNames()`); neither reserved key is read anywhere on this path. From there it is a straight passthrough with no second chance to inject: `ToolBinding::toDefinition()` → `ToolCollection::toDefinitions()` → `ReasonRequest` tools → provider. So all three model- and operator-facing strings — `name`, `description`, `displayTitle` — come from type-level text, and both instance overrides are lost. `instanceDescription` in particular is read by nothing in PHP: the only runtime reader of either constant is `NodeRuntimeService.php:771`, which reads `INSTANCE_TITLE` for the confirmation-gate prompt label. ## Why it matters Tool name and description are the model's entire basis for choosing between wired tools. Two `HTTP Request` nodes — one hitting a CRM, one a search index — project as the same slug from the same type label, and the author's whole disambiguation ("Look up a customer by email") is the field being discarded. Naming a tool for the job it does in *this* workflow is the normal way to make an agent pick correctly, and today it silently has no effect on the wire. ## Second site that has to move with it `modules/flowdrop_runtime/src/Service/Compiler/WorkflowCompiler.php:348-351` derives the tool name the same way for the compile-time collision check: ```php $label = ($toolNode !== NULL && $toolNode->getLabel() !== "") ? $toolNode->getLabel() : $toolId; $name = ToolName::fromLabel($label); ``` Fixing `ToolProjector` alone would leave two tools whose `instanceTitle`s slug-collide passing validation and reaching the model as duplicate names — exactly what this check exists to prevent. Conversely, two nodes sharing a type label but given distinct instance titles are rejected today as a collision that no longer exists once names come from the instance. `ScopedToolInvoker.php:315` uses `getLabel()` for the log/trace label; cosmetic, but it should agree with the other two. ## Proposed fix One resolver, three call sites: - `DependencyNode::getDisplayTitle()` — `config[ReservedName::INSTANCE_TITLE]` when a non-empty string, else `getLabel()`, else the node id. Used by `ToolProjector` (name + `displayTitle`), `WorkflowCompiler::validateToolWiring()`, and `ScopedToolInvoker`. - Description: `config[ReservedName::INSTANCE_DESCRIPTION]` when non-empty, used **instead of** the `label — pluginDescription` composite (an author-written override replaces type text, matching what the editor shows), falling back to today's composite otherwise. ## Author-visible change A workflow whose tool nodes carry an `instanceTitle` will send different tool names to the model after this lands. That is the point of the fix, but it is a behaviour change for any prompt that names a tool literally, and for a compile-time collision that only existed because instance titles were ignored. ## Docs `docs/development/tool-aware-node-processors.md` ("Tool names") documents the name as a slug of the node label; it needs the instance title mentioned as the source that wins.