docs: fix /health → /health/live, refresh stale mode-detection log examples (#766)

Issue #766 reported that the running.md quick-start tells users to
`curl http://localhost:8000/health`, which returns 404 — the server
only registers `/health/live` and `/health/ready` (K8s-style probes).
The same section also listed BasicAuth and OAuth startup log lines
(`BasicAuth mode detected …`, `OAuth mode detected …`) that no longer
exist anywhere in the codebase.

Update running.md and troubleshooting.md to point at the real
endpoints, explain liveness vs readiness, and replace the fictional
log examples with messages the server actually emits today. Also
clarify that the per-session BasicAuth messages only appear after the
first MCP client connects, which is the second symptom the reporter
hit.

Docs-only change; code paths and endpoint surface unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Chris Coutinho
2026-05-12 07:35:49 +02:00
co-authored by Claude Opus 4.7
parent f8e48f1c53
commit e78e191818
2 changed files with 37 additions and 16 deletions
+35 -14
View File
@@ -313,30 +313,51 @@ MCP clients (like Claude Desktop, LLM IDEs) can connect to your server:
### Check Server Health
The server exposes two Kubernetes-style probe endpoints:
```bash
# Test if server is responding
curl http://localhost:8000/health
# Liveness — server process is up (always 200 if running)
curl http://localhost:8000/health/live
# Expected response: HTTP 200 OK
# Readiness — server can reach Nextcloud and (if enabled) Qdrant
curl http://localhost:8000/health/ready
```
### Check OAuth Configuration
`/health/live` returns `200 OK` as long as the process is running. `/health/ready`
returns `200 OK` with a JSON body describing each dependency check, or `503` with
the same JSON body listing which checks failed — use the readiness probe when
troubleshooting connectivity to Nextcloud or Qdrant.
Look for these log messages on startup:
### Check Deployment Mode
**OAuth mode:**
The server logs the detected deployment mode on startup. Look for these
messages in the container logs:
**At server boot (all modes):**
```
INFO ✅ Configuration validated successfully for <mode> mode
INFO Configuring MCP server for <mode> mode
INFO Health check endpoints enabled: /health/live, /health/ready
```
`<mode>` is one of `single_user_basic`, `multi_user_basic`, or
`oauth_single_audience`, matching the `MCP_DEPLOYMENT_MODE` setting.
**Additional OAuth-mode messages (at server boot):**
```
INFO OAuth mode detected (NEXTCLOUD_USERNAME/PASSWORD not set)
INFO Configuring MCP server for OAuth mode
INFO OIDC discovery successful
INFO OAuth client ready: <client-id>...
INFO OAuth initialization complete
INFO OAuth configuration complete
```
**BasicAuth mode:**
**Additional single-user BasicAuth messages (per MCP session):**
These fire when the first MCP client connects, not at server boot — if you
have just started the container and no client has connected yet, you will not
see them in the logs:
```
INFO BasicAuth mode detected (NEXTCLOUD_USERNAME/PASSWORD set)
INFO Initializing Nextcloud client with BasicAuth
INFO Starting MCP session in single-user BasicAuth mode
INFO Creating shared Nextcloud client with BasicAuth
INFO Client initialization complete
```
---
@@ -416,7 +437,7 @@ Common issues:
### Can't connect to server
1. Verify server is running: `curl http://localhost:8000/health`
1. Verify server is running: `curl http://localhost:8000/health/live`
2. Check firewall settings
3. Verify host binding (use `0.0.0.0` to allow network access)
4. Check OAuth authentication if enabled
+2 -2
View File
@@ -290,10 +290,10 @@ kill <pid>
2. **Test connectivity:**
```bash
# Test from same machine
curl http://localhost:8000/health
curl http://localhost:8000/health/live
# Test from network (if using --host 0.0.0.0)
curl http://<server-ip>:8000/health
curl http://<server-ip>:8000/health/live
```
3. **Check firewall:**