API-317: follow up on the retired Cursor deep link in the MCP README

[gulshngill]

Why

nansen-api#1803 removes the Cursor install deep link from docs.nansen.ai/mcp/connecting. This README — already published on npm (1.41.1) — tells readers that link is maintained on that page:

Claude Desktop and Cursor: setup instructions for both — the Claude Desktop .dxt bundle and the Cursor install deep link — are in the connection docs: docs.nansen.ai/mcp/connecting.

The moment #1803 merges, that sentence points at an artifact that no longer exists. This PR should merge first, so the window never opens.

Note this reverses the follow-up #506 filed for itself ("worth dropping --allow-http so the deep link matches"). API-319 wanted the deep link fixed; API-317 concluded it can't be — Cursor persists a deep link's decoded config as-is, so a static link can only ever ship a placeholder key, and a personalized one would put a live key in a URL.

What changed

• Drop the artifact enumeration from the Claude Desktop / Cursor pointer, so the README stays correct as the docs page evolves rather than naming specific install artifacts it doesn't own.
• Pin mcp-remote@0.2.1 (the current release) in the stdio bridge example, replacing @latest. The bridge handles the API key on every request, so the version is fixed rather than letting npx pull a new release automatically. Bumping is invited — review the release, update the pin.
  • Correction from review: an earlier revision of this PR pinned 0.1.38 and justified it as matching what nansen mcp install writes and nansen mcp verify requires. No such command exists — not on main (schema.json has no mcp key, mcp-remote appears only in README.md) and not in published 1.40.1. MCP_REMOTE_PIN = 'mcp-remote@0.1.38' lives only in API-285: One-step MCP install (nansen mcp install <client>) #487, which is unmerged and CONFLICTING. The .dxt is not the source either: it vendors mcp-remote ^0.1.18 and never invokes npx. 0.1.38 is ~7 months and ~13 releases behind current.
  • 0.2.1 verified as a drop-in: identical header parser, identical ${VAR} substitution, identical allowHttp guard, connects to prod with the key substituted from the environment.
• Correct the header-formatting note. It said "keep the header as one argument with no space after the colon". The no-space part is wrong: mcp-remote parses headers with /^([A-Za-z0-9_-]+):\s*(.*)$/, so whitespace after the colon is trimmed. The note now says what actually matters — name and value in a single args entry, and the key in env rather than the argument list.

Verification

• mcp-remote@0.1.38 header parser read from source (package/dist/chunk-65X3S4HB.js:20713) — confirms the \s* trim.
• Env substitution confirmed live at chunk-65X3S4HB.js:20850-20861 and by running the documented command against prod: Replacing ${NANSEN_API_KEY} with environment value in header 'NANSEN-API-KEY' → Proxy established successfully. So the env form this README already recommended does work — only the rationale sentence was wrong.
• npm run lint clean; npx vitest run src/__tests__/response-meta.test.js → 44 passed. No source files touched.

Checklist

• Tests pass
• src/schema.json updated if new commands or flags were added — n/a, docs-only
• README.md updated
• Changeset added (patch — the README ships to npm)

🤖 Generated with Claude Code

[nansen-pr-reviewer]

pr-reviewer Summary for #33ec046

📝 1 finding

Review completed. Please address the findings below.

Findings by Severity

Severity	Count
🟡 Medium	1

Review effort: 1/5 (Trivial)

Summary

The three README changes are all correct and well-reasoned: dropping the stale Cursor deep-link enumeration, pinning mcp-remote to an exact version, and fixing the header-formatting note. The underlying motivations are sound.

One medium-severity inconsistency between the changeset and the actual diff is worth cleaning up before merge.

Findings

README.md / .changeset/mcp-readme-cursor-followup.md — Changeset rationale disagrees with the committed pin

Severity: medium

What happened: The PR description and the first commit ("docs: follow up on the retired Cursor deep link") planned to pin mcp-remote@0.1.38 because it's "the version nansen mcp install writes". A later commit ("Pin mcp-remote to 0.2.1 with an honest justification") correctly changed the pin to 0.2.1 after discovering that nansen mcp install / extractInstalledKey don't exist yet. However, the changeset body (mcp-readme-cursor-followup.md) was not updated and still says:

"pin the mcp-remote bridge to the version mcp install writes"

That rationale is the one the second commit explicitly retracted. The actual CHANGELOG entry will record an inaccurate justification.

Suggested fix: Update the changeset description to match the real reason, e.g.:

Docs: stop pointing at the retired Cursor install deep link, pin
`mcp-remote` to an exact version (the bridge handles your API key on
every request; `npx` would otherwise pull a new release automatically),
and correct the header-formatting note (whitespace after the colon is
trimmed; the key belongs in `env`, not in the argument list).

---

Token usage: 539 input, 1,917 output, 105,831 cache read, 20,939 cache write | Usage Guide

New pushes are reviewed automatically with a 10-minute cooldown between reviews. To request a review at any time, comment @nansen-pr-reviewer re-review.

[nansen-pr-reviewer]

Auto-approved

This PR was automatically approved because:

• It contains only documentation changes

If you have any concerns, please request a manual review.

[Codier]

Approving.

The question I left on nansen-api#1803 applies to the mcp-remote@0.1.38 pin here too — I can't find the nansen mcp install / nansen mcp verify that's meant to set it, and this repo is where it would live. Answer it over there and this is fine as is.

[nansen-pr-reviewer]

Auto-approved

This PR was automatically approved because:

• It contains only documentation changes

If you have any concerns, please request a manual review.