Two gaps, same shape. The model is great at reasoning over whatever lands in its context, and useless at the part where context actually comes from.

So I built UCP — Universal Context Pipeline. A single Rust binary that indexes folders on my machine, then exposes them to any MCP client (Claude Desktop, Cursor, LM Studio, Zed, Continue, custom agents) as one tool: search_local_context. No cloud, no telemetry, no per-page-view API calls.

What it actually is

UCP is a local-first MCP server. You point it at folders — notes, code, exported Claude conversations, PDFs — and it builds a hybrid index on disk. When an MCP client launches it, the client sees exactly one new tool, and the LLM running in that client can call it whenever it needs grounding.

The retrieval underneath is the unglamorous part that quietly matters:

• BM25 via SQLite FTS5 for exact terms (function names, error strings, that one weird acronym).
• Vector search via sqlite-vec for intent (“the thing that retries webhooks with exponential backoff”).
• Reciprocal-rank fusion to merge the two — neither alone is good enough; together they handle both shapes of query.
• Tree-sitter chunking for Rust / Python / TS-JS, heading-aware chunking for Markdown, sentence-bounded fallback for everything else.
• Content-hash embedding cache. Re-index a folder where nothing changed and zero embedding calls are made.

Everything lives in one SQLite file. The whole thing is one binary on your PATH.

The design call I keep defending: one tool, not ten

Most “context for LLMs” tools expose a constellation of MCP tools — read_notes, search_code, find_conversations, list_pdfs, and so on. I went the other way. UCP exposes exactly one tool to the model: search_local_context(query, folder_filter?, limit?).

The reason is empirical, not philosophical. Agents have to choose a tool to call, and tool choice gets worse — sometimes much worse — as you add more tools that overlap in meaning. “Should I search_code or read_notes for this question?” is the kind of decision an LLM can faceplant on, and it’s the kind of decision the retriever should be making anyway, because it’s the one with the index in front of it.

So UCP collapses the decision: the model asks one question in natural language, the retriever decides whether to lean on BM25 or vectors or both, the model gets snippets with citations back. There’s nothing for the agent to get wrong because there’s nothing to choose.

The cost is that the tool description has to do real work — it has to tell the model when calling it is appropriate and when it isn’t. That’s a writing problem, not a protocol problem, and I’d rather solve it once in a docstring than push it into the model’s tool-routing every turn.

Why local-first, beyond the obvious

The privacy story writes itself — lawyers, clinicians, defense, anyone with an NDA, anyone who simply doesn’t want their notes leaving the laptop. Pair UCP with a local model in LM Studio or Ollama and the whole stack — indexing, embeddings, retrieval, chat model — runs offline. Works on a plane. Works in an air-gapped facility. Works when the WiFi at the café decides today is not the day.

But the part I didn’t expect was that local-first is what makes the conversation-memory feature work at all. Exporting your Claude history and uploading it to a third-party “memory” service is a non-starter for most people — it’s the most intimate corpus you have. Doing it locally turns it from an awkward sell into a one-liner: ucp-local ingest-conversations ~/Downloads/claude-export/conversations.json. From that point on, every future Claude (or Cursor, or LM Studio) session can search every prior one. The thing that was missing the day I started building this — Claude remembering what we already worked through — became a search_local_context call.

The bit I’m quietly happy with

The content-hash embedding cache. Embeddings are the expensive step — they hit Ollama, they take real wall-time, and the typical edit-a-file-and-re-index workflow re-touches a lot of chunks whose content hasn’t actually changed. So every chunk is hashed; the hash is the cache key; on re-index, only chunks with a new hash hit the embedding model. The watcher (ucp-local watch) leans on this — you edit a file, the index updates in ~500ms because 99% of the chunks were already embedded last time.

It’s a small thing. It also turns “re-index my big notes folder” from a coffee break into a beat.

The part that actually hurt

PDFs. Specifically, PDFs whose body fonts don’t ship a ToUnicode CMap.

The Rust pdf-extract crate is fine for most things, but on a particular shape of PDF — usually papers and corporate exports — it’ll happily pull out the headings and lose the entire body. The text isn’t missing from the file; it’s just encoded in a way the extractor can’t map back to characters without the CMap. You only notice when you query the index for a phrase you know is in the document and get nothing back.

The fix wasn’t writing a better PDF parser (that way lies madness). It was admitting that pdftotext from Poppler already solves this and giving UCP a graceful fallback: try pdf-extract first, detect the “headings only, body missing” failure mode, fall back to pdftotext if it’s on PATH. Poppler is now a documented optional dependency that I quietly recommend everyone install.

The lesson, again, was the unglamorous one: the hard part of grounding an LLM in your own files isn’t the model or the embeddings or the retrieval algorithm. It’s the long tail of file formats refusing to give up their text.

How you can try it

Three commands on macOS, then a four-line MCP config:

brew install ollama poppler
ollama serve &
ollama pull nomic-embed-text
cargo install ucp-local
ucp-local index ~/Documents/notes ~/code/my-project

Then add UCP to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "ucp-local": { "command": "/full/path/to/ucp-local", "args": ["serve"] }
  }
}

Restart Claude Desktop. Ask it something grounded in your indexed folders. The reply will cite the files.

If you want the conversation-memory unlock too, export your Claude history from claude.ai/settings/data-privacy-controls and run ucp-local ingest-conversations ~/Downloads/claude-export/conversations.json. Every future Claude session now has access to every past one. That, more than anything else UCP does, is the part I didn’t realise I wanted until I had it.

The full README, MCP configs for Cursor and LM Studio, and the positioning doc are all on GitHub. v0.1 is on crates.io as ucp-local.

Then my own work stopped being Android-only.

Try it in your browser: the WASM build of the sample app is live at akshay2211.github.io/DrawBox/sample — no install, just draw.

The honest reason for the rewrite

Nobody filed a “please port to iOS” issue. The push was personal: my day-to-day moved into Kotlin Multiplatform across Android, iOS, Web and Desktop, and it started feeling silly that my own drawing library was the one thing I couldn’t reuse. A stroke is a stroke. An undo entry is an undo entry. The geometry, the serialization, the gesture interpretation — none of it has anything to do with Android specifically.

So the question stopped being should this be multiplatform and became why is it still not.

The refactor commit landed in late May 2026. The library is now DrawBox 2.0, shipped as a Compose Multiplatform artifact with Android, iOS, JVM/Desktop and WASM targets from one shared source set.

What actually lives in commonMain

Almost everything. The shared module is split the way you’d expect if you’ve done this before:

• domain/model — State, Intent, Event, Element, Geometry, Viewport, Serialization, BackgroundPattern
• domain/usecase — SvgExporter, the rest of the use cases
• presentation/viewmodel — DrawBoxController
• presentation/reducer — one Reducer.kt, about 250 lines, where every state transition happens

The platform source sets — androidMain, iosMain, jvmMain, wasmJsMain — are thin. They exist to bridge things the Kotlin stdlib won’t give you cross-platform: file IO, share sheets, the few graphics primitives that still differ. The drawing logic itself doesn’t know what platform it’s on.

The part that actually hurt

This is the section the rewrite earned. Going from Android-only to KMP was the easy framing. The real work was rewriting the whole thing around MVI and a single immutable state.

The original DrawBox was a controller with mutable state — perfectly fine on one platform. Compose Multiplatform rewards a different model: one State data class, an Intent sealed type for every user action, a Reducer that takes (State, Intent) and returns the next State. Clean once it’s done. Painful while you’re getting there, because every feature has to be re-expressed as an intent and a reducer case. Pen-down, shape resize, eraser hit-test, viewport zoom, history step, JSON load — all of it funnels through the same 250 lines.

The payoff was the bit I underestimated:

• Undo/redo is basically free. History is just a stack of State. The reducer doesn’t have to know it exists.
• Serialization is free. If State is @Serializable, then JSON import/export is mostly already done.
• Replay is free. The sample app has a replay screen because the architecture allowed it, not because I planned one.
• Platforms can’t drift. WASM, iOS, Android and Desktop call the same reducer on the same state. If the eraser behaves differently on one of them, it’s a rendering bug, not a logic bug — and the bug surface shrinks accordingly.

What it cost was the willingness to put the library on pause and rebuild features I’d already shipped, with no new user-visible win until the very end.

What snuck in once the model was clean

Once everything was an Element in a State, adding features got noticeably cheap. The KMP branch picked up a lot more than just new targets:

• SVG export and JSON import/export
• Infinite canvas with zoom and pan
• Shape selection, drag and scale
• Connectors between shapes
• Stroke style and corner radius options
• A tileable SVG background pattern with optional tint
• An object eraser tool (replaces pan in the controls bar)
• Roborazzi for visual regression tests

Most of these would have been awkward in the old architecture. In the new one, they’re a few lines in the reducer and an entry on the toolbar — and they ship on every platform at once. There’s also a live WASM sample now, which has done more for “try it before you adopt it” than any README screenshot ever did.

Would I do it again

Yes, but I’d stop pretending the migration paid off on merge day. It didn’t. It paid off over the weeks after, when each new feature was small, symmetric across platforms, and didn’t need a per-target branch.

If you maintain an Android-only library and your own work has quietly moved into KMP, the library is going to follow whether you plan for it or not. Better to do it deliberately than to let it slowly stop reflecting how you actually build things now.

So I built statsvg_rs: a single Rust program that renders GitHub stats cards as SVG, with enough knobs that one tool can produce a header-heavy profile card and a stripped-down lifetime-stats card from the same code.

What it actually makes

There are two presets, and the difference is the whole point.

profile.svg is the card you drop into a project README, where the reader doesn’t know who you are yet. It leans on identity: avatar, bio, location, a row of last-year stats, a contribution grid, top languages, and pinned repos.

stats.svg is what I call the anti-profile. It’s meant for your profile README — the username/username repo — where your avatar and bio are already sitting right above it. So it drops all of that and instead shows the things GitHub tends to hide: lifetime contributions since you joined, your longest streak, all-time stars and commits, the top repos you’ve contributed to but don’t own, and your single most-starred project as a highlight.

Both are driven by the same flags. Width, theme (github_dark, nord, dracula, light, solarized), which sections to show or hide, how many pinned repos, an optional highlight line. If you want a profile card with no contribution grid, that’s one flag. If you want the lifetime variant but with the header back on, that’s one flag too. That flexibility is the feature I couldn’t find anywhere else.

How it works

The flow is short and boring in a good way, which is what I wanted.

1. Fetch. One GraphQL query to GitHub pulls the user, their repos, languages, contribution calendar, pinned items, and contributed-to repos. The lifetime variant fires a few extra queries — more on that below.
2. Compute. From that raw data it derives the numbers: total stars and forks, language percentages by bytes of code, current and longest streak from the calendar, and the last ~18 weeks of the contribution grid.
3. Render. It builds the SVG as a plain string, section by section, top to bottom. There’s no templating engine and no headless browser — just a small builder that keeps a running vertical cursor and writes one section after another.

A couple of details I’m quietly happy with. The avatar is fetched and base64-embedded directly into the SVG, so the card is fully self-contained — no external image request when someone loads it. And themes are just plain Rust structs; adding a new one is a constant declaration and a single line to register it, no config format to invent.

For the lifetime numbers there’s a wrinkle worth calling out. GitHub’s API only gives you contribution totals for a date range, not a true “since the beginning of time” number. So to get a real lifetime total, statsvg_rs asks for each year from your join date to now — one query per year — and sums them. The per-year requests fan out concurrently so it stays fast even for an account that’s been around a decade.

How I deploy it, and why

Here’s the part I went back and forth on. The project can run as a live HTTP server — there’s an axum server mode and a Dockerfile — but I don’t deploy it that way. I render to static files instead.

A GitHub Action runs on a schedule (every six hours), builds the binary, renders both profile.svg and stats.svg, generates a tiny landing page, and publishes the whole thing to GitHub Pages. The cards you embed are just static files sitting on a CDN.

I picked this for two plain reasons:

• There’s nothing to keep alive. No server to pay for, monitor, or restart at 2am. A scheduled job either runs or it doesn’t, and if it doesn’t, the last good card is still sitting there.
• It’s faster and more reliable for whoever’s looking at it. A static SVG from a CDN always loads instantly. A live server has cold starts, can go down, and gets hit on every single README view — which is exactly how the shared instances of other stats tools end up rate-limited and broken.

Rendering on a schedule means GitHub’s API gets called a handful of times a day on my terms, not once per page view by every visitor. The server mode still earns its keep, though — it’s how I iterate on layout locally. cargo run, hit localhost:3000 with different query params, and watch the card change without waiting on a full render-and-deploy cycle.

How you can use it

If you want your own copy, it’s a fork-and-edit job:

1. Fork the repo.
2. Open .github/workflows/render.yml and set STATSVG_USER to your GitHub login (and a theme/width if you like).
3. Turn on GitHub Pages with the source set to GitHub Actions.
4. Push. Your cards publish to https://<you>.github.io/<repo>/profile.svg and /stats.svg.

If you want private-repo data counted, generate a classic token with repo scope and add it as a repo secret — otherwise it just uses public data. Then embed whichever card fits where you’re putting it.

That last part is how I run it myself: the stats card lives on my profile README at akshay2211/akshay2211, and the profile card sits in the README of my DrawBox project. Same tool, two genuinely different cards, each tuned for where it’s shown.

What was actually hard

Honestly? Not much fought me. The mechanics — GraphQL, the SVG building, the Actions pipeline — mostly just worked once they were wired up. The real work wasn’t debugging, it was deciding: what belongs on a profile card versus a stats card, what’s noise, what GitHub already shows the viewer so I shouldn’t repeat it. The anti-profile idea came out of that question, not out of any technical struggle.

The few things I had to design around rather than fight were all just realities of the platform. Lifetime totals needing a query per year, as mentioned. GitHub’s image proxy caching embedded SVGs, which is part of why re-rendering every six hours (rather than chasing real-time) is the right cadence — and why there’s a ?v= cache-bust trick in the README for when you want a card refreshed immediately. And the layout being hand-tracked rather than handed to a layout engine, which is more arithmetic but also means there’s no surprise dependency between me and the pixels.

If you’ve got a wall of mismatched cards on your profile and you’ve ever wished one of them did something slightly different, that’s the itch this scratches. The code is on GitHub — fork it, point it at your username, and make it show what you actually want.

That kind of change is easier to review, easier to test, and easier to explain. It also keeps momentum healthy because every release has a visible reason to exist.

Start with the user path

Before touching implementation details, I like to ask one simple question: what should become easier after this change?

If the answer is clear, the scope usually becomes clear too. A useful improvement should remove friction from a real path rather than add surface area just because the system can support it.

Keep the code honest

Small changes still deserve care. The implementation should match the existing shape of the codebase, avoid surprising abstractions, and leave the next change easier than this one.

When the code and the user path point in the same direction, shipping becomes less noisy.