Summary

#70 fixed the broken contextstream/mcp/releases link so it now points to contextstream/mcp-server/releases, and help(action="version") / mcp_server_version expose the running version, latest version, release URL, and changelog. That repaired the link, but a real residual confusion remains around which MCP build a user is actually running and where that build's release notes live.

Observed mismatch

• help(action="version") reports: running server v0.5.39, latest available v0.5.39.
• The releases page it links to (https://github.com/contextstream/mcp-server/releases) shows latest tag v0.4.81.

So there are at least two different version lines (a 0.5.x server and a 0.4.x published release), and it is not obvious from the README which one a given user is on or which releases URL is authoritative for their build. This is exactly the "can't tell what changed / which version am I on" confusion #70 set out to remove.

Request

Please document, in the README (and/or a docs page), the distinct MCP server types/builds and the correct release-notes location for each, for example:

• Hosted remote API (consumed via .vscode/mcp.json HTTP endpoint) — version line + releases/changelog URL
• Local CLI (contextstream-mcp, installed via npm install -g @contextstream/mcp-server) — version line + releases URL
• ContextStream Desktop ("Add local repository" flow) — version line + releases URL
• Rust MCP (if separately versioned) — version line + releases URL

For each, state:

1. How to identify which type you are running.
2. The canonical releases/changelog URL for that type.
3. How help(action="version") maps to that type's release notes, so the running-version → release-notes jump is unambiguous.

This would make the [VERSION_NOTICE] mechanism and the help(action="version") output self-explanatory instead of leaving users to reconcile mismatched version numbers by hand.

Related

• Follow-up to Popup 'View all releases' links to github.com/contextstream/mcp/releases (404); propose release_notes tool for agents #70 (broken releases link + release_notes proposal).
• See also Windows client: no way to index local repo; /status reports wrong project root and path change does not persist #69 (Windows client local-repo indexing) and Follow-up: ingest_local after purge leaves project index missing (0 files) #67 (ingest_local after purge).