SDK docs

SDK-Wissensdatenbank-(MCP-basiert)-–-Nutzung-des-bestehenden-Docs-Repos

3 Min. Lesezeit

StatusTypeRelevance

1. Ausgangssituation

Dieses Repository soll als projektübergreifende Wissensdatenbank dienen und:

  • in Codex (via MCP) verfügbar sein
  • von eigenen Tools genutzt werden

Dieses Dokument beschreibt die Nutzung als Wissensbasis.

2. Zielbild

Docs-Repo (Single Source of Truth)
        ↓
lokaler Checkout / Mirror
        ↓
Filesystem MCP Server
        ↓
Codex + interne Tools

Kein Monorepo.
Keine Duplikation der Inhalte.
Eine zentrale Quelle.

3. Setup

3.1 Docs-Repo lokal verfügbar machen

Der Filesystem-MCP-Server arbeitet ausschließlich auf lokalen Pfaden.

→ erforderlich:

git clone <docs-repo> <local-docs-repo-path>

Wichtig:

  • stabiler, absoluter Pfad
  • regelmäßiges Update (git pull oder automatisiert)

3.2 MCP Filesystem Server anbinden

codex mcp add sdk-knowledge -- npx -y @modelcontextprotocol/server-filesystem <local-docs-repo-path>

Alternativ über Konfiguration:

## ~/.codex/config.toml
[mcp_servers.sdk-knowledge]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "<local-docs-repo-path>"]
enabled = true

3.3 Nutzung in Projekt-Repos

Minimal erforderlich:

## AGENTS.md
 
### Wissensbasis
 
Nutze den MCP-Server "sdk-knowledge" (Docs-Repo) für:
 
- SDK-Standards
- API-Dokumentation
- Architekturentscheidungen
 
### Priorität
 
1. Code im aktuellen Repo
2. projektspezifische Doku
3. zentrales Docs-Repo

Ohne diese Anweisung:

  • Zugriff ist technisch vorhanden
  • Nutzung aber nicht zuverlässig

4. Anforderungen an das Docs-Repo

Das bestehende Repo wird zur Wissensdatenbank. Dafür sind folgende Mindestanforderungen notwendig:

4.1 Struktur (Vorschlag)

docs/
  standards/
  apis/
  sdk/
  runbooks/
  architecture/
  projects/

4.2 Dokumentqualität (entscheidend)

Jedes Dokument sollte enthalten:

  • Zweck / Scope
  • Gültigkeitsbereich
  • Owner
  • Datum (“Last reviewed”)
  • ggf. Ablösung älterer Versionen

Beispiel:

 
## SDK Authentication Pattern
 
Status: active
Owner: Platform Team
Last reviewed: 2026-03-30
Applies to: all SDK integrations

Begründung:

Der Filesystem-MCP-Server liefert nur Zugriff, keine inhaltliche Bewertung.

5. Nutzung außerhalb von Codex (API / eigene Tools)

5.1 Wichtiger Punkt

  • MCP ist nicht Teil der OpenAI API
  • API-Calls sehen das Docs-Repo nicht automatisch
    → Retrieval muss selbst implementiert werden

5.2 Architektur

z.B.

Input
→ Transkript
→ Suche im Docs-Repo (lokal oder via MCP)
→ relevante Dokumente extrahieren
→ Prompt bauen
→ OpenAI API

5.3 Minimalvariante (empfohlen)

Statt MCP:

  • direkte Dateizugriffe
  • einfache Suche (Dateinamen / grep)

→ oft stabiler und einfacher

6. Features

Funktional

  • zentrale Wissensquelle (Docs-Repo)
  • projektübergreifende Nutzung
  • Integration in Codex via MCP
  • Nutzung in eigenen Pipelines möglich

Technisch

  • Zugriff auf Dateien und Struktur
  • einfache Suche
  • global einbindbar (kein Setup pro Repo)

7. Limitationen

7.1 Kein intelligentes Retrieval

  • keine semantische Suche
  • kein Ranking
  • keine Konfliktauflösung

→ Qualität hängt direkt vom Docs-Repo ab

7.2 Nicht deterministische Nutzung

  • Codex nutzt MCP nicht immer automatisch
  • Steuerung notwendig über:
    • AGENTS.md
    • Prompting

7.3 Skalierung

Mit wachsender Dokumentmenge:

  • schlechtere Auffindbarkeit
  • mehr irrelevanter Kontext
  • steigende Inkonsistenz

7.4 Synchronisation

  • lokaler Checkout kann veralten
  • erfordert:
    • manuelles git pull oder
    • automatisches Sync

7.5 Sicherheit

  • Zugriff auf komplettes Verzeichnis
  • falsche Konfiguration → unnötige Exponierung von Daten

8. Anforderungen

Technisch

  • Node.js (für MCP Server via npx)
  • Codex CLI oder kompatibler MCP-Client
  • lokaler Zugriff auf Docs-Repo

Organisatorisch

entscheidend für Funktion:

  • klare Struktur
  • konsistente Benennung
  • definierte Owner
  • regelmäßige Pflege

Ohne diese Punkte:
→ hohe Fehlerwahrscheinlichkeit

9. Erweiterungspfad

Wechsel zu komplexerer Lösung sinnvoll bei:

  • viele Dokumente (> ~100)
  • häufige Fehlinterpretationen
  • mehrere Wissensquellen
  • Bedarf an gezielter Suche

Dann:

→ eigener MCP-Server mit:

  • search_docs
  • get_doc
  • Ranking / Filter

10. Fazit

  • Das bestehende Docs-Repo kann direkt als Wissensdatenbank genutzt werden
  • Filesystem-MCP ist der schnellste Integrationsweg
  • Hauptfaktor für Qualität ist nicht MCP, sondern:

→ Struktur und Pflege des Docs-Repos

Graph View

Zuletzt bearbeitete Seiten