Built 5 MCP servers in 2026, retired 4 daemons and a Zapier flow
Catalog and blog-index MCPs saved roughly 9 hours per week
Render-queue MCP was a mistake, ripped it back out after 11 days
One pattern made every server after the first take under 90 minutes
I built 5 Model Context Protocol servers for my studio this year and deleted 4 background daemons, a Zapier flow, and roughly 600 lines of one-off shell scripts in the process. The math changed once I stopped thinking of MCP as "Claude plugins" and started treating it as cheap glue between the tools I already pay for. Here is what I shipped, what each one replaced, and the one I had to rip back out.
The Two That Saved the Most Time
The Shopify catalog MCP was the first one I built, and it is the only one I would refuse to give up. Before it, every time I drafted a product blog or an announcement, I would open Admin, search for the product, copy the price, copy the slug, and paste it back into the article. Or worse, I would run a one-off Admin API script and grep the JSON. With the MCP server in place, Claude queries the live Shopify catalog before writing a single sentence. Title, slug, price in EUR, current variants, last edit date. The article ends up factually correct on the first draft instead of the third.
The blog index MCP came two weeks later and replaced an embarrassing pile of ad-hoc grep and jq pipelines over my 266-article corpus. Every time I wanted to link a new piece to existing articles in the same cluster, I was running shell incantations to scan the registry. Now Claude asks the MCP server: give me everything in the AI Tools cluster, give me articles linking to this URL, give me orphan posts older than 60 days. The server returns a tiny JSON payload, Claude picks 3 internal links, and I stop missing the obvious mates. For a deeper look at why the protocol scales like this, the Claude MCP Servers Practical Guide walks through the basics.
Together, these two saved roughly 9 hours per week. Not because they do anything magical. They just remove the context-switch tax. I never alt-tab to Admin or open a terminal mid-draft anymore. The article gets written in one pass, with real data, in one window.
The catalog MCP also caught two factual errors in drafts I would have shipped otherwise. Once a stale price from an old article. Once a slug that had changed during a product rename. Both would have been embarrassing to publish. Neither showed up because Claude pulled the live values before drafting.
The One That Was a Mistake
The After Effects render queue MCP was a mistake. I built it in a Friday-evening flow state, convinced I had cracked the loop. Claude would queue compositions, watch frames render, and tell me when the deliverable was ready. The server was 180 lines of TypeScript wrapping aerender, and it worked exactly as designed.
The problem was not the code. The problem was that I do not render headless. I scrub. I open the comp, watch a frame, nudge a curve, watch another frame. The render queue is the end of the work, not the middle. Wrapping it in an MCP server meant Claude could see something I never asked Claude to look at. The agent kept proactively suggesting render starts, asking about output paths, offering to queue overnight passes. None of that fit how I actually use After Effects. I deleted the server after 11 days.
The lesson is not "do not build MCP servers for design tools." The lesson is that MCP makes sense when the tool is upstream of writing or shipping. The catalog is upstream of every blog. The blog index is upstream of every internal link. The render queue is downstream of creative judgment, and putting an agent in that loop just adds noise. If the answer to "should an agent see this?" is "only after I have already decided," skip the server.
The other tell was simpler. I never reached for it. Every time I sat down to render something, my hand went to the AE timeline, not to the chat window. When a tool you built sits unused for a week, that is the signal. I gave it 11 days because I wanted to be sure, but the answer was clear by day 3. Sunk-cost bias kept it on my dock longer than it deserved.
The Pattern That Made Building Trivial
After the first server, every MCP server I built took under 90 minutes. The pattern was almost embarrassingly simple. One file, three tools per server, no state, no auth beyond a single env var. The Vercel deploy status MCP is 70 lines. It exposes 3 tools: last_deployment, env_diff, recent_errors. That is it. Before this server, I was opening the Vercel dashboard 12 times a day to check whether a push to raxxo-studio had built. Now Claude asks the server, sees the green, and I move on.
The local finance ledger MCP follows the same shape. Three tools: month_spend_by_category, recent_entries, over_budget_categories. Read-only over a localStorage dump. No write access. No way for the agent to touch numbers. I needed this because I kept opening the dashboard mid-conversation to answer "how much did I spend on software in May?" Now I just ask. The server returns a small JSON object. Claude reads it back. The conversation continues.
The pattern: one tool per question I keep asking. No more. No general-purpose "query anything" tool that tempts overuse. Three narrow tools beats one fat one every time. The wider point about how this scales across an ecosystem of 97 million weekly users is covered in MCP: 97 Million Agentic Foundation, and the production patterns I borrowed for the server scaffolding came from the Claude Agent SDK Production writeup.
The other half of the trick is logging. Every MCP server I keep writes a single-line JSON entry per call. Tool name, arguments, response size, latency. After two weeks I read the log and prune. Tools that get called zero times get deleted. Tools that get called constantly tell me what to expose next. The Vercel server started with 5 tools. It is down to 3. The blog index started with 3 and grew to 4. The log is the only feedback loop that matters.
What I Won't Build as an MCP
There is a category of work that looks like a perfect MCP target and is actually a trap. Anything that involves making a decision in real time on visual or emotional grounds. Anything where the agent could be tempted to act before I have looked. Anything where the round-trip cost is higher than the cognitive cost of just opening the tool.
I keep a short veto list. No MCP for my email. No MCP for Slack DMs. No MCP for the actual creative software (After Effects taught me that). No MCP for client deliverables until they are already approved. The pattern is the same in each case: the value of the work depends on me looking, not on automation reading.
The replacements I made were all dead time. Opening Admin to copy a slug. Running grep to find mates. Refreshing the Vercel dashboard. Opening a budget app to answer one number. Every one of those was a context switch worth eliminating. None of them touched the part of the day where the actual work happens.
The other rule I follow: if a tool would benefit from write access, I do not give it. The finance ledger MCP could in theory add entries. It does not. The blog index MCP could in theory move articles between clusters. It does not. Read-only servers are forgiving. You can ship them in a weekend, run them for a year, and never worry about an agent doing something irreversible. The moment a server needs write access, the design budget triples. Most of my use cases are read-only by nature, and that is exactly why MCP works for a one-person studio.
If you want a longer view on which surfaces are worth wrapping in MCP and which to leave alone, the Claude Blueprint hub collects the rest of my notes on the loop.
Bottom Line
Five MCP servers in 2026, 4 still running, 1 deleted. The pattern is the same across every keeper: replace a context switch, expose 3 narrow tools, return small JSON, do not let the agent write. The ones that worked all replaced dead time that was already costing me 2 to 9 hours a week. The one that failed tried to put an agent inside a creative loop where the value comes from me looking, not from an agent reading.
If you run a solo studio or a one-person ops setup, MCP is not a Claude feature. It is replacement infrastructure for the small daemons, Zapier flows, and shell scripts you have been duct-taping for years. Start with the most boring thing you do 10 times a day. Build a server with one tool. See how it feels. The first one took me a weekend. Number 5 took 80 minutes.
This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)
Top comments (0)