API-285: Authenticated MCP setup verification (nansen mcp verify) - #502
API-285: Authenticated MCP setup verification (nansen mcp verify)#502gulshngill wants to merge 2 commits into
Conversation
…API-285) Closes the verification half of API-285 (child API-318): tools/list and even some free tools succeed without a key, so a broken credential setup looks fine until the first paid data call. verify makes that call — one JSON-RPC tools/call of token_info against the hosted server — and maps every observed failure mode to an actionable next step. Two modes: bare verify checks the nansen login / NANSEN_API_KEY credential; verify <client> checks the key actually installed in that client's config, refusing (before any network call) entries that drift from what install writes, so the key can never be sent to a non-official URL. Redirects are refused (redirect: 'error'), the key is never printed, response bodies are redacted, --dry-run is rejected on the credit-consuming path, and per-status-family HTTP guidance covers 401/403, 429, 5xx, and unexpected responses. Live-verified against mcp.nansen.ai (server nansen-mcp 3.2.4): valid key → success; invalid key → actionable 401 guidance; install→verify round trip in a clean HOME. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Independent reviewVerdict: REQUEST_CHANGES Protocol behavior, credential redaction, endpoint pinning, live verification, and the existing test suite were checked and are generally sound. Two fixes are needed:
Follow-ups noted by the reviewer: classify insufficient credits separately, verify the installed desktop transport rather than only direct HTTP, and tighten the success gate. These are non-blocking relative to the two fixes above. |
…match Addresses the two blocking findings on #502. extractInstalledKey deep-equalled buildServerEntry(), so valid official configs — hand-written, deep-link, or simply carrying an extra field — were refused with "re-run install" even though verify sends the key to the NANSEN_MCP_URL constant and never to the config's URL. It now gates on what actually decides where the key goes: - HTTP clients: the official URL (trailing slash tolerated), no command/args (which would make the client spawn a process and hand it the key), and exactly one case-insensitive NANSEN-API-KEY header. - Claude Desktop: npx running the pinned mcp-remote itself (an npm execution override such as --package= keeps every token while running another binary), aimed at the official URL and no other, the key passed by the exact ${NANSEN_API_KEY} reference after --header with no competing key header (mcp-remote's last assignment wins), and no env variable beyond the key — env is npx's execution surface. Everything else is now a warning from the new entryDriftNotes(), which names the missing/changed/extra fields and never their values, so a note cannot carry the key. Test coverage for the primary live failure shape: an HTTP 200 body with result.isError and an invalid-key message, driven through the command and through runCLI — exit 1, actionable guidance, key absent from the error and from all output even when the server echoes it back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Summary
Adds authenticated verification for the MCP setup.
Why
Some MCP protocol discovery operations can succeed without credentials, so a typo, rotated, or placeholder key may appear to install successfully and only fail on the first real data call.
verifymakes that call up front and maps failures to an actionable next step.Design / security
--dry-runis rejected up front so the credit-consuming path is never reached silently; credit cost is disclosed in output, usage, schema, and README.installnow points users toverifyas the final setup step.Tests
npm test: 54 files, 2,010 passed / 2 skippednpm run lint: clean🤖 Generated with Claude Code