Gefunden beim Versuch, F1 mit einem ECHTEN MCP-Call abzunehmen statt
nur mit dem initialize-Handshake.
Befund:
- Container-Env GITEA_ACCESS_TOKEN = a9317c68... -> Gitea antwortet 401
- ~/.secrets/credentials.env (SSoT) = bc12ad19... -> Gitea antwortet 200
- Gitea selbst war durchgehend erreichbar (/api/v1/version -> 200)
- NICHT durch den Bind-Umbau verursacht: Token-Hash vor und nach dem
Recreate identisch. Der MCP war schon vorher funktionsunfaehig.
Fix: Container mit dem Store-Token neu gebaut, Token per stdin (nicht
argv). Abnahme jetzt ein echter tools/call user__get_my_userinfo ->
login=admin id=1.
Lehre (im F1-Eintrag festgehalten): ein initialize-Handshake beweist
nur, dass der MCP-Prozess lebt - er liefert serverInfo auch dann, wenn
jeder echte Aufruf am Backend-Token scheitert. Fuer MCPs mit
Backend-Credential ist die gueltige Abnahme ein tools/call, der das
Backend wirklich anfasst. Gleiches Muster wie "frische DHCP-Lease statt
Registration-Table" bei WLAN.
Verstaerkt F5: Container-Envs driften vom Credential-Store, weil sie
ihn nie lesen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph Emsenhuber
bc0bf316e1