I Fed Brewfather's API to Claude and Built My Own MCP Server
Last updated: 06.04.2026
I Fed Brewfather's API to Claude and Built My Own MCP Server
Audio Narration
Brewfather is a comprehensive app for homebrewers that manages recipe design, batch tracking, fermentation logs, water chemistry, and ingredient inventory, making it a central hub for homebrew recipes. An MCP (Model Context Protocol) server acts like a plugin that exposes local tools and data to an AI such as Claude, letting it call a locally run server without any cloud intermediary or custom UI. Using Brewfather’s REST API, the author fed the documentation to Claude and quickly generated a local MCP server that connects Brewfather to Claude Code. This setup enables three key capabilities: browsing and inspecting real Brewfather recipes, checking the brew schedule and batch stages, and verifying whether the ingredient inventory is sufficient for an upcoming brew day. The main benefit is turning brewing data into a conversational interface, so users can simply ask questions like whether they are ready to brew on a given day. Future extensions could include logging fermentation readings, auto-creating batches from recipes, and sending notifications as batches progress through stages.
What is Brewfather?
Brewfather is the go-to app for homebrewers. It handles everything — recipe design, batch tracking, fermentation logs, water chemistry, and ingredient inventory. If you brew beer at home, there is a good chance your recipes already live there.
What is an MCP Server?
MCP stands for Model Context Protocol. It is a standard that lets you expose tools and data to an AI like Claude. Think of it as a plugin — you run a local server, and Claude can call into it during a conversation. No cloud middleman, no custom UI. Just your data, your rules.
How I Built It
Brewfather has a solid REST API. I pulled up the API documentation and fed it straight to Claude. I described what I wanted — a local MCP server that could talk to Brewfather on my behalf — and Claude generated the server code. A few tweaks later it was running locally and connected to Claude Code. The whole thing took an afternoon.
What It Can Do
Three things immediately became useful:
Browse my recipes. I can ask Claude to pull up any recipe by name, show me the grain bill, hop schedule, or yeast selection — all from my actual Brewfather library.
Check my brew schedule. The MCP can look up my batches and tell me when my next brew day is planned, what recipe it is, and what stage I am at.
Verify ingredient inventory. Before brew day I can ask Claude to check whether I have enough of everything for the recipe. It reads my inventory from Brewfather and flags anything that is running low or missing.
Why This Is Cool
The shift here is that your brewing data becomes conversational. Instead of opening the app, navigating to inventory, and cross-referencing a recipe manually — you just ask. "Am I ready to brew this Saturday?" and get a straight answer. That is the kind of practical AI utility that actually changes how you work.
What's Next
There is plenty of room to extend this. Logging fermentation readings, automatically creating new batches from a recipe, getting notified when a batch moves to the next stage. The API supports all of it. If you are a developer who also homebrews, or just curious about what you can build with MCP servers, this is a great weekend project to try.
Using the WAT Framework: Writing Sanity MCP Workflows That Make Claude Consistent and Reliable
The text explains why open-ended AI instructions like “write a blog post about TypeScript” lead to inconsistent results. Because models are probabilistic, they vary structure, miss fields, and overlook edge cases, which is problematic for repetitive, structured tasks such as publishing to a CMS. To solve this, it introduces the WAT framework: Workflows, Agents, Tools. Workflows are plain-language markdown SOPs that encode domain knowledge and specify steps. Agents (Claude) handle reasoning and decisions. Tools are deterministic scripts or APIs, like the Sanity MCP, that execute actions. This separation narrows the decision space and keeps behavior consistent across sessions. A concrete example is the draft_blog_post workflow, which fetches authors and categories from Sanity, requires outline approval, and strictly defines document shape and constraints, including a 5000-byte body limit. Workflows evolve through a self-improvement loop: each failure adds new rules and edge cases. To get started, you document repeatable tasks, inputs, tools, steps, and edge cases, store them in .claude/wat/workflows/, and reuse them for faster, cheaper, and more reliable AI-assisted work.
Read post
Serving Your Blog as Markdown So AI Agents Can Actually Read It
The article explains how to serve clean Markdown versions of blog posts so AI agents can consume content without HTML noise like navigation, scripts, and cookie banners. It recommends two access patterns: appending .md to post URLs, or using an Accept: text/markdown header for content negotiation. In Next.js, rewrites in next.config.ts route both patterns to an internal /md/posts/[slug] handler. That route fetches the post from Sanity, converts it to Markdown, and returns it with a text/markdown Content-Type and short caching headers. A buildPostMarkdown helper constructs the Markdown document with a title, canonical URL, optional hero image, auto-generated summary, and body converted from Portable Text via @portabletext/markdown. Code blocks stored in Sanity as _type: "code" are correctly rendered as fenced Markdown code blocks with language tags, making them ideal for AI agents and syntax highlighters. A /posts.md index provides a machine-readable sitemap listing all posts with metadata and links, enabling agents to discover and traverse content efficiently using either the .md suffix or Accept header approach.
Read post