`server_info` returns success even when auth is expired — misleads as health check

[josuebustosn]

Summary

server_info returns status: success regardless of authentication state, because it's
a local call that doesn't touch Google. When used as a lightweight "is the MCP healthy?"
probe before firing auth-dependent tools, it's a false positive.

Repro

1. Authenticate via nlm login (successful)
2. Let cookies expire (or invalidate manually)
3. Call server_info → status: success, returns version info
4. Call notebook_list → status: error, "Authentication expired"

Expected

Either:

• server_info includes an auth_status field (valid | expired | unknown), or
• Docs/tool description clarify that server_info is a local metadata call and does NOT
  validate auth state

Why it matters

Agentic workflows (Claude Code with GSD-style orchestration, autonomous research phases)
naturally reach for server_info as a cheap pre-flight check before spawning research
tools that hit Google. Discovering after a downstream failure that server_info never
validated auth is wasted cycles and confusing debug sessions.

Environment

• notebooklm-mcp-cli v0.5.25
• Python 3.13.7 (uv-managed)
• Windows 11

[jacob-bd]

You were right to call this out. server_info was basically "is the process alive," not "will Google calls work," and that is a bad surprise when you are orchestrating agents.

v0.5.26 adds an auth_status field (configured / stale / not_configured / error) based on what we can see locally (tokens on disk and rough age). It still does not ping Google on purpose, but the tool description now says that out loud so it does not masquerade as a full auth probe.

Hope that saves you a few wasted agent loops. If you want a true live check later, we can talk about a separate tool or a flag.