KI und MCP
KI und MCP
1. AURA AI Context Layer
Zusätzlich zur Webseite braucht AURA eine eigene KI-Kontextschicht. Eine Webseite allein reicht für KI nicht aus.
Die AI Context Layer stellt geprüften, versionierten und zitierbaren Kontext bereit. Sie enthält:
normalisierte Markdown-Chunks
strukturierte Metadaten
Service-/Dependency-Graph
ADRs
C4-Modelle
API-Spezifikationen
Event-Spezifikationen
Jira-Verknüpfungen
PR-/Commit-Verknüpfungen
Repo-Links
Embeddings / Vektorindex
Volltextindex
Berechtigungsinformationen
Quellenangaben
KI-Assistenten sollen nicht beliebige oder veraltete Dokumentation lesen, sondern geprüften, versionierten und quellenbasierten Architekturkontext erhalten.
2. Quellen und Zitierbarkeit
Jede KI-Antwort auf Basis von AURA sollte nachvollziehbar sein. Idealerweise kann eine KI-Antwort sagen:
Ich beziehe mich auf:
- payment-service / commit a81f3c2
- ADR-0042
- docs/architecture/containers.md
- Jira PAY-123
- PR #847
AURA sollte deshalb niemals nur rohe Embeddings ohne Quellenverwaltung verwenden. Jeder Chunk braucht Metadaten:
source_repo: payment-service
source_commit: a81f3c2
source_path: docs/architecture/containers.md
owner: team-payments
snapshot_time: 2026-05-09T14:30:00Z
documentation_status: validated
visibility: internal
3. AURA MCP Server
Ein MCP Server ist ein sehr passender Baustein für AURA. Über MCP kann AURA Kontext, Prompts und Tools für KI-Assistenten bereitstellen.
AURA kann dadurch mit unterschiedlichen KI-Clients verbunden werden, ohne dass jeder Client die AURA-Logik selbst implementieren muss.
4. MCP Resources
AURA stellt über MCP Resources lesbare Architekturinformationen bereit:
aura://services/payment-service/overview
aura://services/payment-service/c4/context
aura://services/payment-service/c4/container
aura://services/payment-service/adrs
aura://services/payment-service/apis
aura://products/commerce-platform/landscape
aura://features/PAY-123/related-systems
aura://teams/team-payments/services
Diese Resources sind primär Kontextquellen für KI-Modelle.
5. MCP Tools
AURA stellt außerdem Tools bereit, die KI-Assistenten aktiv aufrufen können:
search_architecture(query)
get_service_context(serviceName)
get_related_services(serviceName)
get_adr_history(serviceName)
analyze_feature_request(ticketId)
find_repositories_for_feature(description)
get_code_context(repo, path)
compare_pr_with_documentation(prId)
check_documentation_drift(serviceName)
Diese Tools erlauben KI-Assistenten, gezielt Kontext abzurufen und Analysen durchzuführen.
6. MCP Prompts
AURA stellt standardisierte Prompts für wiederkehrende Architektur-Workflows bereit:
analyze-feature-impact
prepare-architecture-review
check-documentation-drift
explain-service-to-new-developer
generate-adr-draft
review-pr-architecture-impact
summarize-system-landscape
Diese Prompts sorgen dafür, dass KI-Analysen konsistenter und besser prüfbar werden.
7. Feature-Erstellung mit AURA
Ein zentraler Mehrwert von AURA entsteht schon vor der Implementierung. Bei einem neuen Feature oder Jira-Ticket kann AURA helfen, den richtigen Einstiegspunkt zu finden.
Neues Feature / Jira Ticket
|
v
AURA analysiert Beschreibung
|
v
AURA findet vermutlich betroffene Produkte, Systeme, Services, APIs und Events
|
v
AURA gibt erste technische Einschätzung
|
v
Entwickler oder KI-Agent bekommt gezielten Kontext
|
v
Implementierung im richtigen Repo mit weniger Blindflug
Mögliche Fragen an AURA:
- Welche Systeme sind wahrscheinlich von diesem Feature betroffen?
- Welches Repository muss ich ändern?
- Welche APIs sind relevant?
- Gibt es alte ADRs dazu?
- Welche Risiken gibt es?
- Welche Teams müssen eingebunden werden?
- Welche Tests oder Contracts sind kritisch?
- Welche Services könnten Nebenwirkungen haben?
8. KI-Use-Cases im Überblick
Feature-Analyse
Analysiere dieses Jira Ticket.
Welche Services sind betroffen?
Welche Repositories muss ich ansehen?
Welche APIs könnten betroffen sein?
Welche ADRs sind relevant?
PR Review
Analysiere diesen PR.
Ist die Architektur-Doku aktuell?
Gibt es fehlende ADRs?
Sind neue Abhängigkeiten dokumentiert?
Onboarding
Erkläre mir den billing-service.
Welche Rolle hat er im Gesamtsystem?
Welche Entscheidungen sind wichtig?
Welche Risiken gibt es?
Architektur-Governance
Welche Services haben veraltete Doku?
Welche kritischen Services haben keine C4-Diagramme?
Welche ADRs fehlen?
Wo gibt es Architekturdrift?
9. AURA als Kontextgrenzen-Management
Ein wichtiges Ziel von AURA ist, KI-Kontextgrenzen zu kontrollieren. Statt einem KI-Assistenten ein komplettes Repository oder eine ganze Organisation zu geben, liefert AURA gezielten Kontext:
betroffene Services
relevante ADRs
wichtige Diagramme
passende API-Specs
kritische Risiken
konkrete Codepfade bei Bedarf
Das reduziert:
- Kontextüberladung
- Halluzinationen
- irrelevante Informationen
- Kosten
- Sicherheitsrisiken
- falsche Architekturannahmen
AURA ist damit ein kontrollierter Kontextfilter für KI-Systeme.
10. Retrieval Layer
AURA sollte Retrieval nicht nur semantisch machen. Gute KI-Suche braucht mehrere Ebenen:
Keyword Search
Semantic Search
Graph Search
Metadata Filtering
Ownership Filtering
Permission Filtering
Freshness Filtering
Trust Filtering
Beispiel:
Suche alle produktiven Services im Payment-Domain-Kontext,
die invoice-created Events konsumieren,
deren Dokumentation validiert ist,
und die für Jira PAY-123 relevant sein könnten.
Das ist mehr als klassische Volltextsuche.
11. AURA mit Code-Zugriff
Da AURA weiß, wo ein Service im Repository liegt, kann AURA theoretisch auch Code-Kontext bereitstellen. Das ist mächtig, aber sicherheitskritisch.
Deshalb sollte strikt getrennt werden:
AURA Documentation Context:
immer verfügbar für berechtigte Nutzer
AURA Code Context:
nur bei Bedarf
nur mit Berechtigung
nur gezielte Dateien
keine Secrets
auditierbar
Der KI-Assistent sollte nicht pauschal alle Repositories laden. Stattdessen sollte er über AURA gezielt fragen:
Gib mir die relevanten Dateien für Feature X im payment-service.
AURA entscheidet dann:
- Welche Repos sind relevant?
- Welche Dateien sind relevant?
- Darf dieser Nutzer sie sehen?
- Wie viel Kontext ist sinnvoll?
- Welche Quellen müssen zitiert werden?
→ Sicherheit und Governance im Detail
Weiterlesen
- Nächste Seite: Governance und Drift — Sicherheitsmodell, Service Graph, Trust
- Ingest und Portal — wie der Knowledge Store erzeugt wird
- Architektur — Einordnung von MCP in das Gesamtbild