How I Built MCP Time-Traveler with Kiro: A Developer’s Journey Through Vibe Coding, Specs, Steering, Hooks, and MCP

Source: Dev.to

🌱 Where the Idea Started

Developers often discuss “what stack should I use?” but rarely ask, “what did this stack look like five or ten years ago?”
I imagined a simple interface:

1. Choose a language →
2. Choose a framework →
3. Pick a year →
4. Get the entire runtime + dependency stack for that year.

The twist was that I didn’t want to fake the data—I wanted to fetch it from real package registries. To achieve this I needed:

• A frontend
• An API
• A shared types layer
• A custom MCP server
• Real registry integrations
• End‑to‑end Kiro support

As a solo developer that’s a lot, but Kiro made it feel surprisingly manageable.

⚡ Vibe Coding: Turning Loose Thoughts into a Real Project

I started with vibe coding—simply talking to Kiro about the concept. Within minutes Kiro created:

• A full monorepo structure
• An Express API
• A React/Vite frontend
• Shared TypeScript types
• A starter MCP server
• Initial routes and validation logic

Kiro aligned each part with the others from the beginning, feeling like pair‑programming with an engineer who understood architecture.

📘 Specs: Moving from Exploration to Structure

After clarifying the idea, I moved into spec‑driven development. I wrote two spec files:

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

These specs defined:

• Input/output contracts
• Type structures
• Expected API behavior
• Input validation
• Error shapes
• Integration points

Then I told Kiro:

Update the API implementation based on the current spec.

Kiro updated everything—API routes, types, helpers—consistently across the monorepo. Specs transformed the project from exploratory to internally coherent.

🎛 Steering Docs: Teaching Kiro My Preferences

To ensure consistency, I added .kiro/steering/coding-style.md describing:

• Naming conventions
• Error formats
• TypeScript patterns
• Folder structure rules
• Expected comments
• File layout preferences

The result: every part of the project, whether generated on day one or day five, looked like it came from the same author, eliminating cleanup time and speeding iteration.

🔌 The MCP Server: The Heart of the Project

The custom MCP server makes MCP Time‑Traveler more than a demo. I built three MCP tools:

• npm historical version lookup
• PyPI historical version lookup
• RubyGems version lookup

Kiro helped generate:

• The MCP tool schema
• Validation logic
• Error handling
• The tool handler implementation
• EOF‑safe request/response types

The MCP layer allowed the app to fetch real, accurate ecosystem data—not hardcoded values. For example:

• Node 4.9.1 + Express 4.13.4 for 2015
• Python 3.7.17 + Django 2.1.15 for 2018

Seeing real historical stacks appear in the UI felt magical.

🔁 Hooks: Automating the Workflows That Slow You Down

I added two Kiro agent hooks:

1. Scaffold regeneration hook – triggered whenever specs changed, keeping project structure aligned.
2. Pre‑commit hook – performed type checks and lightweight build steps.

These hooks acted like guardrails, helping a solo developer maintain discipline and consistency without remembering every detail.

☁️ Deploying the Full Project

• API → deployed to Heroku
• Frontend → deployed to Vercel
• MCP Server → runs locally for Kiro during development
• GitHub Repo → public, open source, MIT licensed

You can try it here:

• Frontend:
• API health endpoint:
• Source code:

💡 What This Project Taught Me

• How AI‑powered IDEs elevate solo developers
• How vibe coding excels at early exploration
• How specs enforce structure and long‑term consistency
• How steering docs unify the codebase
• How MCP bridges AI and real‑world data
• How hooks automate away repetitive tasks

Kiro didn’t just help me build faster; it helped me build more cleanly, predictably, and enjoyably.

🎃 Final Thoughts

When I started, I thought the MCP server would be the hardest part. Turns out, the hardest part was believing an AI‑assisted IDE could guide a full multi‑service build. Kiro did—consistently, reliably, and creatively. MCP Time‑Traveler became more than a hackathon project; it became a blueprint for how I want to build future tools.