The deprecation register is not askable over MCP

docir doctor | jq '.compat' carries every surface this build will stop accepting and the date each stops (A breaking change is announced with a date, by doctor). Over MCP there is no way to ask. The store-format half reached docir_store_status, because those are facts about a store and that tool already answers those; the deprecation register did not, because it is a fact about the build.

Why the obvious placement does not work¶

MCP as a second transport over the dispatcher makes every MCP tool one Request through the dispatcher — one tool per dispatcher command, never a second implementation. There is no doctor command there: most of what doctor reports is about the client process, and the MCP server runs in the daemon, so docir doctor — one report for every way docir is subtly wrong deliberately left it out.

The register is not like the rest of doctor. It reads no environment and no process — it is a constant in the package plus today's date, and both are as true in the daemon as in the shell. It is the one part of that report the existing argument does not cover.

Who it costs¶

The reader the announcement was written for. An agent driving docir over MCP holds only the installed package, never opens a changelog, and is exactly the caller that would otherwise script around a flag due to stop working — which is the whole case A breaking change is announced with a date, by doctor makes for putting a date on it.

What a fix has to decide¶

Whether a dispatcher command may answer a question about the build rather than about a store. Adding compat there gives both transports one implementation and settles it; putting the register in docir_store_status instead would answer it faster and quietly make that tool about two things.

What shipped¶

deprecations is a dispatcher command, so docir_deprecations is one Request like every other tool — the shape MCP as a second transport over the dispatcher requires, rather than a second implementation beside doctor's. Verified over real stdio against this store: 23 tools listed, the register returned with its replacement and sunset.

The rule that let a command answer about the build rather than a store is A dispatcher command may answer about the build, when place cannot change the answer: it may, when running somewhere else cannot change the answer. The register is a constant in the package plus today's date, which reads the same in the daemon as in the shell — unlike the rest of docir doctor, which is about the client process and stays out.

Not folded into docir_store_status, which would have been quicker and would have made one tool about a store and about the build reading it.

describe_deprecations shapes the payload once, so doctor's compat section and the command cannot disagree about a field name. doctor still reads the register directly rather than dispatching, because it has to answer while the store is unopenable — a split between transports, not between answers.