Andere MCP-Clients
WhyVault ist ein gehosteter Remote-MCP-Server: ein Endpoint, Streamable HTTP, OAuth 2.1 – jeder Client, der Remote-MCP spricht, kann sich verbinden.
Jeder Client, der entfernte MCP-Server unterstützt, kann sich mit WhyVault verbinden. Die Adresse ist https://mcp.whyvault.io.
- Transport: Streamable HTTP
- Anmeldung: OAuth 2.1 mit Authorization Code und PKCE (S256)
- Registrierung: Dynamic Client Registration (RFC 7591)
- Ohne OAuth: Clients senden einen Zugangsschlüssel aus Agenten verbinden als
Authorization: Bearer wv_….
Die Metadaten stehen unter /.well-known/oauth-protected-resource auf mcp.whyvault.io; ohne Anmeldung antwortet der Server mit 401 und einem Verweis darauf. Eine Beschreibung des Servers (Server Card) liegt unter https://whyvault.io/.well-known/mcp/server-card.json.
Voraussetzungen
- Remote-MCP über Streamable HTTP. Clients, die nur lokale Server starten (stdio), brauchen eine Brücke – siehe Clients nur mit stdio.
- Entweder OAuth 2.1 mit PKCE und Dynamic Client Registration – der Client öffnet ein Anmeldefenster und kümmert sich selbst um die Tokens –
- oder eigene Header, damit du einen Zugangsschlüssel mitschicken kannst.
- WhyVault: jedes Konto, auch Free. Nichts zu installieren – der Server läuft gehostet, in der EU (Frankfurt) und DSGVO-konform.
Endpoint und Transport
| Was | Wert |
|---|---|
| Endpoint | https://mcp.whyvault.io – die Wurzel, ohne Pfad |
| Transport | Streamable HTTP, zustandslos (jede Anfrage steht für sich) |
| Anmeldung | Header Authorization: Bearer … – OAuth-Token oder wv_…-Schlüssel |
| Servername | WhyVault |
Der Server ist zustandslos: Es gibt keine Sitzung, die am Leben bleiben muss. Bricht eine Verbindung ab, geht es mit der nächsten Anfrage einfach weiter. Den älteren Transport HTTP+SSE gibt es nicht – fragt dein Client nach dem Transport, wähl HTTP oder Streamable HTTP, nicht SSE.
So läuft die Anmeldung per OAuth
Discovery. Der Client ruft den Endpoint ohne Token auf und bekommt 401 mit WWW-Authenticate: Bearer resource_metadata="…". Dieses Dokument (RFC 9728) nennt den Authorization Server.
Registrierung. Der Client liest die Metadaten des Authorization Servers (RFC 8414) und registriert sich selbst (RFC 7591). Für ältere Clients, die die Metadaten beim MCP-Host suchen, reicht https://mcp.whyvault.io/.well-known/oauth-authorization-server sie durch.
Anmeldung und Zustimmung. Der Client öffnet die Autorisierungs-Adresse mit PKCE (S256). Du meldest dich bei WhyVault an und stimmst auf der Zustimmungsseite zu – dort steht der Name, den der Client angemeldet hat.
Tokens. Der Client tauscht den Code gegen ein Access Token und schickt es bei jeder Anfrage als Bearer-Header mit. Tokens leben kurz; der Client erneuert sie am Token-Endpoint.
Scopes: keine eintragen. Der Authorization Server kennt nur Standard-Scopes und lehnt unbekannte wie vault:read ab. Was eine Verbindung darf, stellst du in WhyVault unter Agenten verbinden ein – lesen, schreiben und, wenn du es erlaubst, löschen.
Die Rechte bestimmen die Werkzeugliste
Eine Verbindung sieht nur die Werkzeuge, die sie nutzen darf. Mit Leserecht: vault_overview, search_notes, read_note, list_notes, get_backlinks. Mit Schreibrecht zusätzlich create_note, append_to_note, update_section und replace_note. delete_note erscheint erst, wenn du das Löschen erlaubst. Details: MCP-Tools.
Beispiele
MCP Inspector – zum Testen, ob die Verbindung steht:
npx @modelcontextprotocol/inspector --cli https://mcp.whyvault.io --transport http --method tools/list --header "Authorization: Bearer wv_…"VS Code – in .vscode/mcp.json (Achtung: servers und type, anders als bei Cursor):
{
"servers": {
"whyvault": {
"type": "http",
"url": "https://mcp.whyvault.io",
"headers": { "Authorization": "Bearer wv_…" }
}
}
}Gemini CLI:
gemini mcp add --transport http whyvault https://mcp.whyvault.io -H "Authorization: Bearer wv_…"Clients nur mit stdio
Clients, die nur lokale Prozesse starten können, erreichen WhyVault über die Brücke mcp-remote. Sie übernimmt die Anmeldung per OAuth im Browser:
{
"mcpServers": {
"whyvault": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.whyvault.io"]
}
}
}Fehlerbehebung
404 oder „Not found“
Du hast einen Pfad angehängt. Auf mcp.whyvault.io antwortet nur die Wurzel – https://mcp.whyvault.io/mcp oder /sse liefern 404.
Der Client versucht SSE und scheitert
Stell den Transport auf HTTP oder Streamable HTTP. Kennt der Client nur SSE, nimm mcp-remote.
invalid_scope bei der Anmeldung
Der Client schickt eigene Scopes mit. Entferne sie aus seiner Konfiguration – Scopes braucht es nicht.
Das Anmeldefenster öffnet sich nicht
Manche Clients unterstützen keine Dynamic Client Registration oder haben keinen Browser. Nimm dann einen Zugangsschlüssel im Header. Öffnet sich der Link aus der E-Mail in einem anderen Browser, gib den Code aus der E-Mail im Anmeldefenster ein.
401, obwohl es schon lief
Zugangsschlüssel oder Verbindung wurden unter Agenten verbinden widerrufen, oder das Token ist abgelaufen und der Client hat es nicht erneuert. Melde dich neu an oder leg einen neuen Schlüssel an.
Die Schreib-Werkzeuge fehlen
Die Verbindung darf nur lesen. Ändere ihre Rechte in WhyVault und verbinde neu, damit der Client die Werkzeugliste neu lädt.
Schreiben scheitert mit „Zu viele Änderungen“
Eine Verbindung darf bis zu 30 Änderungen pro Minute machen. Das Werkzeug antwortet mit einem Fehlerergebnis; warte eine Minute und bündle Änderungen.
Häufige Fragen
Gibt es eine lokale Version?
Nein. WhyVault läuft gehostet; für Clients nur mit stdio nimm mcp-remote.
Welcher Name steht in meinem Verlauf?
Der Name, den der Client per OAuth angemeldet hat, oder der Name, den du dem Zugangsschlüssel gegeben hast.
Können mehrere Clients dasselbe Vault nutzen?
Ja – darum geht es. Jeder Client bekommt eine eigene Verbindung mit eigenen Rechten, und alle lesen und schreiben dieselben Notizen.