The MCP Server of You: Building a Personal Knowledge Power for Kiro IDE

In this post I’m going to walk you through how I built kiro-recall, a Kiro IDE Power that loads your personal knowledge vault into every session before you type a single word.

We’ll cover why I built it, how it works, and how you can install and test it yourself.

I’m getting old, and as I get older, I find my brain races faster than it ever has, because I have gained more and more knowledge as the years have dragged on ceaselessly.

I needed to go back to filing my thoughts.

I started with a notepad with way too many unsaved tabs. Great. Now I can’t remember what I wrote on every single tab, let alone find them on my PC if I closed them down.

I needed a solution — a digital Zettelkasten folder or “second brain” vault seemed to solve that problem, so I built one in Obsidian.

During the development of the Power though, I discovered all I needed Obsidian for was the inspiration. I needed to see the shape of how these things were constructed.

Turns out a vault is just a folder. Plain markdown files on your own disk, organised in a way that makes sense to you. No app required to read them, no proprietary format locking you in, no cloud sync needed. Any text editor can open them. Any MCP server can read them.

That realisation is what made kiro-recall possible. If the vault is just a folder, you can point an MCP server at it, read the files directly, and inject them into a Kiro session without Obsidian ever being involved. Obsidian is still great for browsing your notes visually — the graph view, backlinks, and plugin ecosystem are genuinely useful. But it’s optional. The vault works without it.

What we’re building

kiro-recall is the MCP Server of You.

Your decisions, your knowledge, your project context, loaded from your own machine into every Kiro session automatically before your first prompt reaches the model.

Kiro’s steering files are unreliable.

I found this out the hard way. I had steering files configured with inclusion: always, the mode that’s supposed to load them into every single interaction. They still got ignored. Kiro would generate code in broken language causing syntax errors, forget architectural decisions I’d documented, and ask me to re-explain context I’d already written down.

After a Kiro update introduced Agent Skills, the problem got worse. Users started reporting on GitHub that project steering files were failing to load entirely, with the AI ignoring inclusion: always in favour of generic task instructions.

Every new session I was back to re-establishing who I am, what the project is, what decisions were already made.

kiro-recall replaces that with a hook-based context injection system.

A session start hook fires on your first prompt. Before your message reaches the model, it reads your personal knowledge vault from disk via MCP and injects the relevant notes as context. Not steering files. Not a prompt you paste in every session. Your actual notes, loaded automatically, every time.

You do nothing. It just happens.

The difference is architectural. Steering files sit in your workspace and hope the model reads them. kiro-recall uses a hook — it fires on the promptSubmit event, which means it runs before Kiro can ignore anything. The context is already in the session before your first word.

The vault is plain markdown files. No cloud dependency for reading your own notes. No data leaving your machine.

v0.1.0 ships four hooks:

Hook	Trigger	What it does
Session Start	Every first prompt	Reads vault, injects context
/recall	User triggered	Writes a structured note to 00-inbox/
Vault Scaffold	User triggered	Creates the standard folder structure
/promote	User triggered	Reformats an inbox note as a Zettelkasten permanent note

The architecture is intentionally minimal. No compiled code. No runtime dependencies beyond the MCP server. Every hook is a JSON file with an askAgent prompt that instructs the model to execute a numbered procedure using MCP tool calls.

This isn’t a new idea. Developers have been pointing Claude Code at Obsidian vaults for months, and the consensus is consistent: targeted context beats re-explaining everything from scratch every time.

And apparently, it saves you tokens and credits.

That might seem counterintuitive. You’re adding context, so shouldn’t that cost more? The saving comes from what you stop doing.

Before I built kiro-recall, every Kiro session started the same way. I’d open a workspace, type my first prompt, and immediately hit a wall. Kiro didn’t know what I was building, what decisions I’d already made, or what stack I was using. So I’d spend the first few exchanges just getting it up to speed. Sometimes I’d paste in background. Sometimes I’d answer clarifying questions. Sometimes I’d just watch it confidently do the wrong thing because it had no context to work from.

That re-establishment isn’t free. Every clarification, every correction, every “no, I already decided to use X not Y” costs tokens. It happens at the start of every session, every day, across every project.

kiro-recall front-loads a small, targeted context injection once per session. Atomic permanent notes are concise by design — one idea per note. The session hook runs once and stops. What it replaces is typically far more expensive in both credits and time, but that’s one of the things I want testers to actually measure and report back on. I will be conducting my own A/B testing in regards to this.

The difference with kiro-recall specifically is the hook. Every other approach still requires you to remember to load the context. kiro-recall makes it impossible to forget.

How it works

The vault structure

The scaffold hook creates this structure on first run, wherever you point it. Your vault can live anywhere on your machine — a dedicated folder in Documents, alongside your dev projects, wherever makes sense for you. You configure the path once in mcp.json and that’s it.

vault/
├── 00-inbox/          # /recall writes here
├── 01-projects/       # one file or subfolder per active project
├── 02-job-search/
├── 03-learning/
├── 04-knowledge/
├── 05-community/
├── 06-permanent/      # atomic Zettelkasten notes — loaded every session
└── 07-templates/

This structure is opinionated. It’s based on my own workflow as an AWS Community Builder juggling job applications, learning, and community work alongside dev projects. The folders that actually drive kiro-recall’s behaviour are only three: 00-inbox/, 01-projects/, and 06-permanent/. The rest is suggested organisation. Rename them, ignore them, add your own. The vault is just a folder — it’s yours.

Relevance detection

The session start hook runs a four-stage Relevance Detector before injecting anything.

Stage 1 — Primary signal. The hook extracts the workspace folder name (e.g. kiro-recall from C:\Dev\kiro-recall) and checks whether a matching file or subfolder exists in 01-projects/. If it finds one, it loads that project note plus all permanent notes and stops.

Stage 2 — Secondary signal. If no primary match, it scans the paths of all open files in the workspace. Any path segment that matches a project folder name in 01-projects/ resolves the project. It also checks .kiro/steering/ for a project field as a fallback within this stage.

Stage 3 — Fallback. No project match found. Load all permanent notes from 06-permanent/ and inject those.

Stage 4 — Cold vault. If 06-permanent/ and 00-inbox/ are both empty, skip injection entirely and show a warm onboarding message instead of an error.

A generic name guard runs before Stage 1. Workspace names like src, dev, app, repo skip primary matching entirely and go straight to secondary signals. This prevents false matches on common folder names.

The hook files

Each hook is a .kiro.hook JSON file. Here’s the structure:

{
  "name": "kiro-recall: Session Start",
  "version": "1.0.0",
  "when": {
    "type": "promptSubmit"
  },
  "then": {
    "type": "askAgent",
    "prompt": "..."
  }
}

The promptSubmit event fires on every prompt, so the session start hook includes a once-per-session guard. On the first prompt it runs the full Relevance Detector and injects context. On every subsequent prompt in the same session it exits immediately. You get context once, cleanly, at the start.

The capture and promote hooks use userTriggered instead. They sit quietly until you need them — type /recall mid-session to capture a note, or /promote to move an inbox note into your permanent knowledge base.

The MCP dependency

kiro-recall wraps @bitbonsai/mcpvault for vault access.

The original choice was smithery-ai/mcp-obsidian, but it only exposed two tools and had no active maintenance. mcpvault ships 14 tools including write_note, search_notes, read_multiple_notes, and move_note — everything the hooks need to read, write, and reorganise your vault. It reads any directory of markdown files directly from disk, which means no Obsidian install required and no dependency on any proprietary format.

One configuration line is all it needs:

{
  "mcpServers": {
    "mcpvault": {
      "command": "npx",
      "args": ["-y", "@bitbonsai/mcpvault", "YOUR_VAULT_PATH_HERE"]
    }
  }
}

Replace YOUR_VAULT_PATH_HERE with the path to your vault folder and you’re connected. The vault path is the only configuration required. Everything else is derived from the folder structure at runtime.

The promote flow

The /promote hook is the most interesting piece of v0.1.0.

/recall is fast and low-friction by design. You dump a rough note into 00-inbox/ and move on. But rough notes don’t load well as context — they’re messy, multi-topic, and hard for the model to use. Permanent notes need to be atomic. One idea, clearly stated, with connections to related concepts.

/promote does that reformatting for you. It lists your inbox notes, you pick one, and the hook rewrites it as a proper Zettelkasten permanent note with a fixed structure:

# {Idea Title}

## The idea
{single atomic statement, 1-2 sentences}

## Why it matters
{significance or future relevance, 1-2 sentences}

## Connected to
{[[wikilink]] references}

## Source
{project}, {session description}, {YYYY-MM-DD}

The filename is derived from the idea title using kebab-case with no date prefix. Permanent notes are evergreen — the filename reflects the idea, not when it was written. A note called relevance-detection-via-workspace-name.md is still findable and meaningful in two years. A note called 2026-03-20-session-notes.md is not.

After writing to 06-permanent/, the hook deletes the original from 00-inbox/. If the write fails, it surfaces the full reformatted note in a code block so nothing is lost. If the delete fails after a successful write, it warns you but doesn’t roll back. The promoted note already exists in permanent, so the worst case is a duplicate in your inbox that you can delete manually.

Installing it

kiro-recall ships as a Kiro Power and is installable right now directly from GitHub.

1. Open Kiro IDE and go to the Powers panel
2. Click Add power from GitHub
3. Paste https://github.com/mikeartee/kiro-recall
4. Once installed, open the Powers config and update the power-kiro-recall-mcp-obsidian entry — replace YOUR_VAULT_PATH_HERE with the full path to your vault folder
5. Restart Kiro or reconnect the MCP server from the MCP Servers panel
6. Trigger the Vault Scaffold hook once from the Hooks panel to create your folder structure
7. Start a new session — the session start hook fires automatically on your first prompt

From the next session onwards, context loads automatically.

What it produces

After the session start hook runs, you see exactly one line:

Loaded kiro-recall note (primary match) + 3 permanent notes.

No file paths. No diagnostic output. Just a confirmation of what was loaded and how it was matched.

After /recall:

Note saved: 2026-03-20-kiro-recall-promote-flow-decision.md. It's in your inbox whenever you're ready to review it.

After /promote:

Promoted to `06-permanent/relevance-detection-via-workspace-name.md`.

The vault fills itself as a side effect of your normal dev workflow. Over time it becomes a searchable record of every decision, pattern, and insight across all your projects.

---

I need testers. Windows and Mac both welcome.

Some things I want feedback on:

1. Does it work on your machine?
2. Does the vault context actually change how your sessions feel?
3. Does it use less credits in Kiro IDE on tasks?
4. What would you add or change?
5. Was it easy to install?

Install via Add Power from GitHub in Kiro IDE: github.com/mikeartee/kiro-recall

Originally published on builder.aws.com