I built 3 MCP servers in a day — then used one to audit and fix my own sites

Thuận Lê — Sun, 07 Jun 2026 11:43:09 +0000

Most MCP examples I'd seen stopped at a "hello world" weather tool. I wanted to know what it takes to build real ones — so in one day I built three Model Context Protocol servers, each a different shape, and then pointed one of them at my own production sites. It found real problems. I fixed them. Here are the numbers and what I learned.

Quick context: what an MCP server is

An MCP (Model Context Protocol) server gives an AI assistant like Claude a set of typed tools it can call. Instead of pasting data into a chat, you expose your system — a database, an API, whatever — as tools, and the model calls them with structured arguments. You write the server once; any MCP client can use it.

Three servers, three shapes

I picked three different "shapes" on purpose, so I wasn't rebuilding the same thing three times:

1. stayhub-mcp — wrapping a database. Read-only tools over the Postgres database of StayHub, a booking app I built (Prisma + Neon). Five tools: search listings, listing detail, booking stats, top cities by revenue, and availability for a date range. Now I can ask Claude "top cities by bookings this month?" and it queries the DB.

2. web-audit-mcp — wrapping external APIs. Three tools to audit any URL: audit_performance (Google PageSpeed / Lighthouse), audit_seo_meta (parse title / description / Open Graph / headings with cheerio), and check_headers (status + security headers). No database — just HTTP.

3. deploy-status-mcp — wrapping DevOps APIs. Read-only deployment status across Cloudflare Pages, Vercel, and Netlify. "Did my last deploy succeed?" without leaving the editor.

All three share the same small stack: TypeScript + the MCP SDK + Zod for input validation + dotenv. Each one has an end-to-end test that spawns the real server over stdio and calls every tool. Secrets go in a gitignored .env.

The fun part: dogfooding

The second server, web-audit-mcp, turned out to be the most useful — because I immediately ran it on my own sites.

My portfolio (static HTML on Cloudflare Pages):

The audit flagged the title (71 chars) and meta description (181 chars) as too long for Google — they'd be truncated in search results. Easy fix.
Performance was 73 on mobile, with a slow First Contentful Paint of 3.3s. The cause was a render-blocking Google Fonts stylesheet. I switched it to a non-blocking load (preload + media="print" onload). Result: FCP 3.3s → 1.7s, Performance 73 → 97.

A lesson hid in here. One run reported LCP at 4.4s, and I almost started "optimizing" the hero animation. But re-running the audit showed LCP at 1.7s consistently — the 4.4s was just lab-measurement variance. The fix that mattered (the font) was already done. Without re-measuring, I'd have "fixed" something that wasn't broken.

My SaaS (StayHub, Next.js on Vercel):

The audit found no Open Graph tags on the homepage — so sharing the link on Facebook / Zalo showed no preview card. I added Open Graph + Twitter Card metadata and a branded opengraph-image.tsx (generated with next/og). Now shares show a proper card.
After the fix: SEO warnings → 0.

And the best part: dogfooding found a bug in my own tool. The audit reported a heading as "Nghỉ dưỡngHoàn hảo" — two words glued together. The site was fine; my tool was extracting text and ignoring <br> tags. So I fixed the tool to treat <br> as whitespace. You only find that kind of thing by using what you build.

What I'd tell myself before starting

Pick different shapes. Three database wrappers would have taught me one thing three times. DB / external API / DevOps taught me three.
Keep tools read-only when you can. All of mine only read. That makes them safe to point at production and removes a whole class of "oops" — and honestly, read tools cover most of what you actually want from an assistant.
Write an end-to-end test. Spawning the real server over stdio and calling each tool caught more than a unit test would have, and it doubles as living documentation.
Dogfood immediately. The audit server only earned its keep when I ran it on my own sites — and it paid me back by finding real issues and a bug in itself.

The three repos are open source (MIT):

stayhub-mcp — https://github.com/LEO17061996/stayhub-mcp
web-audit-mcp — https://github.com/LEO17061996/web-audit-mcp
deploy-status-mcp — https://github.com/LEO17061996/deploy-status-mcp

If you've been reading about MCP but haven't built one, pick something you already own — a database, an API you call a lot, your deployment dashboard — and wrap it. The second one is much faster than the first.

DEV Community: Thuận Lê

I built 3 MCP servers in a day — then used one to audit and fix my own sites

Quick context: what an MCP server is

Three servers, three shapes

The fun part: dogfooding

What I'd tell myself before starting