## Problem/Motivation `InputDefinitionRefinerInterface` lets a tool rebuild an input definition once dependency values arrive, and today nothing constrains what the refined definition may be. But the schema invokers advertise (e.g. what the MCP bridge bakes into `tools/list`) is built from the _unrefined_ definition and is static — refinement can never reach it. Strict invokers validate arguments against that advertisement before the tool is reached. That means refinement is only coherent when the refined definition accepts a **subset** of what the advertisement accepts. A refiner that changes the data type or the multiplicity makes the two shapes disagree: values that pass the invoker's schema gate fail refined validation, and values the refined definition wants are rejected at the gate and can never arrive. This is not hypothetical — `tool_belt:field_set_value` refined its `value` input's multiplicity from the field's cardinality, which made multi-value fields unusable over MCP until it was reworked to a stable shape (tool_belt issue 3616141). Refinement is also order-sensitive (coercion behaves per the definition in effect when a value is set), so shape-changing refiners produce different behavior depending on argument order. Nothing currently stops the next tool from reintroducing this defect class. ## Steps to reproduce 1. Implement `InputDefinitionRefinerInterface` on a tool whose refiner returns a definition with a different data type (e.g. `string` → `integer`) or flipped multiplicity for the target input. 2. Advertise the tool through an invoker that validates against the unrefined schema (the MCP bridge). 3. Set the dependency input, then attempt to supply a value for the refined target. ## Expected behavior Shape-changing refinement is rejected loudly as a developer error at refinement time, so it is caught in the tool's own tests. Narrowing refinement — adding constraints, declaring properties on a free map, supplying a list item definition, refining `any` to a concrete type, narrowing an entity type to a sub-type — continues to work. ## Actual behavior Any refined definition is accepted silently. The advertised and accepted shapes diverge, and callers hit unexplainable gate rejections or validation failures depending on which side of the mismatch they land on. ## Proposed Resolution Adopt and enforce the narrowing contract: **the unrefined definition is the upper bound; a refined definition must accept a subset of what it accepts.** - Document the contract on `InputDefinitionRefinerInterface`. - Enforce it where refiners are applied (`TypedInputsTrait::setInputValue()`): after `refineInputDefinition()` returns, throw a `LogicException` naming the input when the data type changed or the multiplicity flipped. Two narrowing type changes are permitted: `any` → any concrete type (an untyped schema accepts every value, so any refinement is a subset — verified against the MCP SDK's own schema validator), and entity prefix narrowing (`entity` → `entity:node`). - Emit an untyped schema for `any` on the legacy (pre-11.1) normalizer path, whose string fallback otherwise advertises a false upper bound; the 11.1+ path already emits one. (Landed under #3583001, where the schema matrix pins both paths.) - Test coverage: a `tool_test` fixture tool whose refiners exercise each branch — forbidden type change, forbidden multiplicity change, permitted `any` narrowing (including that the concrete type applies to validation and coercion only), permitted entity sub-type narrowing — plus a regression asserting constraint-only refiners are unaffected. All existing refiners in tool, tool_belt, and the bridge fixtures were audited and comply: they add constraints (`FieldExists`, `EntityBundleExists`, `Choice`, `Count`) or declare properties on free maps. Enforcement is therefore safe to introduce without a deprecation cycle. Constraint additions remain allowed even though they can reject gate-valid values: they fail as _named violations_ with the refined schema echoed back, which is the correction loop working as designed, and runtime-dependent constraints (bundle lists, cardinality) cannot be known statically. ### AI usage (if applicable) * [x] AI Assisted Issue: This issue was generated with AI assistance, but was reviewed and refined by the creator. * [x] AI Assisted Code: This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision. * [x] 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.