Obsidian und MCP: Claude Code, Codex und Antigravity Zugriff auf den Vault geben

Teil 4 der Obsidian-Serie – und der Teil, in dem das Second Brain Gesellschaft bekommt. Mittels des Community-Plugins Local REST API for Obsidian lässt sich Obsidian mit einem MCP-Server verheiraten, der der KI deiner Wahl den Weg in deinen Vault öffnet. Lesen, schreiben, suchen, Frontmatter pflegen – alles, was du sonst per Hand machst, kann ein Agent über MCP-Tools erledigen. Was du dafür brauchst, wo die Fallstricke liegen und warum deine CLAUDE.md keine Sicherheitsgarantie ist, klären wir jetzt.

Das Pflicht-Plugin – inzwischen mit MCP-Server ab Werk

Local REST API ist das Herzstück der ganzen Geschichte. Das Plugin stellt eine authentifizierte HTTPS-Schnittstelle zu deinem Vault bereit – und heißt mittlerweile offiziell „Local REST API with MCP“, weil es in den aktuellen Versionen (Stand Juli 2026) gleich einen eigenen MCP-Server mitliefert. Der läuft direkt in Obsidian, hat Zugriff auf Live-Metadaten, die aktive Datei, Periodic Notes und die Command Palette, und lauscht unter https://127.0.0.1:27124/mcp/ per Streamable HTTP. Authentifiziert wird mit dem API-Key aus den Plugin-Settings als Bearer-Token.

Das Repo selbst formuliert es unmissverständlich: Third-Party-MCP-Server existieren zwar weiterhin, seien aber „no longer necessary“ – wer noch einen nutzt, bekomme mit dem eingebauten voraussichtlich bessere Ergebnisse. Für den Standardfall ist der Weg also kurz. Plugin installieren, API-Key kopieren, MCP-Client auf den Endpoint zeigen lassen. Kein zusätzliches npm-Paket, kein separater Prozess.

Ich selbst komme von einer älteren Plugin-Version und fahre darum noch die Third-Party-Variante – absehbar wechsle ich aber auf den mitgebrachten Server. Der bringt alle Tools mit, die man im Alltag braucht, und spart einen kompletten Baustein im Setup. Was er nicht mitbringt, sind die ordnerbasierten Permissions von cyanheads – aber in meinem Vault liegt ohnehin nichts, das diese Schutzebene bräuchte (dazu weiter unten mehr).

Third-Party-MCP-Server – wann sie noch Sinn ergeben

Ganz obsolet sind die separaten Server trotzdem nicht, sie haben nur ihre Nische gewechselt – von Pflicht zu Spezialwerkzeug.

• mcp-obsidian hat das Nötigste, was man benötigt, wird gepflegt und ist etabliert. Setzt das Local-REST-API-Plugin voraus.
• obsidian-mcp-server von cyanheads ist meine erste Wahl, nachdem das lange populärste MCP-Plugin eingestellt wurde – dazu gleich mehr. Vierzehn Tools, gut dokumentiert, und mit einem Feature, das die anderen nicht haben: ordnerbasierte Read/Write-Permissions über Environment-Variablen plus ein globaler Read-only-Schalter. Warum das mehr ist als ein nettes Detail, klären wir beim Thema Instruction Files.
• mcpvault spielt in einer eigenen Kategorie: Es braucht das REST-API-Plugin gar nicht, sondern liest dein Vault-Verzeichnis direkt im Dateisystem. Obsidian muss dafür nicht einmal laufen. Gut dokumentiert, umfangreiches Toolset, von mir bisher nicht ausprobiert – aber ein etabliertes Projekt, das aktiv gepflegt wird.

Und das erwähnte eingestellte Plugin? MCP Tools for Obsidian war mit 87.000 Installationen das populärste MCP-Plugin im Community-Store, bis der Maintainer das Repo im Mai 2026 archivierte. Seine Begründung ist erfrischend ehrlich – er nutzt Obsidian schlicht nicht mehr und überlässt das Feld Entwicklern, die im Ökosystem zuhause sind. So sieht ein sauberer Abgang aus. Kein stilles Verrotten, kein „Maintenance Mode“ als Euphemismus.

Einrichtung in Obsidian

Du kannst die CLI oder das Desktop-Tool deiner Wahl bitten, die Einrichtung einfach für dich zu übernehmen – schreib den Link zum jeweiligen Repo (oder beim eingebauten Server den MCP-Endpoint) mit in den Prompt. Den Token findest du in den Settings des Local-REST-API-Plugins. Ein Rat aus der Praxis – lass Antigravity, Codex oder Claude Code den MCP-Eintrag erst einmal mit einem Platzhalter als Token erzeugen und füge den richtigen Token anschließend per Editor selbst ein. Dein API-Key hat im Chatverlauf eines Frontier-Modells nichts verloren.

Ansonsten legst du den entsprechenden Eintrag auch in den jeweiligen Settings schnell selbst an. Die genaue Konfiguration unterscheidet sich je nach gewähltem Weg ein wenig, ein Blick in die Doku ist Pflicht.

Kurzer Einschub zu Antigravity: Falls du dich wunderst, wo Gemini CLI geblieben ist – Google hat es im Juni 2026 für Consumer-Accounts abgeschaltet und durch Antigravity CLI ersetzt. Gleiche Aufgabe, neues Binary, agy statt gemini.

Agent Instruction File

Hier mal exemplarisch meine CLAUDE.md:

# CLAUDE.md

Guidance for Claude (Code, Desktop, CLI) when working with this Obsidian vault.

## Overview

This is an Obsidian vault using a PARA-inspired folder structure for knowledge management.

## AI Access Control (CRITICAL)

Before processing any file, check `ai` field in frontmatter:
- `ai: not allowed` → Do not read/edit/index. Treat as non-existent.
- `ai: index allowed` → Read and use as context, but **never** edit.
- `ai: all allowed` → Full permissions (read, index, edit).
- Missing/empty `ai` field → Treat as `not allowed` by default.

## Folder Structure

| Folder | Purpose |
| -------------- | ------------------------------------ |
| `0 Inbox` | Incoming notes |
| `1 Projekte` | Active projects |
| `2 Bereiche` | Concepts and thoughts |
| `3 Ressourcen` | Reference materials and brand assets |
| `4 Archiv` | Completed/inactive items |
| `5 System` | Templates, FileClasses, AI prompts |

### Folder-Specific Permissions

| Folder | Default `ai` value | Write Permission |
| ------------- | ------------------ | ---------------------------------------------------------- |
| `0 Inbox` | `all allowed` | Yes (no restrictions, just ask before deleting content) |
| `1 Projekte` | `all allowed` | Yes (ask before deleting or restructuring content) |
| `2 Bereiche` | `all allowed` | Yes (ask before deleting or restructuring content) |
| `3 Ressourcen` | `all allowed` | Yes (ask before deleting or restructuring content) |
| `4 Archiv` | `index allowed` | ❌ Read-only |
| `5 System` | `index allowed` | ❌ Read-only |

## Frontmatter Schema

All notes use this metadata structure (defined in `5 System/FileClasses/Standard.md`):

---
type: concept | shortnote | ressource | project | MOC
domain: Business | Blog | Dev | Other
status: seedling | in progress | completed | evergreen | archived
created: [handled by Linter Plugin]
updated: [handled by Linter Plugin]
ai: all allowed | index allowed | not allowed
tags: [tag1, tag2, etc.]
---

## Writing Files

- NEVER write to files with `ai: not allowed` or `ai: index allowed`
- ALWAYS use appropriate template from `5 System/Templates/`
- ALWAYS set correct frontmatter based on folder context
- Ask for confirmation before creating new files

### Naming Conventions

- **File Names:** Use the note's title as filename
- **MOCs:** Prefix with `_Dashboard` (e.g., `_Dashboard AI Research.md`)
- **No special characters:** Avoid /, \, :, " in filenames
- **Spaces allowed:** Use spaces for readability (e.g., `Prompt Engineering.md`)
- **Case:** Use proper capitalization (Title Case or sentence case)

### Linking & Relationships

- **Wiki-Links:** Use contextual `[[wikilinks]]` to connect new notes to existing relevant notes.

„AI Access Control (CRITICAL)“ regelt, was die KI tun darf. Das darf man nicht falsch verstehen: Das sind KEINE Guardrails. Wenn du der KI sagst, lösche oder bearbeite die Notiz, wird sie dich im besten Fall vorwarnen und noch mal nachfragen – es danach aber trotzdem tun, egal ob da „not allowed“ steht. Das Ganze ist ein doppelter Boden, und immerhin fragt die KI dich so vorher, weil es in der Instruction steht. Gleiches gilt für die „Folder Write Permission“.

Wer echte Guardrails will, muss eine Ebene tiefer ansetzen. Genau da wird der cyanheads-Server interessant – dessen ordnerbasierte Permissions und der Read-only-Schalter greifen auf Server-Ebene, bevor das Modell überhaupt einen Schreibzugriff absetzen kann. Eine Instruction kann ein Modell ignorieren. Einen 403 vom Server nicht.

Die „Folder Structure“ liefert, welcher Ordner im Vault wofür gedacht ist, das „Frontmatter Schema“ den Head mit den Meta-Daten der Datei – das hatte ich in einem eigenen Beitrag aufgedröselt. Alles, was danach noch kommt, sind spezifische Anweisungen für den Vault. Wie bei allen Agent Instruction Files solltest du dich so kurz wie möglich halten, weil davon alles ins Kontextfenster wandert – immer, in jeder Session.

Das kann es

Ich beschränke mich auf meine Erfahrungen mit Claude Code und Antigravity (vorher Gemini CLI) bzw. Gemini, da ich Codex dafür bisher schlicht nicht genutzt habe.

Du legst ein Projekt an (eigentlich ergibt in diesem Kontext nur der Vault-Ordner dafür Sinn) und legst dort die spezifisch angepasste Agent Instruction File ab. Ich empfehle dringend, das manuell zu tun und nicht einfach eine Datei über /init erzeugen zu lassen – was das Tool dabei zusammenschreibt, kennt weder deine Ordnerlogik noch deine Frontmatter-Regeln.

Wenn der MCP korrekt eingerichtet ist, steht dir alles zur Verfügung, was an Tools da ist.

Den ganzen Spaß nutze ich u. a. dafür, um meine notorisch zu volle Inbox einer Triage zu unterziehen – „Zeig mir alle Notizen aus 0 Inbox, die älter als X Tage sind, und fasse jede in zwei Sätzen zusammen.“ Oder auch, um ähnliche oder verwandte Einträge zusammenzulegen, sofern das Sinn ergibt. Beim Aufspüren von Zusammenhängen leistet die Anbindung ebenfalls gute Arbeit, etwa um Notizen sinnvoll untereinander zu verlinken und/​oder zu verschlagworten. Der Hauptfokus in meinem Fall ist aber der Inbox-Ordner.

Fallback oder Alternative: das offizielle Obsidian CLI

Wenn du auf den MCP verzichten möchtest oder einen Fallback brauchst – Obsidian verfügt seit Februar 2026 über ein offizielles Command Line Interface. Erst als Early-Access-Feature in Version 1.12.0, seit 1.12.4 ohne separaten Download für alle Desktop-Nutzer an Bord. Alles, was in der App geht, funktioniert auch im Terminal – inklusive einer richtig guten Suche über den gesamten Vault.

Der entscheidende Unterschied zu den Community-CLIs, die vorher diese Lücke füllten: Das offizielle CLI läuft durch Obsidians Runtime – dieselbe Logik, die auch in der App arbeitet. Ein move aktualisiert interne Links (sofern in den Vault-Einstellungen aktiviert), create zieht deine Templates korrekt, und Frontmatter wird als valides YAML geschrieben statt als Textwurst. Der Index bleibt dabei konsistent, nichts kollidiert mit laufenden Plugins.

Du musst Antigravity, Codex oder Claude Code natürlich noch mitteilen, dass sie das CLI benutzen dürfen bzw. sollen und in welchen Fällen. Ein Absatz in der Instruction File genügt.

Der Datenschutz- und Sicherheitsaspekt

Obsidian hat das schöne Feature des „local first“ – sprich, meine Daten liegen auf meinem System. Diese Souveränität gebe ich auf, wenn ich eine KI an meinen Vault hänge.

Wenn du einem Frontier-LLM Zugriff auf deinen Vault gibst (und sei es nur lesend), musst du im Hinterkopf behalten, dass du damit auch die Inhalte des Vaults an den jeweiligen Anbieter weitergibst. Das muss nicht datenschutzrechtlich relevant sein, kann es aber, sobald du mit persönlichen Daten oder Kundendaten in Obsidian hantierst. Gleiches gilt für spezifische Projektdaten, die z. B. unter NDA stehen.

Pragmatische Lösung: Mein Vault ist ein Second Brain und meine Knowledge Base – da gehören im Regelfall ohnehin keine Daten rein, die datenschutzrechtlich in irgendeiner Form relevant sind. Und für sicherheitskritische Daten brauche ich das ohnehin niemandem erzählen: Denn im Zweifelsfall hast du dafür einen eigenen, separaten Vault und lässt die KI dort draußen – so einfach.

Eine Randnotiz noch, weil sie in dieselbe Kerbe schlägt. Das Local-REST-API-Plugin hat kürzlich eine Path-Traversal-Lücke geschlossen, über die authentifizierte Anfragen aus dem Vault ausbrechen und beliebige Dateien auf dem Host lesen oder schreiben konnten. Der Fix ist da, die Lehre auch – wer eine API zu seinem Dateisystem betreibt, hält das Plugin aktuell. Ausnahmslos.

Beiträge der Serie

• Obsidian – mein digitales Gehirn, und warum ich nie wieder zurück möchte
• Obsidian-Vault organisieren: Frontmatter, Templates und Dataview
• Obsidian-Inbox automatisieren: n8n, Telegram und KI