Found while investigating a paywalled-book fetch on a subscribing network; splitting it out because it is a distribution problem, not a source problem.
What was running
| where |
version |
date |
MCP server actually serving an agent session — %LOCALAPPDATA%\Programs\doiget\doiget.exe, the scripts/install.ps1 default destination (install.ps1:25) |
0.8.9 |
binary dated 2026-08-25 |
CLI on PATH |
0.8.12 |
|
next |
0.8.13-beta.23 |
|
The agent-facing binary was four releases behind, and nothing in the session said so.
It was not cosmetic
doiget_resolve_paper on 10.1017/CBO9780511813467.006 (a closed CUP book chapter whose only Crossref link[] entry is intended-application: "similarity-checking"):
0.8.9 "oa_url": "https://www.cambridge.org/core/services/aop-cambridge-core/content/view/7FCF854BE4B7BD006C95BB0E2BBAA209"
0.8.12 "oa_url": null
That is the #517 / ADR-0052 fix — the one whose stated purpose is to stop handing a caller a Similarity Check URL under the name oa_url. It shipped, and the agent path kept handing it out for another four releases. The failure mode the fix exists to prevent was live in the only place that consumes oa_url programmatically.
Reproduced by driving both binaries directly over stdio JSON-RPC (initialize, notifications/initialized, tools/call doiget_resolve_paper), same env, same store root.
Why it was invisible
doiget_health returns { ok, version, schema_version, store_writable } (doiget-mcp/src/lib.rs:159). The version is reported with nothing to compare it against, so an agent reading 0.8.9 has no way to know that is old — and neither does the user, since the MCP config names a path, not a version.
install.ps1 installs. There is no upgrade path, no record of what it installed, and no re-run prompt.
Asks
- A staleness signal the agent can act on. Cheapest honest version:
doiget_health (and capabilities) reports the version alongside the release channel it came from, and the installer leaves a manifest next to the binary. A network check for the latest release is the fuller version and needs its own decision, since it adds a call nobody asked for.
- An upgrade path in
install.sh / install.ps1 — re-run should detect and replace, and say what it replaced.
- Worth deciding whether the
.mcpb bundle has the same problem, since a Desktop Extension is installed once and updated never unless something updates it.
Refs #501, #517, #513.
Found while investigating a paywalled-book fetch on a subscribing network; splitting it out because it is a distribution problem, not a source problem.
What was running
%LOCALAPPDATA%\Programs\doiget\doiget.exe, thescripts/install.ps1default destination (install.ps1:25)PATHnextThe agent-facing binary was four releases behind, and nothing in the session said so.
It was not cosmetic
doiget_resolve_paperon10.1017/CBO9780511813467.006(a closed CUP book chapter whose only Crossreflink[]entry isintended-application: "similarity-checking"):That is the #517 / ADR-0052 fix — the one whose stated purpose is to stop handing a caller a Similarity Check URL under the name
oa_url. It shipped, and the agent path kept handing it out for another four releases. The failure mode the fix exists to prevent was live in the only place that consumesoa_urlprogrammatically.Reproduced by driving both binaries directly over stdio JSON-RPC (
initialize,notifications/initialized,tools/call doiget_resolve_paper), same env, same store root.Why it was invisible
doiget_healthreturns{ ok, version, schema_version, store_writable }(doiget-mcp/src/lib.rs:159). The version is reported with nothing to compare it against, so an agent reading0.8.9has no way to know that is old — and neither does the user, since the MCP config names a path, not a version.install.ps1installs. There is no upgrade path, no record of what it installed, and no re-run prompt.Asks
doiget_health(andcapabilities) reports the version alongside the release channel it came from, and the installer leaves a manifest next to the binary. A network check for the latest release is the fuller version and needs its own decision, since it adds a call nobody asked for.install.sh/install.ps1— re-run should detect and replace, and say what it replaced..mcpbbundle has the same problem, since a Desktop Extension is installed once and updated never unless something updates it.Refs #501, #517, #513.