saga-mcp is my MCP server for project tracking. SQLite-backed projects, epics, tasks and subtasks, so a coding agent doesn't lose the plan the moment a session ends. It's on npm as saga-mcp. On 2026-09-04 at 14:29 I was doing something unglamorous with it: filing a submission to the Cline MCP marketplace (github.com/cline/mcp-marketplace/issues/2435). The form wants a tool count, and I had the README open to copy one out of.
At that exact commit (698ef81, which was HEAD when I filed) the README said three things. Line 15, the intro paragraph: "exposed as 35 MCP tools." Line 79, a feature bullet: "35 focused tools." Then line 138, buried in the environment-variable reference table, SAGA_TOOLS set to full (the default) "lists all 33 tools," and core "lists only the 12 an ordinary tracking session needs."
Two of those agreed with each other and the third didn't, which is exactly the smell that makes you stop reading documentation and go measure the thing. So I did. I pointed a client at the published package with SAGA_TOOLS set to full and then to core, and both runs came back with 22 tools.
22 matched nothing in the README. I read that as confirmation the file had rotted, put 22 in the marketplace submission as the verified count, noted that rewriting the README was outside the scope of a registry-submission task, and moved on.
What was actually running that day
Writing this up today, I went back and nailed it down properly instead of from memory. The method is one line and anyone can rerun it: pipe a raw MCP stdio handshake, a JSON-RPC initialize followed by tools/list, into npx -y saga-mcp@<version> with DB_PATH pointed at a scratch file, and count what comes back in the response.
The version genuinely live on 2026-09-04 was saga-mcp@1.8.0, published the day before. It returns exactly 35 tools.
So the README's two prominent claims, the ones a reader actually sees, were correct. The stale number was the buried one in the env-var table, 33 and 12, left behind by a couple of releases. My "verified" 22 was further from the truth than the documentation I'd distrusted.
I did eventually find where 22 lives. saga-mcp@1.1.0 and saga-mcp@1.2.0, both published 2026-02-21, each return exactly 22 tools, and both ignore SAGA_TOOLS completely: full and core give you the same 22. That's the fingerprint I saw and misread. Getting the same count twice regardless of the env var looked to me like "the env var is broken too," and it actually meant "you are talking to a package from six months ago."
How a same-day test landed on a February build, I don't know. A stale npx cache is the obvious guess. A globally installed copy shadowing the npx resolve is the other one. I haven't managed to reproduce either, and I'd rather leave it sitting there unexplained than pick whichever story sounds tidiest.
What bothers me isn't the 22 itself. It's that the wrong number sat in a public marketplace submission for four days, and the reason nobody caught it, including me, is that I had measured it myself. Distrusting the docs and going to the source is the right instinct and I'd do it again. It only helps if you also check what you measured. I never got as far as asking which package had answered me.
The fix that did land
The README work I'd deferred shipped four days later: commit 3dd5df5, 2026-09-08 19:18:58 -0500, "Rewrite the README, and test the claims it makes (#51)," co-authored by Claude Opus 5 per the commit trailer. 849 lines touched in the README itself (changed, not final size) plus a new 189-line test/readme.test.js. From the commit message:
The file had grown by accretion across a dozen releases and was wrong in several places a reader would act on... It claimed ~140 tests when there are 298, and quoted the tool surface as ~6,000 tokens dropping to ~2,700 when the measured figures are ~7,200 and ~2,900... Verified by reintroducing seven kinds of drift that had genuinely been in the file — a stale tool count, a stale test count, a renamed tool, a stale version in the release example, a broken anchor, a stale tab count — and confirming eight tests fail.
It says seven kinds of drift and then lists six. A commit about fixing counting errors, undercounting its own list of counting errors. I laughed, then left it in.
test/readme.test.js checks, programmatically: every real tool is documented and vice versa; the advertised tool counts match what the running server reports; the SAGA_TOOLS=core list matches what the code actually restricts to; the tab list matches the web UI's own tabs; quoted test and e2e counts are current; the release example names the current version; no example calls a tool that doesn't exist; every anchor link resolves. The file's own doc-comment puts the motivation plainly: "The README drifts. It claimed ~140 tests when there were 298, quoted a tool surface two releases out of date, and documented sorting behaviour that had since changed — all of it written in good faith and then left behind by the code."
Two days later
Two days is not a long time to trust a new test, so I reran the handshake against npx -y saga-mcp@latest. It resolved to 1.16.0 and printed:
Tracker MCP Server running on stdio (41 of 41 tools listed)
The current README claims 41. The CORE_TOOLS set in source has also grown from 12 entries to 13, with a new tool called tracker_next (essentially a "what should I work on" query), and the rewritten SAGA_TOOLS table says 13. That's precisely the kind of edit that used to silently desync the count.
The download number I don't trust
Separately, the metrics I run across my packages flagged saga-mcp: npm downloads went from 321/month on 2026-08-31 to 1,808/month on 2026-09-07, a 463% jump, with no new registry listings going live that week and GitHub stars flat at 33 across the whole window. It got logged as unverified, watch if it holds.
The daily numbers for 2026-09-01 through 09-10 are 5, 190, 0, 485, 73, 775, 0, 0, 83, 0. My own publish counts for the same days are 0, 1, 2, 5, 0, 5, 0, 2, 0, 0.
The two biggest download days, 485 on 09-04 and 775 on 09-06, are the two days I shipped five releases each. That fits neatly enough that I wanted it to be the whole answer. It isn't: 09-03 and 09-08 each carried two releases and recorded zero downloads. If publishing reliably drove the counter, those days would show something.
My read, and this is where a reasonable person could land somewhere else: a curve that spikes on my busiest publish days and flatlines in between is more likely measuring registry mirrors and dependency scanners refetching new versions than it is measuring people installing the thing. The counter-examples mean I can't prove that, and I'm not claiming the correlation is clean. I am claiming that "up 463%" does not belong in a scorecard on its own, which is inconvenient, because it's a very nice number and nobody would stop me from using it.
The README test now fails the build when the docs and the running code disagree, which is a real improvement over remembering to update things. It would not have caught the 22. Nothing in that suite, or in my head on 2026-09-04, checks whether the process answering me is the process I think I'm talking to.
Pranab Sarkar, Independent Researcher
Top comments (0)