From Zero to Shipped: My Journey Building an MCP Server

Saja Sayara — Sun, 06 Sep 2026 13:17:17 +0000

Six weeks ago, "MCP" didn't mean anything to me. Today, I've shipped tools, published a live website, and learned more about backend engineering — and about myself as a builder — than I expected from a single cohort.

Where I started

I joined NextFlows Academy's Building an MCP for an AI Engine program with a decent grip on the basics, but the Model Context Protocol itself was completely new territory. The idea that an AI assistant could reach out and call real, validated tools — not just generate text — was exciting, but the actual mechanics of it (stdio transport, schemas, tool lifecycles) took real time to click.

What I built

Working with my teammates, we built Quote-of-the-Day, an MCP server that lets an AI host fetch, search, and manage a collection of quotes. I owned two of the six tools:

list_categories — surfaces every category in our dataset, so a user (or an AI) can browse quotes by theme.
delete_quote — the one I'm most proud of. A delete button sounds simple until you actually think about what could go wrong. I built it to require an explicit confirm: true flag, to refuse to run if it would leave the collection empty, and to take an automatic backup before removing anything. Small details, but they're the difference between a toy feature and something you'd trust in production.

Every tool we shipped went through Zod validation — strict types, length limits, character allowlists — so the server rejects bad input before it ever touches our data.

Taking it further

I didn't want the project to just live in a repo that only developers could appreciate, so I built and published a public project website on GitHub Pages. It walks through what the server does, introduces the team, and includes something I'm genuinely excited about: a Live Console — a section where anyone can actually run our tools, right in their browser, against the real dataset. Not a mockup, not screenshots — the real logic, live.

Getting there wasn't frictionless. I ran into GitHub's permission model head-on: Collaborator access isn't the same as Admin access, and features like enabling GitHub Pages are gated behind repo ownership. I hit a confusing 404 on my first deploy attempt and had to work backward to realize it was a permissions issue, not a code bug. It was a good reminder that "it doesn't work" often has a boring, fixable cause if you're willing to dig.

What was genuinely hard

Two things stretched me the most:

Writing validation that's strict without being annoying. It's easy to make a delete tool "safe" by making it painful to use. Finding the right balance — safe by default, but not obstructive — took a few iterations.
Matching real behavior everywhere. When I built the Live Console, I made a rule for myself: it had to run the exact same logic as our actual quotes.ts and schemas, not a simplified stand-in. It would have been faster to fake it. It was more honest — and more useful — not to.
What's next

If I kept building, the first thing I'd add is a real backend behind the website's Live Console, so write actions (creating, updating, deleting quotes) persist for everyone, not just within a visitor's own browser session. Right now it's a great demo; with a backend, it'd be a real shared tool.

The takeaway

Six weeks ago I could describe what an API does. Now I've shipped one — tools, validation, safety guards, a live public site — and picked up a real feel for how "it works on my machine" turns into "it works for anyone who opens this link." That gap is most of what backend engineering actually is, and I'm glad I got to close it, mistake by mistake, with a great cohort and mentor around me.

DEV Community: Saja Sayara

From Zero to Shipped: My Journey Building an MCP Server