SERVER_VERSION

const SERVER_VERSION: string

What this build reports in the MCP handshake, and in the startup banner.

Read from the installed package.json at load, never written here (spec 791-content-mcp-version-reporting). It used to be the literal '0.1.0', under a comment claiming the build kept it in step with package.json. The build does no such thing: publish-packages.yml stamps the version with npm version and never touches source, so every published build announced 0.1.0 — and that number is exactly what a reporter needs when two agent processes disagree about which tools exist, which is the situation it was useless in. content_topology is the newest tool, so a stale build has the other eight and not it; scopes cannot produce that, since the five read tools share one registration block.

Why not a generated constant, following scripts/bundleHelp.mjs, which is the obvious shape: the publish workflow runs npm version after npm run build, so a prebuild stamp would bake the committed 0.0.0-dev placeholder into every release — the same symptom with a different wrong number. Reading at runtime is immune to that ordering, because it reads the file npm version actually wrote. Reordering the workflow would work too, and is worse: it is deliberately package-agnostic and shared by four packages, so a change made to suit this one has three other consumers and no test.

../package.json resolves correctly from both places this module ever runs — dist/server.js in a published install, and src/server.ts under vitest — which is why the path needs no build configuration and no conditional.