Ziel
Die MCP-Dokumentation bildet den tatsächlichen OAuth-Implementierungsstand korrekt ab. Integratoren sehen sofort, dass OAuth 2.1 + PKCE + DCR funktioniert (seit v2.8.0) und welche Konfigurationsoptionen es gibt.
Warum jetzt
docs/mcp-api.md:102-182 behauptet fälschlich, OAuth liefere "501 Not Implemented" — der Code implementiert OAuth aber funktional. Dadurch wissen Integratoren nicht, dass DCR funktioniert.
docs/agent-integration.md hat keine opencode-Sektion für den OAuth-Pfad (nur Bearer-Token-Pfad).
- Nach den Änderungen (persistente Registry + Refresh-Token) muss die Doku den aktuellen Stand abbilden.
Aktueller Stand / Evidenz
docs/mcp-api.md:112-113: Tabelle zeigt /mcp/oauth/authorize und /mcp/oauth/token als "501"
docs/mcp-api.md:147-158: Beispiel-Responses zeigen 501-Fehler — obwohl der Code 200/302 zurückgibt
docs/mcp-api.md:160-182: "openCode Integration Guide" beschreibt nur Bearer-Token-Pfad, sagt "well-known endpoints exist only to prevent client crashes"
docs/agent-integration.md: Keine opencode-Sektion für OAuth DCR + PKCE + Refresh
internal/mcp/serverbootstrap/wellknown.go:38-52: Endpoints liefern reale Metadata (issuer, authorize/token/register endpoints)
In Scope
docs/mcp-api.md — Sektion "OAuth Well-Known Endpoints" komplett überarbeiten:
- Tabelle:
/mcp/oauth/authorize und /mcp/oauth/token von 501 → 200/302/400
- OAuth-Flow als unterstützt dokumentieren mit kurzem Sequenz-Diagramm (oder Textablauf)
- Hinweis: Client-Registrierungen sind jetzt persistent (nach Issue 1)
- Hinweis: Refresh-Token wird unterstützt (nach Issue 2)
- opencode-Sektion: beide Pfade dokumentieren (DCR/OAuth mit PKCE oder statischer Bearer-Token)
- TTL-Defaults + Config-Optionen dokumentieren
docs/agent-integration.md:
- Neuen Abschnitt "OAuth Dynamic Client Registration" mit opencode-Beispiel
- Erwähnen, dass refresh-token-Support selteneres Re-Authentifizieren ermöglicht
CHANGELOG.md: Eintrag unter nächster Version
Out of Scope
- Code-Änderungen (separate Issues)
- Doku für andere MCP-Clients als opencode
- Tutorials für andere Passwort-Manager
Akzeptanzkriterien
Risiken / Abhängigkeiten
- Setzt Änderungen aus Issue 1 (Persistenz) und Issue 2 (Refresh-Token) voraus
- Sequenz-Diagramm kann durch reinen Textablauf ersetzt werden, wenn Diagramm-Tool nicht verfügbar
Ziel
Die MCP-Dokumentation bildet den tatsächlichen OAuth-Implementierungsstand korrekt ab. Integratoren sehen sofort, dass OAuth 2.1 + PKCE + DCR funktioniert (seit v2.8.0) und welche Konfigurationsoptionen es gibt.
Warum jetzt
docs/mcp-api.md:102-182behauptet fälschlich, OAuth liefere "501 Not Implemented" — der Code implementiert OAuth aber funktional. Dadurch wissen Integratoren nicht, dass DCR funktioniert.docs/agent-integration.mdhat keine opencode-Sektion für den OAuth-Pfad (nur Bearer-Token-Pfad).Aktueller Stand / Evidenz
docs/mcp-api.md:112-113: Tabelle zeigt/mcp/oauth/authorizeund/mcp/oauth/tokenals "501"docs/mcp-api.md:147-158: Beispiel-Responses zeigen 501-Fehler — obwohl der Code 200/302 zurückgibtdocs/mcp-api.md:160-182: "openCode Integration Guide" beschreibt nur Bearer-Token-Pfad, sagt "well-known endpoints exist only to prevent client crashes"docs/agent-integration.md: Keine opencode-Sektion für OAuth DCR + PKCE + Refreshinternal/mcp/serverbootstrap/wellknown.go:38-52: Endpoints liefern reale Metadata (issuer, authorize/token/register endpoints)In Scope
docs/mcp-api.md— Sektion "OAuth Well-Known Endpoints" komplett überarbeiten:/mcp/oauth/authorizeund/mcp/oauth/tokenvon 501 → 200/302/400docs/agent-integration.md:CHANGELOG.md: Eintrag unter nächster VersionOut of Scope
Akzeptanzkriterien
docs/mcp-api.mdzeigt korrekte HTTP-Status-Codes für alle OAuth-Endpointsdocs/mcp-api.mdhat ein kurzes Sequenz-Diagramm oder Flow-Description des OAuth-Ablaufsdocs/mcp-api.mddokumentiert die Config-Optionenoauth.access_token_ttlundoauth.refresh_token_ttldocs/agent-integration.mdhat einen Abschnitt "OAuth Dynamic Client Registration" mit opencode-BeispielCHANGELOG.mdhat Eintrag für die OAuth-VerbesserungenRisiken / Abhängigkeiten