The MCP surface cannot say what build the service is: expose the informational version (and the running rung) on an existing read #3453

Nothing on the Darling MCP surface says what build the service is. get_store_metrics carries size and growth, get_collection_health carries alert_read_health.counting_since (the process's own start, because the counts are in-memory), and the instructions header carries a tool count — but the one question an operator or an agent watching an install actually asks, "is the running service the build that carries fix X", has no direct read. The assembly knows (AssemblyInformationalVersionAttribute, which the CLI's version command already prints); the MCP surface does not repeat it.

The workarounds measure the wrong thing or measure it by inference:

• counting_since moving proves a RESTART, not a new build — a crash-restart reads identically to an install.
• Capability fingerprints (the instructions' tool count, a settings key appearing in get_alert_settings) identify a build only when the change in question happens to move a fingerprintable surface, and reading them means knowing tonight's merge list — which is exactly the state an external watcher does not have.
• The nightly version work (Nightly version strings are date-only, so same-day builds from different trees are indistinguishable (operator-facing, low) #3390) made build strings distinguishable; it did not make them readable from here.

The ask is small: the service's informational version (and plausibly the running schema rung beside it, since StorageVersion.SchemaVersion is the compiled expectation and the store's migrated rung is the other half of "what is actually running") on some existing read — get_collection_health's response already carries the process-scoped alert_read_health block, so a service block beside it (version string, process start, compiled schema rung) would put all three facts on the surface that already answers "is this thing healthy". No new tool, no census move beyond the response shape.

Motivating case, scrubbed: two delivery fixes merged the same night an agent was measuring delivery behavior on a production store. Attribution required knowing which build produced each burst, and the agent's only options were restart inference plus a merge-list lookup it had no way to perform. A version field turns that into one read.