Radius

Bookmarks are a bet on your future self that usually loses. What you get back is a flat list with no real search and no way to see how anything relates to anything else.

Radius makes that corpus queryable — you ask an agent what have I saved about X and get an answer grounded in your own data, not the open web.

Radius never scripts a login and never stores a password, which has a deliberate consequence: it ships no exporter. You bring the JSON from whatever tool already holds your session, and ingestion takes it from there.

Rows are upserted by id into real relational tables — authors, posts, media — so re-running over an overlapping export is idempotent and safe on a schedule.

Storage is one Turso (libSQL) database, read by your laptop and your deployment alike, so there is nothing to keep in step between the two.

Two retrieval modes sit on top of it: SQLite FTS5 for exact lexical matching, and RapidFuzz similarity for the queries where you half-remember the wording. Writes only ever happen locally from the ingestion job; the served process opens the database read-only.

The server speaks streamable-HTTP MCP via FastMCP and exposes two tools — fetch_bookmarks and whoami. Neither is meant to be called by hand: you ask a client in plain language, and it picks the tool and fills the arguments.

Tokens are RS256 JWTs signed by a locally generated key pair and verified against a published JWKS, so nothing about an issued token is stored server-side — it carries an expiry and a scope, and that is all.

Authorization is per-tool: a token opens only what it was minted for. An unauthenticated call to the MCP endpoint gets a 401 with a WWW-Authenticate challenge; only /health is public.

The whole server deploys as a single Python function on Vercel, or runs locally behind a CLI — keys init, migrate, ingest, token issue, serve. Leaving the Turso URL unset falls back to a local file, which is what offline work and the test suite use.