varunchoraria-mcp

This lets an AI assistant read varunchoraria.com directly, as it exists right now, instead of guessing at it from training data.

Connect it once and you can ask Claude or Cursor things like "what has Varun written about AI-first go-to-market" and get an answer based on the actual essays, quoted and linked, including one published this morning.

claude mcp add --transport http varunchoraria https://varunchoraria-mcpvercelapp.vercel.app

For Claude Desktop, Cursor, or Codex, add that same URL to your mcpServers config.

What problem this solves

Ask any chatbot about a personal website and you get a confident, vague answer. Models are trained up to a cutoff date, they don't index small sites deeply, and they don't know what you published last week. So they improvise.

MCP is an open standard that fixes this by letting an AI ask a website for its content directly, in the moment, rather than recalling it. This repo is one small server that does that for my site.

How it works, in plain terms

Think of it as a menu rather than a photocopy.

Every time I publish something, my site regenerates one file listing every essay and page it has, with the full text. This server reads that file when an AI asks it a question. It doesn't keep its own copy of my writing, doesn't crawl anything, and has nothing to keep in sync.

Two consequences worth knowing:

It updates itself. Publishing is the update. A new post is readable by any connected AI within about five minutes, and no one has to remember to run anything.

It can't quietly go blind. The risk with a setup like this isn't going stale, it's a new page silently getting left out: visible to humans, invisible to AI, and nobody notices for months. So the site's build process compares its own sitemap against that file and refuses to deploy if anything public is missing or empty. If you can open a page in a browser, an AI can read it.

If the site is ever down, the server keeps serving the last good copy rather than throwing an error.

What an AI can do with it

Tool	In plain terms
get_site_info	Who this is, what they write about, how to get in touch
list_posts	Every essay, newest first
get_post	Read one essay in full
list_pages	Every page: about, work, projects, tag archives
get_page	Read one page in full
search	Find where something is discussed, with the relevant passage

Names are forgiving. michealangelo, side-quests/michealangelo, and the full URL all find the same page.

Changelog

2.1.0 — 29 July 2026

The version that made "it updates itself" actually true rather than mostly true.

• Fixed: pages that couldn't be read. The home page, the blog index, and all thirteen tag archives were returning nothing at all. An AI could see they existed but couldn't open them. They now return their introduction plus everything they link to.
• Fixed: unusable page names. Addresses were being mangled, so /tags/ai/ became tagsai and the home page had no name at all. Names now match the URL, and full URLs work too.
• Better search. It used to return anything containing your word, in no particular order. Results are now ranked, and each one includes the passage where the match appears, so an AI can judge relevance before opening anything. Tag archives were briefly drowning out the essays they point at, which is now corrected.
• Bio comes from the site. It used to be typed into this server by hand, so it went out of date the moment anything changed. It now reads from the site itself.
• Survives an outage. If the site is unreachable, the last good copy is served instead of an error.
• A health check. Visiting the server URL in a browser now reports what it can currently see and when the site was last published.
• New pages are included automatically. Previously each page had to be individually marked as AI-readable, which is exactly the kind of step people forget. Everything public is now included by default, and the build fails if that ever stops being true.

2.0.0 — June 2026

First working version. Six tools, reading from the site's published feed.

Running your own

It's a single file, api/mcp.js, deployed on Vercel. No build step, no dependencies, no database.

npx vercel dev     # run locally
npx vercel --prod  # deploy

To point it at a different site, change FEED_URL and publish an equivalent feed: { generated, site, posts: [...], pages: [...] }, where each entry has title, slug, url, and content. The Jekyll template that generates mine is api/site.json, and the build check that keeps it honest is check-built-site.rb.

MIT licensed. Take it, strip out what you don't need.