DEV Community

Cover image for Building MCP Time-Traveler with Kiro: How I Used Vibe Coding, Specs, Steering, Hooks, and MCP to Build a Full Stack App
Prabhakaran Jayaraman Masani
Prabhakaran Jayaraman Masani

Posted on

Building MCP Time-Traveler with Kiro: How I Used Vibe Coding, Specs, Steering, Hooks, and MCP to Build a Full Stack App

#fullstack #tutorial #ai #mcp

When I joined the Kiroween Hackathon, I wanted to create something playful, unusual, and technically challenging — a project that stitched together multiple ecosystems, multiple runtimes, and multiple AI workflows.

The result is MCP Time-Traveler:

A full-stack app that reconstructs historical tech stacks (Node, Python, Ruby) for any year between 2015 and 2025 — using real registry version data pulled through a custom MCP server.

What made this possible in days instead of weeks?

Kiro

This article walks through exactly how I used Kiro’s features — vibe coding, specs, steering, hooks, and MCP — to build the entire project from scratch as a solo developer.

🎃 The Idea

I wanted an app where you choose:

  • A language (Node, Python, Ruby)
  • A framework (Express, Django, Rails)
  • A year (2015–2025)

…and the system returns:

  • The correct runtime version for that year
  • The package manager version
  • The framework version
  • Relevant dependencies
  • Notes about ecosystem changes
  • Real version data from npm, PyPI, and RubyGems

Basically a “time machine” for developers.

⚡ Step 1: Vibe Coding — Turning Ideas into Working Code

I started with vibe coding inside Kiro.

I described the project:

“I want a monorepo with an API, a web UI, a shared types folder, and an MCP server that queries real registries.”

Kiro instantly generated:

  • A clean monorepo layout (apps/api, apps/web, shared, mcp-server)
  • Initial Express routes
  • TypeScript types
  • A Vite + React frontend
  • The MCP tool skeleton
  • A working /api/generate proof of concept

The most striking moment was watching Kiro turn an idea into a working codebase within minutes.

This gave me early momentum and validated the architecture before I wrote anything manually.

📘 Step 2: Spec-Driven Development — Defining the Structure

Once the idea was clear, I added two specification files:

  • .kiro/specs/app-spec.md
  • .kiro/specs/mcp-spec.md

Each spec defined:

  • Inputs and outputs
  • Error shapes
  • Edge cases
  • Type contracts
  • Validation rules
  • API behavior
  • MCP tool behavior

From those specs, Kiro generated clean, consistent code across the entire monorepo.

The biggest benefit:

Whenever I changed a requirement, updating the spec allowed Kiro to regenerate code that remained aligned across all services.

No drift.

No conflicts.

No outdated files.

🎛 Step 3: Steering Docs — Keeping the Codebase Consistent

Next, I created .kiro/steering/coding-style.md.

This ensured consistent:

  • Folder structure
  • Naming
  • Error responses
  • Comment format
  • TypeScript patterns
  • File layout
  • Import style

After adding this steering doc, Kiro’s output became extremely predictable.

Every generated file matched the established code style — even when created days later.

This brought a “single author” feeling to a multi-generated project.

🔌 Step 4: MCP Server — Turning the Project from Demo to Real App

The most important piece of the project is the custom MCP server.

I implemented three MCP tools:

  • npmHistoricalVersions
  • pypiHistoricalVersions
  • rubygemsHistoricalVersions

These tools query real registry APIs to fetch accurate version data.

Kiro generated:

  • MCP tool schema
  • Request/response TypeScript types
  • Validation logic
  • Error handling
  • Integration into the main MCP server framework

With this MCP layer, the app is not a mock or static demo — it’s backed by real historical ecosystem data.

🔁 Step 5: Agent Hooks — Automating Workflows

I created two custom hooks:

1️⃣ gen:scaffold

Regenerates project structure based on updated specs.

2️⃣ pre-commit

Runs:

  • Type checks
  • Lightweight build validation

This prevented:

  • Out-of-sync types
  • Broken builds
  • Spec drift
  • Manual and repetitive chores

The hooks became a “safety net” for the entire monorepo.

🧪 Step 6: API and Frontend Deployment

To make the project accessible for judges:

  • API deployed on Heroku
  • Frontend deployed on Vercel

Endpoints:

Frontend:

https://mcp-time-traveler.vercel.app/

API Health:

https://mcp-time-traveler-api-04b9f0b0b1ae.herokuapp.com/health

GitHub Repo:

https://github.com/prabhakaran-jm/mcp-time-traveler

Everything is publicly available, open source, and live.

💡 What I Learned

Through this project I learned:

  • How powerful vibe coding can be for early exploration
  • How specs turn AI output into structured, consistent code
  • Why steering docs matter in long-lived AI-generated projects
  • How MCP unlocks real integrations beyond static scaffolding
  • How hooks keep the codebase healthy and consistent automatically

Kiro changed my development workflow — not just by speeding it up, but by making it more structured, more predictable, and more maintainable.

🚀 Try MCP Time-Traveler

Frontend:

https://mcp-time-traveler.vercel.app/

API:

https://mcp-time-traveler-api-04b9f0b0b1ae.herokuapp.com/health

Source Code:

https://github.com/prabhakaran-jm/mcp-time-traveler

🎃 Final Thoughts

As a solo developer, building a multi-service app with an MCP server, API, and frontend is normally a challenge.

But with Kiro’s ecosystem of vibe coding, specs, hooks, and steering — the experience felt smooth, accelerated, and enjoyable.

This project could not have been built without Kiro.

kiro

Top comments (0)