API-Referenz

POST /mcp
Content-Type: application/json
Authorization: Bearer mk_...

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "TOOL_NAME",
    "arguments": { ... }
  }
}

memory_store

Speichert Content. Fuehrt die Extraction-Pipeline aus: LLM-Extraktion → Confidence-Routing → Embedding → Verschlüsselung.

Input

Output

{
  "stored": [...],          // Direkt gespeichert (Confidence ≥ 0.85)
  "drafts": [...],          // Als Draft zur Prüfung (0.4-0.84)
  "pm_matches": [...],      // Ausgeloeste Prospective-Memory-Ziele
  "conflicts": [...]        // Erkannte Konflikte
}

memory_retrieve

Sucht Memories per Hybrid-Retrieval. Drei Modi: Relevanz (Default), chronologisch, Profile.

Input

Output

{
  "memories": [
    {
      "id": "...",
      "content": "...",
      "entities": [              // Multi-Entity Support
        { "type": "person", "id": "lisa-mueller" },
        { "type": "projekt", "id": "q3-relaunch" }
      ],
      "entity_type": "person",   // Deprecated (erster Entity)
      "entity_id": "lisa-mueller",
      ...
    }
  ],
  "semantic_profiles": [...],   // Verdichtete Entity-Profile
  "context_tokens": 1234        // Token-Verbrauch
}

Jede Memory enthaelt ein entities Array mit allen verknuepften Entitaeten ([{type, id}]). Ein Fakt kann mehrere Entitaeten haben, z.B. eine Entscheidung die mehrere Personen oder Projekte betrifft. Die Felder entity_type und entity_id sind weiterhin vorhanden (Backwards Compatibility), enthalten aber nur die erste Entitaet.

memory_draft_review

Prüft Drafts: akzeptieren, ablehnen oder bearbeiten. Die Engine lernt aus Entscheidungen (Confidence-Kalibrierung).

Input

memory_set_goal

Erstellt eine zukunftsgerichtete Erinnerung. Zeitbasiert (Deadline) oder eventbasiert (Trigger-Bedingung).

Input

memory_briefing

Generiert ein LLM-Briefing aus aktiven Memories, Drafts und ausgeloesten Goals.

Input

Weitere Tools

Dynamische Tool-Descriptions

Die Engine generiert Tool-Descriptions dynamisch aus der Domain-Config deines Vaults. Statt generischer Beschreibungen sieht das LLM die konkreten Categories, Entity-Types und verfuegbaren Vaults.

Die Descriptions werden bei jedem tools/list Request frisch generiert (5-Min-Cache). Aenderungen an der Domain-Config sind automatisch sichtbar.

memory_link

Verknuepft zwei Memories mit einer typisierten Relation. Erstellt persistente Graph-Verbindungen fuer Kausalketten, Widersprueche oder thematische Links.

Parameter	Typ	Beschreibung
source_id	string	Quell-Memory ID
target_id	string	Ziel-Memory ID
relation_type	enum	caused_by, contradicts, relates_to
metadata	object?	Optionale Begruendung

memory_replay

Zeitreise: zeigt den Wissensstand deines Vaults zu einem beliebigen Zeitpunkt. Inkludiert Fakten die spaeter archiviert wurden wenn sie zum angefragten Zeitpunkt noch aktiv waren.

Parameter	Typ	Beschreibung
timestamp	string	ISO 8601 Zeitpunkt (Pflichtfeld)
query	string?	Optionale Suche auf zeitgefiltertem Bestand
category	string?	Kategorie-Filter
entity_type	string?	Entity-Typ Filter (filtert ueber das entities Array)
limit	number?	Max Ergebnisse (Default: 50)

Response-Format identisch zu memory_retrieve. Semantic Profiles zeigen den aktuellen Stand, nicht den historischen.

memory_retrieve: Graph-Modus

Mit sort_by: 'graph' traversiert memory_retrieve den Relationen-Graph ab einer Start-Memory.

Parameter	Typ	Beschreibung
sort_by	'graph'	Aktiviert Graph-Traversal
start_memory_id	string	Startpunkt der Traversierung (Pflichtfeld)
relation_types	string[]?	Filter auf bestimmte Relationstypen
max_depth	number?	Traversierungstiefe 1-5 (Default: 3)

Response enthaelt zusaetzlich ein relations Array mit source_id, target_id, type, confidence, created_by und depth. Bidirektionale Traversierung fuer symmetrische Relationen (contradicts, relates_to).