DEV Community: Pranab Sarkar

Twelve Green CI Legs, One Dead SSE Server

Pranab Sarkar — Thu, 03 Sep 2026 15:05:38 +0000

The official mcp Python SDK went to 2.0.0 and deleted mcp.server.fastmcp outright. No shim, no deprecation window that downstream packages got to see. yantrikdb-mcp is a thin MCP server over YantrikDB, my persistent cognitive memory substrate for AI agents, and at 04:08 on 2026-08-04 I did the defensive thing: v0.11.0 (d823b82) pinned mcp[cli] to <2.0.0.

A ceiling like that doesn't stop anyone from installing the package. pip resolves mcp 1.x and moves on. It bites later, in an environment where something else wants mcp>=2.0.0, because then the resolver has to pick a loser and one of the two packages isn't getting installed. That's an acceptable trade for a few hours. It's a bad thing to leave sitting in a published pyproject.toml, so I spent the morning taking it back out.

Scale matters here, because it changes how much a five-hour window costs. yantrikdb-mcp is the fastest-moving package in my download numbers at the moment: 1,688 a month when I logged it on 2026-08-24, 2,137 on 2026-08-31. Up 26.6% in a week, mostly a cluster of registry listings landing close together rather than any single event.

Probing instead of parsing

v0.12.0 (0ca6092, PR #19) shipped at 10:39, six and a half hours after the pin. One file, src/yantrikdb_mcp/_compat.py, became the single import site for every MCP SDK symbol the rest of the package touches, and it resolved them by probing rather than by reading a version string and branching on it:

# _compat.py, trimmed to the shape of the probe
try:
    from mcp.server.mcpserver import Context, MCPServer as Server
    from mcp.server.mcpserver.exceptions import ToolError
    MCP_MAJOR = 2
except ImportError:
    from mcp.server.fastmcp import Context, FastMCP as Server
    ...
    MCP_MAJOR = 1

What actually moved, found by running the suite against 2.0.0 rather than by reading a changelog: FastMCP became MCPServer, Context moved under mcp.server.mcpserver, and ToolError went one level deeper than that, to mcp.server.mcpserver.exceptions. mcp.types.ToolAnnotations stayed exactly where it was, which I would not have guessed given everything around it had shifted. The lifespan dict, request_context.lifespan_context, annotations passthrough, .run(transport=...): all identical across the major bump. Most of a breaking release wasn't breaking for this codebase, and the pin had been treating the entire API surface as suspect when only a slice of it had moved.

One divergence surfaced only by running things. mcp 2.x refuses to register a static resource whose handler declares a Context parameter, and it refuses at import time, which takes the server down before it answers a single request. yantrikdb-mcp had two of those, yantrikdb://stats and yantrikdb://health. Both now reach the engine through a process-singleton and don't ask for a Context at all.

What twelve legs bought

CI got a new axis, mcp-line, with values mcp1 and mcp2, applied across the unit and e2e suites. Twelve legs. Each leg installs its SDK pin after the package installs and then asserts the resolved major, specifically so a compat layer that quietly resolved the wrong way couldn't pass by accident and turn one leg into a duplicate of the other. 214 tests passed on mcp 1.x. 214 on mcp 2.x. The pyproject.toml ceiling went from <2.0.0 to <3.0.0, and --version started reporting the active line: yantrikdb-mcp 0.12.0 (mcp 2.x). I tagged it.

15:42

v0.12.1 went out five hours later: "fix SSE / streamable-http startup on mcp 2.x (v0.12.0 regression)."

The e2e cases, on both legs, all drove stdio. Most of the 214 are unit tests that don't exercise a transport at all. So nothing in the suite touched SSE or streamable-http, which are the two transports yantrikdb-mcp uses for shared network deployments, and v0.12.0 had broken both of them on mcp 2.x.

mcp 1.x configures a network server by mutating shared state (mcp.settings.host, mcp.settings.transport_security.enable_dns_rebinding_protection) and then reading those values back inside server.sse_app(). mcp 2.x's Settings object has no such fields. The old code kept mutating, and on 2.x it raised:

ValueError: "Settings" object has no field "host"

On 2.x those values are arguments to the app factory instead. _compat.build_network_app(server, transport, host, port) is now the only place in the package that knows the difference, and _run_network() delegates to it rather than poking settings.host itself:

# build_network_app(), condensed to the branch that matters
if MCP_MAJOR == 1:
    # 1.x reads its configuration back off the server object
    server.settings.host = host
    server.settings.transport_security.enable_dns_rebinding_protection = False
    return server.sse_app()

# 2.x: the fields don't exist, the factory takes them
return server.sse_app(host=host, transport_security=security)

The streamable-http factory goes through the same branch with a different call. Worth being precise about the failure mode: the server didn't come up misconfigured, it didn't come up. The process died before uvicorn bound a port. A stdio suite is structurally incapable of noticing, because stdio never reaches sse_app().

I found it because I went to upgrade the live SSE box I run, which sits behind bearer-token auth and depends entirely on that path, and I checked it before rolling it forward. Twelve green legs did not catch this bug. A pre-deploy check did, which is the least impressive way there is to find one.

Past the unit tests, I started a real SSE server on mcp 2.x with YANTRIKDB_API_KEY set: uvicorn bound, GET /sse returned 401 with no token and 200 with one. A new file, tests/test_network_transport_compat.py, builds the actual ASGI app for both sse and streamable-http against whichever SDK line is installed, so both legs finally walk the network path. It also carries a source-level guard against _run_network ever reverting to direct settings.host mutation, plus a tripwire assertion that the host field really is absent from Settings on 2.x, so a future 2.x release that quietly restores it fails the suite instead of letting the shim do the wrong thing on both majors at once. Counts after the fix: 218 on mcp 1.x, 219 on mcp 2.x. The asymmetric one is that tripwire, which has nothing to assert on the 1.x leg.

The part I'd argue about

Twelve felt like coverage because twelve is a bigger number than three. What I had was two dependency pins multiplied against one transport. Multiplying an axis against the same assertions doesn't buy a code path, it buys a longer CI run and a wider grid of checkmarks, and I think a great many matrices in a great many repos are built exactly that way: wide where widening is cheap, thin where the interesting failures live. Mine was, until August. Now, before I add an axis, I want to be able to name the line of code it forces the suite through. If I can't name one, the axis is decoration.

The same shape, one size down

A different gate on this repo caps how large the tools/list JSON schema is allowed to get, kept deliberately tight so it doesn't eat into a model's context budget. PR #37 merged with four red CI checks. The gate had passed locally on Python 3.13 and failed in CI on 3.10 and 3.12, because 3.10 renders a hint like str | None into a noticeably fatter anyOf block than 3.13 or 3.14 do: roughly 1,950 extra characters from identical source, against a budget with 197 characters of headroom. PR #38 clawed back 204 characters by trimming a docstring, raised the ceiling from 48,600 to 48,800, and wrote the reasoning into the test file instead of bumping the number silently. There was already a comment in that file warning about this exact interpreter quirk, left there the first time it happened.

Same shape as the SSE regression, one size down: green in the configuration I looked at, red in the one I didn't.

Three weeks later, the probe needed patching too

On 2026-08-25 I had to fix the probe itself (0e170a9, PR #35). mcp 2.1.1 reintroduced mcp.server.fastmcp alongside the canonical mcp.server.mcpserver tree. Read the code block above again: its logic is "if fastmcp imports, we're on 1.x," and on 2.1.x both trees import cleanly, so it confidently answered 1. The fix reads importlib.metadata.version('mcp') directly instead of inferring the line from which modules happen to resolve, adds a second check tying the canonical 2.x tree to MCP_MAJOR, and pins the both-trees-importable shape to 2.x in a regression test. Validated against mcp 1.29.1, 2.0.0 and 2.1.1.

So probing beat parsing right up to the point where upstream did something stranger than I'd allowed for, and the version string I'd deliberately avoided ended up being part of the answer after all.

I Made an MCP Server Stop Calling Any AI API, and It Got More Useful

Pranab Sarkar — Thu, 27 Aug 2026 14:58:41 +0000

v1.0 of brainstorm-mcp shipped with two providers wired up: OpenAI and DeepSeek. Gemini arrived later in v1.2.0 (3690f24, 2026-02-26), and groq, mistral and together are in the list too. You never needed all of them. The provider loader walks the list and skips anything whose env var is missing, so one working key is enough to run a debate.

The catch is which key. Every provider in that list belongs to somebody other than Anthropic. There is no Claude provider in the server and there never was; in API mode Claude's role is to read what the other models said and add its own take, which happens through the host rather than through a key the server holds. So if you're running Claude Code and you install brainstorm-mcp to see what a multi-model debate looks like, the number of usable keys you have is quite possibly zero. The friction was never "go collect N keys." It was "go sign up with a vendor you weren't otherwise using, before you can find out whether this tool is any good."

The inversion

v1.4.0, commit 7906fbf, 2026-03-24: "Add hosted mode for API-key-free multi-model brainstorming" (PR #1, co-authored with Claude Opus 4.6 per the commit trailer; Opus and I worked out the orchestration model together).

Hosted mode isn't a seventh provider or a free-tier proxy. In API mode the server is a caller. It holds keys, hits api.openai.com or api.deepseek.com, returns results. In hosted mode it never calls a model API. It builds the debate prompt for a given round and a given voice, then hands that prompt back to the host as tool output. Claude Code spawns sub-agents on opus, sonnet and haiku to run those prompts, using model access the host already has. Responses come back in through brainstorm_collect, which appends them to the debate and decides what round comes next.

Worth being precise about the mechanism, because it's easy to overstate. The server cannot make the host do any of that. What it returns is a prompt plus instructions, and Claude Code acts on them because acting on tool guidance is what a host does. There's no protocol-level guarantee anywhere in this. A host that ignored the instructions and dumped the prompt text at the user would leave the server sitting on a half-finished session until it timed out. The whole arrangement is cooperative, and I'd rather say so than let it sound like the server is driving.

Mode selection is automatic. If the model names you pass don't carry a provider: prefix (no openai:gpt-5.5, no deepseek:deepseek-chat), the server reads that as hosted mode and assumes you mean the host's own models. No flag, no config file, just the shape of the string.

The same commit brought context injection, so a debate can be grounded in a real diff or file instead of a topic sentence, plus the debate styles (freeform, redteam, socratic) and a synthesis format that closes every debate with Recommendation, Key Tradeoffs, Strongest Disagreement in both modes. brainstorm_respond was already there from v1.1.0 (75c8949, "Add interactive mode — Claude participates as active debater"); 7906fbf touched it by exactly one line, passing session.style through.

The design consequence I care about is what happens once the server stops calling models. It has to hold state: which round the debate is on, which voices have spoken, what's outstanding. That lives in memory with a 10-minute TTL, and calling brainstorm_collect against an expired session returns an error telling you to start a new one.

Two ways it broke, same afternoon

Both of these live in the API-mode calling path, which hosted mode's design doesn't touch. They broke a debate I was running to test hosted mode, so they're part of the same afternoon.

v1.5.6, c9e3d86, 2026-04-27, "drop temperature for gpt-5.x reasoning models." Three-round brainstorm, openai:gpt-5.5 and deepseek:deepseek-chat as the two voices. Every round-1 turn from gpt-5.5 came back as an HTTP 400:

Unsupported value: 'temperature' does not support 0.7 with this model. Only the default (1) value is supported.

The gpt-5.x family and the o-series reject any non-default temperature. deepseek-chat doesn't care what you send it, so the loop ran fine right up to the OpenAI voice, which is why testing hadn't caught it. The code already branched on model family for max_tokens vs max_completion_tokens, tracked by a useNewTokenParam flag, so the fix reused that branch and stopped sending temperature: 0.7 down it. Older gpt-4.x models still get it, since they still accept it. Rechecked against gpt-5.5-2026-04-23: 200 OK, no temperature field in the request body.

v1.5.7, 9af668b, same day, "bump per-call timeout 2m -> 5m." I shipped the temperature fix, reran the same debate, and it stalled at 120 seconds. DEFAULT_TIMEOUT_MS in src/debate.ts was hardcoded to 120_000. gpt-5.5 doing reasoning on a real brainstorm prompt (multi-thousand-word topic, six-option intervention list, redteam framing instructions on top) goes past two minutes routinely. Session 01751c60-256a-489b-88d3-9b954a3edd79, round 1, same wall on retry. One constant, 300_000, done. deepseek-chat and gpt-4.x were finishing well under two minutes and saw no change at all.

Under an hour between the two commits, which is about how long I spent believing the first one had unblocked the debate.

One thing I'm watching now: SESSION_TTL_MS is 600_000 while DEFAULT_TIMEOUT_MS is 300_000 post-fix. Two slow reasoning calls back to back inside a single round could in principle burn most of a session's life before the round finishes. I haven't hit it and I'm not certain the arithmetic works out that way in practice, but it's the next thing I'd expect to go wrong.

What the numbers say

From state/metrics-history.jsonl, npm downloads per month and GitHub stars as recorded:

Date	npm downloads/month	GitHub stars
2026-08-09	286	67
2026-08-18	345	67
2026-08-21	413	67
2026-08-24	427	67

Downloads up about 49% across those 15 days. Stars sat at 67 on every check.

I read that as a property of how this kind of tool gets installed rather than as a problem. You add brainstorm-mcp to an MCP client config and start calling brainstorm_quick. Nothing in that path requires opening the repo. Starring costs a page visit plus a small public declaration of interest; downloading costs wanting to run the thing. For a mechanical utility with a narrow use case, I'd weight the download curve over the star count.

Plenty of people will call that motivated reasoning from someone whose star count isn't moving, and four data points over two weeks isn't evidence of anything. It's four numbers. What it did change is what I bother logging.

Pranab Sarkar, Independent Researcher

The Model Reading My Benchmark Mattered More Than the Memory System Did

Pranab Sarkar — Tue, 25 Aug 2026 20:40:17 +0000

On 2026-08-11 I reran a benchmark I'd already published and changed exactly one thing: the model that reads the retrieved memory and writes the answer. Same memory system, same retrieved context, same judge, same rubric. YantrikDB's own score moved about 9 points on that swap.

Grounding, if you haven't heard of the thing being measured: YantrikDB is a persistent memory system for AI agents — it stores what happened in earlier sessions and hands the relevant parts back on demand. It makes no LLM call at ingest, which is where the 241-second ingest and 80ms retrieval numbers further down come from.

Two weeks before that rerun, Hindsight — a competing agent-memory system — had published a score on the same benchmark 25 points above mine. Nine of those 25 came from a model swap that has nothing to do with either memory architecture. More than a third of a published architectural gap, produced by changing the plumbing.

The comparison that got thrown out

The first version was the lazy one. BEAM-100K, an agent-memory benchmark, rubric-scored: YantrikDB at 0.611, Hindsight's published number at 0.862. My answerer was deepseek-v4-flash, theirs was gemini-3.1-pro-preview, and I filed that as a footnote.

Two adversarial reviews came back on it on 2026-08-11, one from a Codex-family model (gpt-5.6-sol) and one from Qwen (qwen3.8-max), both rejecting it for the same reason. An end-to-end agent-memory score has at least three things stacked inside it: how good retrieval is, whatever an ingest-time LLM does to the data on the way in, and how well the reading model uses what came back. YantrikDB and Hindsight differ in architecture. Hindsight runs an LLM fact-extraction pass at ingest and YantrikDB doesn't. The answerer models were different. Three variables moved together and I'd assigned all 25 points to the one I happen to build.

My first reaction was that this was reviewer pedantry — the reader model is plumbing, the memory system is the interesting part. Then I ran the swap to prove it, got the 9 points, and spent the next two days rewriting the paper instead.

Replaying their own context strings

Hindsight publishes, per query, the literal context string it injects into its answerer — one for a RAG configuration, one for a single-query configuration. Not a description of what its retrieval does; the string itself. So I took those strings unmodified and ran them through YantrikDB's own fixed answerer and judge: deepseek-v4-flash:0731 at temperature 0, the identical pair already scoring YantrikDB's own retrieved contexts. Nothing here calls Hindsight's live system; it's their published artifacts replayed through my scoring pipeline, so the only thing varying between rows is which memory system wrote the context.

Worth being blunt about one detail: the answerer and the judge here are the same model. deepseek-v4-flash:0731 writes the answer and then grades it, and self-grading has an obvious bias risk that I'm not going to dress up. What makes it usable is the frozen-context design — the same reader and the same judge process both systems' contexts under the same rubric, so whatever that model is inclined to reward, it rewards equally in both columns. The residual worry attaches to the absolute score level; the gap between the columns is what gets reported.

400 queries nested inside 20 conversations, all from BEAM-100K. All 400 query_ids matched across systems, so there's no partial-overlap story to explain this away.

System	Mode	Binary accuracy	Rubric score	Context tokens
YantrikDB	RAG	72.2%	0.607	13,673
Hindsight	RAG	71.5%	0.592	23,689
Hindsight	single-query	65.0%	0.563	17,655

The significance test needs a note, because the obvious test is the wrong one. Those 400 queries aren't 400 independent draws — they sit inside 20 conversations, and queries from the same conversation tend to succeed and fail together, so a per-query t-test would count 400 samples where there are really 20. The test therefore works at conversation level: flip the sign of each conversation's mean difference, enumerate every possible assignment, which with 20 conversations is 2^20 of them, a bit over a million, and p comes out at 0.438. The interval is a separate procedure — 4,000 conversation-clustered bootstrap resamples, giving [-0.021, +0.052]. A +0.015 rubric difference with an interval that comfortably straddles zero is a tie, and the paper's own word for it is "equivalent". Against Hindsight's single-query configuration the difference is +0.044, p=0.025, CI [+0.009, +0.077] — real, but single-query is the weaker of their two published configurations, so leading with it would be picking the easy target.

What did survive is cheaper than a win. YantrikDB reached that equivalent rubric score on 13,673 tokens of context against Hindsight's 23,689 — 42% fewer. The paper is careful here and I want to stay careful: part of that 42% is the cost of not carrying event time. Hindsight's contexts carry a median of 117 dates each. YantrikDB's carry a median of 5. "Not a free efficiency" is the paper's phrase, and it's the right call: that's a difference in what the two memory layers choose to emit. YantrikDB's two weakest categories in this eval are event ordering at 0.298 and temporal reasoning at 0.425. Those numbers and the token saving are one fact seen from two sides: a context with fewer dates in it is cheaper to read and worse at time.

Ingest and retrieval move the same direction, for a design reason and not a tuning one:

System	Ingest time	Retrieval (mean)	LLM call at ingest
YantrikDB	241s	80ms	none
Hindsight (RAG)	404s	2,565ms	fact extraction
Hindsight (single-query)	404s	6,379ms	fact extraction

No LLM call at ingest is the choice; 80ms against 2,565ms is what the choice buys.

The part worth stealing

Back to the 9 points, the finding I'd defend hardest. Holding retrieval completely fixed and changing only the answerer moved YantrikDB's own score by more than a third of the entire published gap between two different memory systems. The paper puts it flatly: "The published gap is therefore overwhelmingly a property of the reading model, not of the memory systems." Any end-to-end "our agent memory beats X" number that doesn't name its answerer model and its judge model isn't a comparable number, and may be describing nothing more interesting than a stronger LLM reading the same context better. That's a complaint about how the category reports results, not about Hindsight, whose habit of publishing raw context strings is the only reason this experiment was possible.

A different reader, a different answer

There's a later experiment in the same paper, and leaving it out here would be editing rather than summarising. On 2026-08-15 I ran the rag-mode 2×2 again under an equalized frontier-class reader: moonshotai/kimi-k2.6 answering, meta-llama/llama-4-maverick judging — a different reader/judge pair from the deepseek one above. On 393 paired queries, YantrikDB scored 0.6331 rubric against Hindsight RAG's 0.5982: +3.5 percentage points, bootstrap 95% CI [+0.7, +6.2]pp, excluding zero.

That doesn't overturn the tie, and I'd rather be tedious about it than let anyone read it that way. A different reader model is a different question rather than a rerun of the same one, and the RAG-vs-RAG comparison under the shared deepseek reader stays the honest headline: equivalent. What the frontier run supports is narrower — under one stronger reader, on a slightly smaller paired set, a small edge that clears its own confidence interval. It is not the sentence "YantrikDB beats Hindsight," and writing that sentence would be doing the exact thing the previous section complains about.

Wrong twice, and what's still open

The reader-model confound was the big retraction. There's a second one, smaller, the same shape. I'd had a hypothesis that Hindsight's ingest-time extraction step was quietly discarding evidence later questions needed — an information-bottleneck story, and the one result that would have made YantrikDB structurally better instead of just cheaper. Category by category against their single-query configuration, it looked real. Against their RAG configuration it mostly evaporated. The paper's line: "We are withdrawing the information-bottleneck claim as unsupported by this experiment." That paragraph took longer to write than the whole results section.

Smaller things, in no order. The results page briefly said engine version 0.14.0; the version actually installed in the benchmark's virtualenv, per dist-info at 21:05 on 2026-08-11, was 0.13.4. That number turned out to matter slightly — a 2026-08-16 rerun of the same comparison on engine 0.15.0 scored 72.5% / 0.6375 where 0.13.4 scored 71.5% / 0.6107, a +0.027 rubric delta, bootstrap CI [+0.007, +0.045], small and clear of zero. The deepseek 2×2 is incomplete: YantrikDB's contexts were never run through Hindsight's answerer, so three of the four cells exist. Context length was never controlled either, so the token-efficiency and accuracy-equivalence findings stay two claims sitting next to each other rather than one. The local harness is a fork of vectorize-io/agent-memory-benchmark, which carries no license and can't be redistributed, so the paper's "Reproduce" link points at the upstream repo.

The paper went up 2026-08-12 at yantrikdb.com/papers/beam-frozen-context/ and until this post it hadn't been anywhere but its own domain. Take the boring thing from it: when you publish agent-memory numbers, name the model that read the context and name the model that graded the answer. Without those two names the number doesn't mean much, including when the person publishing it is me.

Pranab Sarkar, Independent Researcher

Relicensing yantrikdb took 57 minutes and I got two things wrong

Pranab Sarkar — Tue, 18 Aug 2026 23:56:18 +0000

On 2026-08-18 I moved yantrikdb from AGPL-3.0 to Apache-2.0. The engine commit landed at 22:32:31 UTC. The server pull request merged at 23:29:28. Fifty-seven minutes end to end.

Almost none of that was writing. It was finding the places where the old licence had been declared and changing the declaration.

I got two of them wrong on the first pass. There is a third thing I still cannot account for.

Before you touch a file

Run this:

git log --format='%an' | sort -u

If more than one name comes back, the flip is not yours to make alone. Copyright in a contribution belongs to whoever wrote it, and relicensing the project relicenses their work too.

The engine repo is 438 commits, all mine, across a few spellings of my own name. The server repo has exactly one commit that isn't mine: PR #11, RFC 006 Phase 5, claims wire opcodes plus a new GET /v1/claims, +219/-5 across six files, merged 2026-04-18, from an outside contributor.

Why

From my own commit message: "The moat is the ecosystem — engine, server, MCP, plugin, packs, web — not the licence."

AGPL bought protection against someone standing up a hosted service on top of my work, and cost every commercial evaluation that ends at legal review. The adoption evidence says the cost is the larger number. A comparable competitor six weeks younger than yantrikdb sits at 2,608 stars against yantrikdb's 48, MIT-licensed and installable in one line. Stars are not a controlled experiment.

Apache-2.0 rather than MIT because a patent has been filed on part of this work. Apache section 3 grants patent rights explicitly, and its retaliation clause terminates the licence of anyone who sues over patents. MIT is silent on patents, which leaves an implied-licence question that corporate reviewers have to resolve themselves. That is the same friction, relocated.

Also from that commit: "This is irreversible: every version published under Apache-2.0 stays available under it permanently."

Eight files

Engine commit 4411244 touched LICENSE, a new NOTICE, README.md, pyproject.toml, crates/yantrikdb-python/pyproject.toml, and the Cargo.toml in each of yantrikdb-core, yantrikdb-python and yantrikdb-wasm.

Five manifests. Two toolchains, since both pyprojects use build-backend = "maturin". Each pyproject needed two edits rather than one, a license field and a separate trove classifier, and nothing checks that the two agree.

The README change was three lines. Two were the badge and the licence line. The third:

-The [MCP server](...) is MIT-licensed — using the engine via the MCP server does not trigger AGPL obligations on your code.
+The [MCP server](...) is MIT-licensed.

letterpress

Commit 4411244's message carved out one directory by name:

NOT included: packs/letterpress, which is AGPL-3.0-or-later and references third-party photographs under licences that require attribution. Its terms are a separate decision and are not mine to flip mechanically.

Twenty-one minutes later, at 22:53:06, commit cea13b3 flipped it anyway. Two files, packs/letterpress/README.md and packs/letterpress/pyproject.toml. The reason I gave: the pack declared license = { text = "AGPL-3.0-or-later" } in its own metadata while carrying no LICENSE file of its own, so it inherited the newly-Apache repo root and contradicted itself.

That reasoning does not answer the reason I gave twenty-one minutes earlier. The photo attribution question is about the assets. The pyproject licence field is about the code. I collapsed the two together at 17:53 local time because the contradiction was the thing in front of me. I would keep them apart if I did it again.

The server

PR #94, sixteen files. The LICENSE diff was +202/-661, Apache's text being much shorter than AGPL's. LICENSE, NOTICE, README.md, DESIGN.md, SERVER_README.md, Cargo.lock, pyproject.toml, deny.toml, four crate Cargo.tomls, four crate READMEs.

The root pyproject.toml still said AGPL-3.0-only after the first commit at 22:45:23. I caught it 36 seconds later and fixed it in SHA 96053e10. Live package metadata that would have published an AGPL classifier sitting under an Apache LICENSE file.

I opened it as a PR, and said so in the body, "so the required status checks run". Seven jobs ran: format, clippy, supply-chain, chaos-gate, and build-and-test on ubuntu, macos and windows. All seven passed on the second run. Then I went and checked: GET /repos/yantrikos/yantrikdb-server/branches/main/protection returns 404, "Branch not protected". The repo's only ruleset is called "default", with enforcement: disabled. Zero required checks. Nothing would have stopped a red merge. I open PRs out of habit, and the habit is what caught the next problem.

cargo-deny

The allow list in deny.toml had this entry, and I deleted it:

"AGPL-3.0-only",       # our own license

The comment above the list went from "Our own code is AGPL-3.0." to "Our own code is Apache-2.0."

CI run 32194878789 started at 22:54:53 on SHA 96053e10. The supply-chain job runs cargo deny check licenses bans sources. Output:

error[rejected]: failed to satisfy license requirements
  ┌─ /home/runner/.cargo/git/checkouts/yantrikdb-1317bbf12f5451d8/42dad7f/crates/yantrikdb-core/Cargo.toml:5:12
  │
5 │ license = "AGPL-3.0-only"
  │            ━━━━━━━━━━━━━
  │            │
  │            rejected: license is not explicitly allowed
  │
  ├ AGPL-3.0-only - GNU Affero General Public License v3.0 only:
  ├   - OSI approved
  ├   - FSF Free/Libre
  ├   - Copyleft
  ├ yantrikdb v0.15.3
    └── yantrikdb-server v0.16.1

Then bans ok, licenses FAILED, sources ok, and Process completed with exit code 4.

Read the file path in that error. .cargo/git/checkouts/. The server does not pull the engine from a registry at all. Line 35 of crates/yantrikdb-server/Cargo.toml, on the failing SHA, was:

yantrikdb = { version = "0.15.3", git = "https://github.com/yantrikos/yantrikdb.git", tag = "v0.15.3" }

42dad7f is the commit that tag v0.15.3 pointed at, the last one before the relicense. cargo-deny read the licence straight out of that git checkout. crates.io was never in the server's dependency path.

The unblock was a tag, not a config edit. Engine commit 473b7ae at 23:03:14, "release: v0.15.4 — Apache-2.0 relicense + embedder-identity guard", carries tag v0.15.4. Then line 35 moved:

yantrikdb = { version = "0.15.4", git = "https://github.com/yantrikos/yantrikdb.git", tag = "v0.15.4" }

That landed as server SHA 2d770017 at 23:13:12, and CI run 32196261107 started 28 seconds after it. A new run on a new head SHA, not a re-run of the failed one.

There was another way. cargo-deny supports [licenses.exceptions], and I could have scoped an AGPL exception to our own crate and left the allow list intact. I didn't. An exception would have held the gate green while the tree was genuinely mixed, and telling me the tree is mixed is the whole job of the gate. Deleting the entry made the build fail for a true reason.

You can disagree with that.

What the registries know

None of that involved crates.io, but crates.io matters for a separate reason: a registry only learns your licence changed when you cut a release. crates.io still serves yantrikdb 0.15.3 as AGPL-3.0-only, published 2026-08-18T05:04:17Z. 0.15.4 at 23:11:19Z is the first Apache-2.0 one. Every version before it stays AGPL on crates.io permanently, for everyone who pins one.

PyPI got there first, by about a minute. Wheels uploaded 23:10:13 through 23:10:25, carrying the classifier License :: OSI Approved :: Apache Software License.

Where else the licence lived

yantrikdb-mcp's README has a competitor comparison table. The License row read:

| License | MIT (engine AGPL-3.0) | Apache 2.0 | Apache 2.0 | Apache 2.0 | MIT |

Three of the four alternatives Apache, one MIT, our own cell qualifying itself. A shorter table higher up the same file had | **License** | MIT (engine: AGPL-3.0) |. CONTRIBUTING.md there has a License section naming the engine's licence too.

Then the GitHub repo description, which is a string in GitHub's database that never touches git. The engine's already said Apache-2.0. The server's still read "Rust, AGPL, ships as library / MCP server / HTTP cluster" after PR #94 merged. I found it while writing this, in the same hour, and fixed it with gh repo edit yantrikos/yantrikdb-server --description "...".

One concrete unblock: yantrikdb-mcp was being held back from the Docker MCP Registry, which takes permissive licences only. It is eligible now.

The engine repo had 48 stars at the time of the commit and has 50 now. There is no data yet on whether any of this worked and there won't be for a while.

The linter

scripts/consistency_check.py is 108 lines and runs twice a day. Its file mtime is 23:06Z on 2026-08-18, which is to say I wrote it in the middle of all this. Its docstring lists the motivating examples: "yantrikdb-mcp's comparison table said AGPL after the Apache relicense", and "PyPI classifiers contradicting the repo LICENSE".

It queries PyPI and npm. There is no crates.io code path in it, so it could not catch a crates.io licence mismatch. For repo descriptions it checks that one exists, not what it says. Both holes are mine and I know they are there.

The one I left alone

docs/papers/ still says AGPL. Section 13.3 of skill-substrate-experience-report-v4.md reads, in full:

YantrikDB is AGPL-3.0. Non-trivial barrier for proprietary commercial adoption; appropriate for research-and-substrate positioning. Dual licensing on inquiry. I do not present AGPL as an unambiguous advantage.

That text exists at two paths, one a Zenodo bundle. It is dated and published. Rewriting it to match tonight would make it wrong about the day it carries. The repo keeps a CORRECTIONS.md, and that is where this goes.

The lockfile

Here is the part I have not worked out. The Cargo.lock sitting on the server's main branch right now records:

name = "yantrikdb"
version = "0.15.3"
source = "git+https://github.com/yantrikos/yantrikdb.git?tag=v0.15.4#42dad7f19c0b7b43b54e1af1c5c492a5c4ad10ef"

Tag v0.15.4 points at 473b7ae. 42dad7f is the pre-relicense commit. The lockfile names the new tag against the old commit and still calls it 0.15.3. That same lockfile was on the SHA where all seven checks went green, cargo-deny included. I noticed it while writing this and I have not chased it.

Pranab Sarkar, Independent Researcher. Building yantrikdb, saga-mcp, brainstorm-mcp, and icantmarket.com.

My Agent Runs My Marketing (I Mostly Just Hit Approve)

Pranab Sarkar — Thu, 13 Aug 2026 15:08:13 +0000

I have 16 open-source projects, 15,386 downloads per month across PyPI and npm, and no ability to make myself post on forums consistently. I've known this about myself for years. So on 2026-08-09, I built a system to do the parts I won't do.

Here's what actually happened in the first four days.

The setup

The system lives in a folder called c:\Users\sync\codes\marketing. A PLAYBOOK.md holds the voice rules and guardrails. A routines/ folder has markdown files that each describe one agent prompt. A state/ folder of JSON and markdown files coordinates between routines. And a Python stdlib server at localhost:8781 handles the one thing that still needs a human.

The routines run on cron via Claude Code headless. weekly-metrics on Mondays. registry-sweep, repo-seo, and content-writer weekly. opportunity-scout daily (bumped from twice a week on launch day because Hacker News threads go cold in hours). issue-responder at 7:26am and 7:26pm.

The important architectural decision is the tier split. Tier 1 is fully autonomous: MCP registries, directory listings, repo SEO, release notes, dev.to articles. The system writes, reviews through a multi-stage pipeline, and publishes without asking me. The article you're reading went through that pipeline.

Tier 2 is draft-only, always. Hacker News, Reddit, X. The system writes ready-to-paste drafts, queues them in state/drafts/, and stops. The portal (scripts/portal.py) parses each draft file by splitting on a --- separator -- metadata above, paste-ready body below -- extracts a "Reply to:" URL via regex, and serves it at localhost:8781 with Copy, Open, and Archive buttons. Archiving moves the file to state/drafts/archive/. That's the whole approval flow. It takes about 10 seconds.

The reason Tier 2 exists is written into the system's own docs: "Those platforms shadowban automated self-promotion and the reputational downside is permanent." The PLAYBOOK.md voice rules reinforce it from the other direction: "Never fake community enthusiasm, never astroturf, never post the same text to two places." I'm not planning to graduate Tier 2 channels to full autonomy. The communities that make HN and Reddit worth posting to are the ones that will correctly identify and punish automated engagement. That 10-second friction is doing real work.

There's also an owned channel -- bothn.com, my platform for agents. The autopilot has a disclosed agent account (yantrikos-autopilot). It posts as itself, not as me.

The first registry sweep

The first sweep ran on 2026-08-09 and hit a mix of successes and walls.

It opened PRs on punkpeye/awesome-mcp-servers (#11771) and tolkonepiu/best-of-mcp-servers (#349 and #350). It submitted yantrikdb-mcp and saga-mcp to mcp.directory via web form, with screenshot receipts saved to state/logs/. It found mcpserverfinder.com, which only accepts submissions by email, and sent one from yantrikdb@gmail.com.

Then the dead ends.

appcypher/awesome-mcp-servers -- archived and read-only. The target list had stale data; the repo hasn't accepted PRs in months. A branch was prepared, then deleted unopened.

mcphunt.com -- parked domain, for sale. Not a live directory.

wong2/awesome-mcp-servers -- the README states: "We do not accept PRs. Please submit your MCP on the website: https://mcpservers.org/submit" The automation checked the README before opening anything and stopped.

smithery.ai -- needs my GitHub login, and the browser automation profile's session was dead. The system logged "NO SESSION" and fell back to drafts.

docker/mcp-registry -- requires my GitHub identity per the run instructions. Skipped entirely; no session check attempted, just a note in submissions.json and it moved on.

A safety rail in PLAYBOOK.md caps outbound PRs: "Max 3 outbound PRs to third-party repos per sweep (avoid looking like a bot wave)." The sweep opened 3 PRs (two to tolkonepiu, one to punkpeye) and stopped there.

The autopilot also posted a summary of this run to bothn.com (post #99, from yantrikos-autopilot). It reported the actual results: 8 answered issues, what it counted as 4 listing submissions, one new directory discovered and submitted to. Then it asked other agents where they'd found agent-native distribution channels.

What broke

The day after launch, the dashboard showed portfolio PyPI downloads had dropped from 14,389/month to 130. Overnight. That's the number in state/metrics-history.jsonl, line 2 -- it's still there.

Here's what scripts/collect_metrics.py actually does: it loops over portfolio.json projects, calling pypistats.org/api/packages/{package}/recent and api.npmjs.org/downloads/point/last-month/{package} for each one. When a call fails, the handler runs print(f" warn: {url} -> {e}", file=sys.stderr) and returns None. The package is silently excluded from the sum. No retry. No alert. The totals line just sums whatever succeeded.

So on 2026-08-10, most PyPI calls apparently failed -- probably a pypistats.org outage, possibly rate limiting -- and the dashboard reported 130 downloads/month because that's what the one successful call returned (yantrikdb-client, 130 downloads). The error went to stderr and nowhere else. I didn't notice for twenty minutes, and even then only because the number looked absurd on the dashboard. A more insidious failure -- say, 30% of packages failing instead of 95% -- would have produced a plausible-looking number and I wouldn't have caught it at all.

The obvious fix: compare against the previous snapshot's total, flag anything that drops more than 40% as suspicious before recording it. I haven't written that yet.

The Bun runtime also hard-crashed twice -- during the opportunity-scout on 2026-08-11 at 18:13, and during the issue-responder this morning at 07:26. Bun v1.3.10, Windows x64, identical panic both times: panic(main thread): switch on corrupt value / "Bun has crashed. This indicates a bug in Bun, not your code." Different routines, different days. Haven't filed the bug report yet.

Baseline numbers

As of 2026-08-09: 15,386 downloads/month (14,389 PyPI + 997 npm), 483 GitHub stars across roughly 16 tracked projects. yantrikdb-hermes-plugin pulls 1,831 downloads/month -- second-biggest PyPI package in the portfolio -- without a single announcement. It's a pluggable memory provider inside NousResearch/hermes-agent, and people find it there. No launch post, no marketing. That data point is why the next phase focuses on embedding into frameworks rather than posting into voids.

90-day targets (set 2026-08-09, target 2026-11-07): downloads to 31,000/month, stars to 800, live directory listings from 9 to 16+, and 12 dev.to articles published. This is article #1 -- the content-log.json articles array was empty before this run.

The longer-term executor is meant to be yantrik-mind, my own agent stack running on a home server, not Claude Code headless. Migration is one routine at a time, risk order, once shadow runs match production for four consecutive weeks. No routine has graduated yet. The shadow metrics run fires Mondays at 08:20 and its diffs land in state/shadow-diff.md.

This system is what icantmarket.com is meant to be for other technical founders who built something real and can't make themselves promote it. Full automation where the platforms accept it. A 10-second interface where they don't.

I built the system on its own portfolio first because I didn't want to sell it before I knew where it breaks. Now I know some of the places.

Pranab Sarkar, Independent Researcher. Building yantrikdb, saga-mcp, brainstorm-mcp, and icantmarket.com.

I Gave Claude Code a "Phone a Friend" Lifeline — It Calls GPT, Gemini, and DeepSeek

Pranab Sarkar — Thu, 05 Mar 2026 21:05:56 +0000

Last week Claude Code was stuck on an architecture decision. Instead of going back and forth with one model, I thought — what if it could phone a friend? Or three?

So I built brainstorm-mcp, an MCP server that gives your coding agent a brainstorming team. Claude poses the question, GPT-5, Gemini, DeepSeek, and others each bring their perspective, then they build on each other's ideas across multiple rounds. A synthesizer distills everything into a consolidated recommendation.

It's not about picking a winner — it's about getting perspectives you'd never get from a single model.

How it works

You give it a topic: "Design the architecture for a next-gen AI-powered code review tool"
All models respond independently in Round 1 — diverse, unbiased first takes
In Round 2, they see each other's ideas and build on them, challenge assumptions, or offer alternatives
A synthesizer distills the best ideas into a final recommendation

Claude participates as a brainstormer with full context of your codebase, so the discussion is grounded in your actual code — not abstract advice.

Real example: AI code review architecture

I asked three models to design an AI-powered code review tool that goes beyond linting. Here's what each one brought to the table:

GPT-5.2 went deep on systems architecture — a full Temporal-orchestrated pipeline with a Repo Knowledge Graph, multi-pass LLM review (intent inference → local correctness → architectural reasoning → team alignment), and a feedback loop that learns from accepted/rejected suggestions. Detailed tech stack: Tree-sitter for parsing, Neo4j for the graph layer, OPA for policy-as-code.

DeepSeek focused on the data flow and learning loop — how the system should ingest PRs, build context packs from the dependency neighborhood, and gradually learn team conventions. Simpler architecture, but pragmatic choices about what to build first vs. defer.

Claude (with codebase context from my actual project) grounded the discussion — pointed out which components I already had, where existing CI pipelines could be reused, and which parts of the architecture were overkill for my scale.

The synthesis combined GPT's comprehensive systems design with DeepSeek's pragmatic sequencing and Claude's "here's what you actually need right now" reality check. 2 rounds, 75 seconds, ~11k tokens, $0.07.

Full debate output

What surprised me

Each model has a genuine personality. GPT goes wide and comprehensive — you'll get a 6-section architecture doc. DeepSeek favors elegant simplicity. Claude with codebase context catches things the others miss entirely. The value isn't in any single response — it's in the combination.

Round 2 is where the magic happens. Round 1 gives you breadth — independent first takes. But Round 2, where models first see each other's thinking and decide what to build on or challenge, is where the most creative solutions emerge.

Cheaper than you'd think. A full debate costs $0.02-0.07. Less than a single complex prompt to a reasoning model, but you get 3x the perspectives refined over multiple rounds.

Local models add real value. Running Llama via Ollama alongside cloud models adds diversity. They think differently — less polished but more willing to suggest unconventional approaches.

Setup

It's an MCP server, so if you use Claude Code, Claude Desktop, or any MCP client:

npx brainstorm-mcp

Add your API keys and you're done. Works with OpenAI, Gemini, DeepSeek, Groq, Ollama, Mistral — anything with an OpenAI-compatible API.

One more thing

While building brainstorm-mcp, I kept losing track of decisions and tasks across sessions. Claude would forget what we'd discussed yesterday. So I built saga-mcp — a Jira-like project tracker that runs as an MCP server. SQLite-backed, 31 tools, full hierarchy from Projects down to Subtasks. One tracker_dashboard call gives your AI agent full context to pick up where it left off.

Both are free, open source, MIT licensed.

brainstorm-mcp: GitHub | npm

saga-mcp: GitHub | npm

Why AI Agents Keep Forgetting Your Project (And How I Fixed It)

Pranab Sarkar — Mon, 23 Feb 2026 00:36:47 +0000

Every time I start a new session with an AI coding agent, the same thing happens: it has no idea what I was working on yesterday.

It doesn't know which tasks are done. It doesn't know we decided to use Redis for caching. It doesn't remember that the auth module is blocked waiting on a dependency upgrade. It just... starts fresh.

So I'd do what most people do — maintain a PROGRESS.md file. After every session, I'd ask the agent to update it. And at the start of the next session, the agent would read the file and try to pick up where it left off.

This worked fine for about a week.

The Markdown Problem

As the project grew, so did the file. 50 lines became 200. Status updates from three weeks ago sat next to current blockers. The agent would read the whole thing, burn 3,000+ tokens on context, and still miss that one task I'd marked as blocked because it was buried between two old progress notes.

The fundamental issue: I was using a text file as a database.

I needed queries ("what's blocked?"), not full-file reads. I needed structure (projects → epics → tasks), not flat bullet points. And I needed an audit trail that wouldn't bloat the context window.

Building a Project Tracker for AI Agents

So I built one. Saga is an MCP server that gives AI agents a local SQLite database for project tracking — think Jira, but designed for the way agents actually work.

If you're not familiar with MCP (Model Context Protocol) — it's a standard from Anthropic that lets AI tools talk to external services through typed tool calls. Claude Code, Claude Desktop, Cursor, and Windsurf all support it. Your agent discovers available tools at startup and calls them as needed during conversation.

Saga exposes 23 tools through MCP:

CRUD for a full hierarchy: Projects → Epics → Tasks → Subtasks
A notes system: For decisions, context, meeting notes, blockers — all typed and searchable
A dashboard: One call returns your entire project status — completion percentages, blocked tasks, recent activity
An activity log: Every change is automatically recorded with old/new values
A session diff: "Show me what changed since yesterday" — in one call

Everything lives in a single .tracker.db SQLite file. No servers, no API keys, no accounts.

How It Actually Works

Here's what a typical session looks like now.

Starting a new project:

Me: "Set up tracking for the e-commerce API"

Agent calls: tracker_init → epic_create (Auth) → epic_create (Catalog)
           → task_create (JWT auth) → subtask_create ([setup lib, create endpoint, add middleware])

Five tool calls. Project is structured with epics, tasks, and subtasks. All persisted to SQLite.

Resuming the next day:

Me: "What's the status?"

Agent calls: tracker_dashboard

One call. Returns:

{
  "stats": { "total_tasks": 12, "tasks_done": 4, "tasks_blocked": 1, "completion_pct": 33.3 },
  "blocked_tasks": [{ "title": "Add rate limiting", "epic": "Authentication" }],
  "recent_activity": ["Task 'JWT auth' status: in_progress → done", ...]
}

The agent immediately knows: 33% done, one task is blocked, auth epic is ahead of catalog. It can prioritize without me having to explain anything.

Recording a decision:

Me: "We're going with Redis for caching. Mark the research tasks as done."

Agent calls: note_save (decision: Redis for caching, reasons, trade-offs)
           → task_batch_update (mark tasks 8, 9 as done)

The decision is stored as a typed note, linked to the relevant epic. Next session, if the agent needs to understand why we chose Redis, it can search for it instead of me re-explaining.

The Token Math

This is the part that surprised me.

Saga's 23 tool definitions cost about 1,500 tokens in the system prompt. That's fixed — it doesn't grow with your project.

A tracker_dashboard call returns ~800 tokens of structured data. A filtered query like "show me blocked tasks" returns ~200 tokens.

Compare that to a PROGRESS.md file for a medium project: 3,000–5,000 tokens, loaded in full every session, growing over time.

The crossover happens at about 15–20 tasks. Beyond that, the structured approach scales better because the agent only retrieves what it asks for, not everything.

And unlike a markdown file, the data is queryable. "What did we decide about caching?" is a note_search call, not a full-file scan.

What's Under the Hood

For the technically curious:

SQLite with WAL mode — concurrent reads during writes, busy timeout of 5 seconds for lock contention
Foreign keys enforced — no orphaned tasks when you delete an epic (cascading deletes)
Append-only activity log — every create, update, and delete is recorded with field-level granularity
Parameterized queries with column allowlists — no SQL injection surface
MCP safety annotations on every tool — clients know which tools are read-only, destructive, or idempotent

The whole thing is ~1,400 lines of TypeScript. Two dependencies: the MCP SDK and better-sqlite3.

Session Diff: The Feature I Didn't Plan

After launching, someone on Reddit asked: "Can it show what changed between sessions?"

Good idea. The activity log already captured everything — it just needed an aggregation layer.

So I added tracker_session_diff. You give it a timestamp, and it returns:

{
  "total_changes": 14,
  "summary": { "created": 3, "status_changed": 4, "updated": 5, "deleted": 2 },
  "highlights": [
    "Task 'Fix auth bug' status: in_progress → done",
    "Created epic 'API v2'",
    "Note 'Sprint retro' deleted"
  ]
}

An agent calling this at the start of a session gets a structured changelog of everything that happened since it last checked. No parsing markdown diffs. No re-reading files.

Getting Started

Add this to your project's .mcp.json:

{
  "mcpServers": {
    "saga": {
      "command": "npx",
      "args": ["-y", "saga-mcp"],
      "env": {
        "DB_PATH": "/absolute/path/to/your/project/.tracker.db"
      }
    }
  }
}

That's it. Works with Claude Code, Claude Desktop, or any MCP-compatible client. The database file is created automatically on first use.

What I Learned

Building Saga taught me something about how agents actually consume information: they're better with structure than with prose.

A markdown file is optimized for humans scanning a document. A typed tool call returning filtered JSON is optimized for an LLM deciding what to do next. The agent doesn't need to "read" your project status — it needs to query it.

MCP makes this practical. The protocol handles tool discovery, typed schemas, and transport. All I had to do was put a database behind it.

If you're building multi-session agent workflows and finding yourself maintaining growing context files, consider whether that context should be a database instead.

Saga is open-source (MIT) and available on npm:

GitHub: https://github.com/spranab/saga-mcp
Install: npx -y saga-mcp