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

Source: Dev.to

🎃 The Idea

The app lets users choose:

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

and 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

Essentially, a “time machine” for developers.

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

I started with vibe coding inside Kiro, describing 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

Seeing an idea become a functional codebase within minutes gave early momentum and validated the architecture before any manual coding.

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

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 these specs, Kiro regenerated clean, consistent code across the entire monorepo. Updating a requirement meant simply editing the spec, and Kiro kept all services in sync—no drift, no conflicts, no outdated files.

🎛 Step 3: Steering Docs — Keeping the Codebase Consistent

I created .kiro/steering/coding-style.md to enforce:

• Folder structure
• Naming conventions
• Error response formats
• Comment style
• TypeScript patterns
• File layout
• Import style

After adding the steering doc, every generated file matched the established code style, even when created days later, giving the project a “single author” feel.

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

The custom MCP server is the core of the project. 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 backed by real historical ecosystem data rather than a static mock.

🔁 Step 5: Agent Hooks — Automating Workflows

Two custom hooks were added:

1. gen:scaffold – Regenerates project structure based on updated specs.
2. pre-commit – Runs type checks and lightweight build validation.

These hooks prevented out‑of‑sync types, broken builds, and spec drift, acting as 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

All endpoints are publicly available, open source, and live.

💡 What I Learned

• Vibe coding accelerates early exploration.
• Specs turn AI output into structured, consistent code.
• Steering docs are vital for long‑lived AI‑generated projects.
• MCP unlocks real integrations beyond static scaffolding.
• Hooks keep the codebase healthy and automatically consistent.

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

🚀 Try MCP Time‑Traveler

Explore the live demo and source code to see the “time machine” in action.

🎃 Final Thoughts

As a solo developer, building a multi‑service app with an MCP server, API, and frontend is normally a challenge. 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.