Claude

TL;DR Three production MCP servers I run: a docs/wiki wrapper, a personal-finance aggregator, and an inventory-ops tool for a side project. Type hints are your schema. The FastMCP SDK extracts JSON Schema from Python docstrings and type annotations — you almost never hand-write schemas. Flatten nested APIs. If the upstream API returns nested JSON, unwrap it in the MCP tool and return clean markdown or a simple dict — agents prefer predictable structures. Reads always-on, writes gated. Use environment variables (MCP_WRITE=1) or similar to gate mutation tools; put mutations behind a validated service layer and audit every call. Log to stderr, not stdout. Stdio protocol uses stdout for JSON-RPC; anything else breaks the connection. The lineup I’ve written three MCP servers from scratch over the last few months. This is the cookbook — concrete patterns, not theory. If you haven’t read the intro to writing MCP servers, start there; I won’t re-explain the anatomy. ...

TL;DR I ran an audit over my repos going back to March: pull the first commit that introduced each agentic pattern, then go find out when that pattern actually became common practice in the wider ecosystem. The results were humbling in a useful way. Four things I quietly considered myself early on were catch-up, in one case by two years. Four other things turned out to be genuinely ahead of documented practice. The interesting part is what those four have in common, and it is not what I expected. ...

TL;DR Before I merge anything where being wrong would be silent, I paste it into a live Gemini session and ask that model to attack it. Not “review this,” which gets you a rubber stamp with bullet points. Attack it. Over four days in April, that gate killed a performance optimization 88 minutes after it shipped, found two engine bugs that meant every historical number in my trading leaderboard was inflated, and identified five separate ways my “out-of-sample” evaluator was reading the future. Claude wrote all of that code. Claude also reviewed all of that code. Claude caught none of it. The useful property is not that Gemini is smarter, it is that Gemini did not write the thing and has no investment in the design being correct. ...

TL;DR One model = one blind spot. Claude and Gemini were trained on different datasets, have different architectures, and will miss different things. Consult for breadth, not consensus. The goal is to widen your analysis surface and catch blindspots, not to reach agreement. If all three models agree, that’s suspicious—run stress tests. The bridge is simple: Playwright drives a logged-in Gemini tab via Chrome DevTools Protocol, pastes your prompt, and scrapes the response when done. Real session, no API key. Two modes: (1) cold second-opinion—hand off a problem and ask for an independent take; (2) adversarial debate—assign sides, force defense, then reconcile. Both work; adversarial is brutal and useful for high-stakes calls. Anchoring is the trap. If you show Model B what Model A said and ask “do you agree?”, you get theater. Always pose cold or ask for the opposite argument first. Every Model Has Its Blind Spot I make the same mistakes in code as everyone else. My reasoning hits walls. I miss architectural gotchas and cut corners on testing. An LLM does the same, just in different places. ...

TL;DR Two Claude agents running in separate project contexts share a private Mattermost channel to ask each other for help without human intervention. A deterministic polling gate (bash + curl) checks for new messages before spawning the expensive responder LLM — idle polls cost almost nothing. The responder runs on the Claude Code subscription (keychain OAuth), not API credits, and keeps the LLM cheap. Scheduled every ~3 minutes by macOS launchd; armed/disarmed by loading/unloading the launch agent. Supervised autonomy: the responder can read, triage, draft, and explain — but NOT commit, spend money, change access, or deploy. Why one agent asks another I run parallel Claude Code sessions on different projects. They’re isolated — each has its own repo context, its own workflow, its own focus. But sometimes they need each other. ...

TL;DR I point Claude at a problem, give it a direction, and let it run — and most of the time I don’t read the merge request it opens. On an internal homelab where the blast radius is my own cluster, backups are real, and everything’s reproducible from code, line-by-line diff review is the wrong altitude. Instead I supervise after the fact by reading the artifacts the agents leave behind: the /docs/ folder, a Wiki.js wiki full of Mermaid diagrams, auto-generated architecture SVGs, and this blog. Reading those — not the diffs — is what’s actually caught problems: dead systems still wired in, duplicate config, a deploy that quietly deleted itself. ...

TL;DR I have $X in monthly Claude tokens I don’t always use. Instead of letting the unused credit evaporate, I built a parallel agent sweep that fans out autonomous scouts to scan for dependency upgrades, CVEs, CI waste, and quick wins across my repos. Each discovery agent returns a scored candidate list. The orchestrator triages and ranks them, then spins up isolated worktree agents to implement the safe ones — all under a hard token cap and with human gates between phases. The output is a pile of merge requests, not silent commits. Noise is real and review burden is the limiting factor, but when it lands right, an hour of agent work + human review beats a weekend of manual maintenance. ...

TL;DR Model Context Protocol (MCP) is a transport layer that lets Claude and other LLM agents call local tools with typed signatures and structured responses. Any HTTP API running on your homelab — ComfyUI, a wiki, a dashboard, a custom service — can become a set of agent-callable tools by wrapping it in a FastMCP server. A typical server takes 150–250 lines of Python, exposes 3–5 tools via @mcp.tool() decorators, and runs as a stdio process. The pattern scales from single-purpose (image generation) to multi-tool (queue status, model listing, system stats) without complexity explosion. This post shows the anatomy by dissecting the ComfyUI MCP server: how to build workflows, poll for completion, parse results, and return structured JSON that agents actually use. ...

TL;DR I run 3-5 Claude Code sessions in parallel at staggered cadences. They coordinate through a shared #mat-claude-sessions Mattermost channel plus a small coordination board file. Each session announces what it’s about to touch, claims it, and announces when it’s done. Conflicts are rare; throughput is dramatically higher than running one session at a time and waiting. Why parallel A single Claude Code session running a long task — refactor across a few repos, work through a debugging session, draft a blog post — is mostly me waiting. The model is fast but tasks are bounded by my decisions, my reviews, and my edits. If I’m waiting on Session A to finish a build, Session B can be drafting something unrelated. Session C can be running a slow eval. The bottleneck stops being the model and becomes my own attention rotation. ...

Heads up: this post mentions Claude. If you want to try it, I've got a referral link — it gives us both a bit of extra credit, no pressure: claude.ai via my referral. TL;DR Most AI tooling still treats an LLM like a search bar — you prompt, it answers, the loop ends. Useful, but not what I wanted. For my homelab’s ops + trading intelligence platform (OpenClaw), I needed agents that could run for hours, do real work against a real cluster, and then tap me on the shoulder when they found something I should see. Claude turned out to be the model I kept coming back to for the “thinking” layer — it’s both comfortable with long tool-use chains and happy to write structured output a human won’t need to decode. This is a tour of how I’ve actually wired that up: k3s CronJobs doing the heavy lifting, LiteLLM as the routing layer, Slack as the interrupt bus, and named cat-bot personas so I can tell at a glance who’s knocking. ...