DEV Community

Thuận Lê
Thuận Lê

Posted on

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

#mcp #claude #typescript #webdev

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):

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.

Top comments (0)