NLM Expert Research MCP — Frontier
# NotebookLM Expert Research MCP for Perplexity
Independent remote MCP for one authorized owner. It exposes a compact, read-oriented NotebookLM surface over authenticated Streamable HTTP and keeps its browser/auth profile, metadata, token, runtime and service separate from the Claude Desktop product.
## Product boundary
- `PRODUCT_MODE=PRIVATE_SINGLE_OWNER`
- One authorized Google identity and one owner-controlled remote MCP client.
- No multi-user/SaaS account model.
- Notebook/source bodies are returned only to the authenticated caller and are not persisted or logged.
- The NotebookLM adapter is an explicit `HIGH_EXTERNAL_UI_DEPENDENCY`; v1 prefers the upstream internal RPC path and fails closed when its contract or UI fallback drifts.
## Local verification
```powershell
npm.cmd install
npm.cmd run certify:local
```
The automated suite uses `TEST_ONLY_FAKE_ADAPTER` only under `NODE_ENV=test`. These checks certify server behavior, isolation and MCP protocol mechanics; they are not evidence of live NotebookLM authentication or research.
## Staging runtime
Copy `.env.example` to a root-readable staging environment file, generate a unique random token of at least 32 characters, and keep the service bound to `127.0.0.1`. Use the artifacts in `deployment/` for the dedicated Unix user, systemd service and nginx HTTPS reverse proxy.
The one-time legitimate Google ceremony uses the loopback-only noVNC scripts documented in `docs/AUTH_BOOTSTRAP.md`. Its auth command is:
```bash
sudo -u nlm-perplexity-stage /opt/nlm-expert-research-mcp-perplexity-staging/deployment/auth-bootstrap-staging.sh
```
It must run only through a secure interactive display method described in `docs/AUTH_BOOTSTRAP.md`. Never paste passwords, 2FA codes or cookies into chat.
## Tool policy
- `nlm_consultar`: ordinary targeted question.
- `nlm_investigar` `STANDARD`: bounded synthesis.
- `nlm_investigar` `DEEP`: bounded primary plus counter-evidence/gap pass when the measured remaining budget permits it.
- `nlm_verificar_respuesta`: NotebookLM source-grounded model evaluation, not deterministic proof.
- Source title scoping in v1 is disclosed as prompt-scoped, not a strict transport-level source filter.
See `docs/OPERATIONS.md`, `docs/AUTH_BOOTSTRAP.md`, `docs/UI_DRIFT_RUNBOOK.md`, and `docs/PERPLEXITY_ACCEPTANCE.md`.
TDQS
Scored across 10 tools
Tools have mostly distinct purposes: setup_auth is for login, health for status, doctor for local diagnostics, research for single-notebook queries, compare_notebooks for two-notebook comparisons, and so on. Some potential confusion exists between list_notebooks and notebook_resolve (listing vs resolving one) and doctor vs health, but descriptions clarify the boundaries well.
Naming follows a mostly verb_noun pattern (list_notebooks, get_evidence, compare_notebooks) but deviates with single-word names (doctor, health, research) and reversed object_verb forms (notebook_resolve, notebook_refresh). This mixed convention is readable but not fully consistent.
10 tools is well-scoped for an expert research MCP, covering authentication, diagnostics, health, notebook discovery, source listing, research, evidence retrieval, and comparison. Each tool earns its place without redundancy or bloat.
The surface covers the full research lifecycle: setup auth, check health, list/resolve/refresh notebooks, list sources, run research, retrieve evidence, and compare notebooks. Minor gaps include lack of a tool to browse all evidence from a session or a single tool to search across multiple notebooks, but these are not core to the stated purpose.