AI Guides

Notes on giving an LLM write access to a personal site — what a minimum viable MCP server looks like, how to design tools the model will actually use correctly, and the operational quirks I wish I'd known earlier.

MCP Self-Hosting Series

A 6-part walk through the patterns that worked: server shape, tool design, safety rails, day-to-day workflow, and the postmortem of six months running it.

  1. AI Part 1: Why I Gave Claude Write Access to My Site

    A year ago I would have called this irresponsible. Today an MCP server lets Claude write to my site. The trust model isn't "I trust the model" — it's "I trust the blast radius".

  2. AI Part 2: The Minimum Viable MCP Server

    A personal MCP server is a tiny HTTP service. The spec accommodates a lot of complexity that, if you're the only user, you can stop building. Here's the inventory of what I have running, and what I deliberately left out.

  3. AI Part 3: Designing Tools for an LLM, Not for Yourself

    The verb in the tool name is the most important part. Descriptions answer the questions a chooser asks, not the questions a maintainer asks. Allowlists fail closed; blocklists fail open. Error messages are also instructions.

  4. AI Part 4: Safety Rails — Allowlists, Atomic Writes, Audit Logs, Rollback

    About two hundred lines of code, none of them clever, all of them the reason I sleep fine with the service running. Allowlists, atomic writes, an audit log, and a manual rollback path.

  5. AI Part 5: Prompt-Driven Authoring in Practice

    What's it actually like to use? The honest answer, including where the loop is tight, where it's still clumsy, and the three things I'd warn anyone trying this.

  6. AI Part 6: Connector Quirks, Cache Traps, and What I'd Do Differently

    Six months in. The cache layer you don't see, OAuth refresh edge cases, and the short list of decisions I'd make differently if I were doing this again from scratch.