[GH-ISSUE #115] Detect stale MCP server versions after REA upgrade and report complete surface inventory #75

Closed
opened 2026-10-15 18:20:50 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @morluto on GitHub (Jul 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/115

Summary

Make REA detect and explain when the installed CLI, registered MCP command, running MCP server, installed skill, and exposed capability catalog come from different versions. Report the complete product surface using unambiguous counts and restart guidance.

Observed behavior

After upgrading globally from REA 1.2.0 to 1.3.0:

  • rea --version immediately reported 1.3.0;
  • the existing Codex MCP process still exposed the old server/tool surface;
  • rea setup --yes updated the bundled skill from v10 to v12;
  • new MCP prompts and capabilities required restarting Codex;
  • rea mcp doctor reported 27 CLI-facing commands, while REA documentation separately describes 68 MCP analysis tools and six prompts.

Each fact is individually valid, but the combined state is difficult for agents and users to interpret.

User problem

Agents may conclude a feature is unavailable when the running server is merely stale. Users do not know whether to:

  • rerun setup;
  • restart the coding client;
  • restart only the MCP server;
  • update the skill;
  • fix a registration path;
  • upgrade the global package.

Ambiguous tool counts further obscure whether CLI commands or MCP tools were tested.

Proposed version identity

Expose a stable identity record containing:

  • package name and semantic version;
  • build/commit identity when available;
  • MCP protocol version;
  • server instance start time;
  • registered command path and resolved package path;
  • skill version expected by the package;
  • tool catalog digest and count;
  • prompt catalog digest and count;
  • resource/template count;
  • provider identities and versions;
  • enabled experimental capabilities.

Make the identity available through:

  • rea doctor;
  • rea mcp doctor;
  • an MCP server/session status result;
  • optional stable _meta on MCP responses.

Stale-state detection

Compare, where observable:

  • currently invoked CLI package;
  • absolute command stored in each client registration;
  • package resolved by that command;
  • installed skill metadata;
  • live MCP server identity supplied by the client/server connection.

Classify states:

  • healthy and aligned;
  • client restart required;
  • MCP server restart required;
  • setup/registration stale;
  • skill stale;
  • multiple installations/path shadowing;
  • live server version unavailable.

Do not claim live comparison if the host provides no way to query the active connection.

Surface inventory

Report distinct labeled counts:

  • CLI commands;
  • MCP tools;
  • MCP prompts;
  • MCP resources;
  • MCP resource templates;
  • configured/available providers;
  • task/elicitation/progress capability support.

Include catalog digests so agents can detect drift without comparing every schema.

Upgrade behavior

After rea upgrade:

  • print the previous and installed version;
  • identify registered clients likely holding a live stale process;
  • say exactly which clients need restart;
  • avoid implying new MCP tools are immediately available;
  • optionally run a post-upgrade registration/skill check without overwriting unrelated config.

Acceptance criteria

  • MCP server exposes package/build identity and start time.
  • Doctor distinguishes CLI, registered, live-server, and skill versions.
  • Upgrade reports when a client restart is required.
  • Multiple global/local/npx installations are detected and paths shown safely.
  • Surface counts are labeled by category and include stable catalog digests.
  • A stale skill is distinguishable from a stale server.
  • Unobservable live state is reported as unknown, not healthy.
  • Tests cover aligned state, old live server, stale registration, stale skill, path shadowing, no live-query support, and additive prompt/tool changes.
  • Documentation provides remediation for each classification.
  • No automatic process termination or client restart occurs without explicit user action.

Non-goals

  • Forcibly restarting coding clients.
  • Assuming a registration on disk proves a running process uses it.
  • Treating catalog count alone as proof of schema equality.
  • Sending sensitive local configuration through remote transports.

Relationships

  • #101 can use catalog identity when announcing tool-list changes.
  • #102 is a concrete example: prompts shipped but were unavailable to the already-running MCP process.
  • #24 tracks keeping installed skills and localized claims current.## Confirmed identity drift and SDK identity

A July 2026 repository inspection confirmed that identity drift can exist inside one checkout:

  • package.json reports REA 1.3.0;
  • PRODUCT_IDENTITY.packageVersion reports 1.1.0;
  • the MCP initialization handshake reports server version 0.1.0;
  • PRODUCT_IDENTITY.skillVersion reports 10.

These values demonstrate why no manually duplicated version constant should be treated as authoritative. Build/package identity should be generated or injected from one canonical source and verified through the packaged artifact.

REA now pins @modelcontextprotocol/server and @modelcontextprotocol/client at 2.0.0-beta.4, which introduce the shared transitive @modelcontextprotocol/core@2.0.0-beta.4. The identity/status record should report server SDK, client test SDK, and core protocol-library versions separately when available. These dependency versions are diagnostic metadata and must not be confused with the negotiated MCP protocol version.

Surface reporting should also distinguish target acceptance from operation-level provider support, as described in #101 and #117.

Originally created by @morluto on GitHub (Jul 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/115 ## Summary Make REA detect and explain when the installed CLI, registered MCP command, running MCP server, installed skill, and exposed capability catalog come from different versions. Report the complete product surface using unambiguous counts and restart guidance. ## Observed behavior After upgrading globally from REA 1.2.0 to 1.3.0: - rea --version immediately reported 1.3.0; - the existing Codex MCP process still exposed the old server/tool surface; - rea setup --yes updated the bundled skill from v10 to v12; - new MCP prompts and capabilities required restarting Codex; - rea mcp doctor reported 27 CLI-facing commands, while REA documentation separately describes 68 MCP analysis tools and six prompts. Each fact is individually valid, but the combined state is difficult for agents and users to interpret. ## User problem Agents may conclude a feature is unavailable when the running server is merely stale. Users do not know whether to: - rerun setup; - restart the coding client; - restart only the MCP server; - update the skill; - fix a registration path; - upgrade the global package. Ambiguous tool counts further obscure whether CLI commands or MCP tools were tested. ## Proposed version identity Expose a stable identity record containing: - package name and semantic version; - build/commit identity when available; - MCP protocol version; - server instance start time; - registered command path and resolved package path; - skill version expected by the package; - tool catalog digest and count; - prompt catalog digest and count; - resource/template count; - provider identities and versions; - enabled experimental capabilities. Make the identity available through: - rea doctor; - rea mcp doctor; - an MCP server/session status result; - optional stable _meta on MCP responses. ## Stale-state detection Compare, where observable: - currently invoked CLI package; - absolute command stored in each client registration; - package resolved by that command; - installed skill metadata; - live MCP server identity supplied by the client/server connection. Classify states: - healthy and aligned; - client restart required; - MCP server restart required; - setup/registration stale; - skill stale; - multiple installations/path shadowing; - live server version unavailable. Do not claim live comparison if the host provides no way to query the active connection. ## Surface inventory Report distinct labeled counts: - CLI commands; - MCP tools; - MCP prompts; - MCP resources; - MCP resource templates; - configured/available providers; - task/elicitation/progress capability support. Include catalog digests so agents can detect drift without comparing every schema. ## Upgrade behavior After rea upgrade: - print the previous and installed version; - identify registered clients likely holding a live stale process; - say exactly which clients need restart; - avoid implying new MCP tools are immediately available; - optionally run a post-upgrade registration/skill check without overwriting unrelated config. ## Acceptance criteria - [ ] MCP server exposes package/build identity and start time. - [ ] Doctor distinguishes CLI, registered, live-server, and skill versions. - [ ] Upgrade reports when a client restart is required. - [ ] Multiple global/local/npx installations are detected and paths shown safely. - [ ] Surface counts are labeled by category and include stable catalog digests. - [ ] A stale skill is distinguishable from a stale server. - [ ] Unobservable live state is reported as unknown, not healthy. - [ ] Tests cover aligned state, old live server, stale registration, stale skill, path shadowing, no live-query support, and additive prompt/tool changes. - [ ] Documentation provides remediation for each classification. - [ ] No automatic process termination or client restart occurs without explicit user action. ## Non-goals - Forcibly restarting coding clients. - Assuming a registration on disk proves a running process uses it. - Treating catalog count alone as proof of schema equality. - Sending sensitive local configuration through remote transports. ## Relationships - #101 can use catalog identity when announcing tool-list changes. - #102 is a concrete example: prompts shipped but were unavailable to the already-running MCP process. - #24 tracks keeping installed skills and localized claims current.## Confirmed identity drift and SDK identity A July 2026 repository inspection confirmed that identity drift can exist inside one checkout: - `package.json` reports REA `1.3.0`; - `PRODUCT_IDENTITY.packageVersion` reports `1.1.0`; - the MCP initialization handshake reports server version `0.1.0`; - `PRODUCT_IDENTITY.skillVersion` reports `10`. These values demonstrate why no manually duplicated version constant should be treated as authoritative. Build/package identity should be generated or injected from one canonical source and verified through the packaged artifact. REA now pins `@modelcontextprotocol/server` and `@modelcontextprotocol/client` at `2.0.0-beta.4`, which introduce the shared transitive `@modelcontextprotocol/core@2.0.0-beta.4`. The identity/status record should report server SDK, client test SDK, and core protocol-library versions separately when available. These dependency versions are diagnostic metadata and must not be confused with the negotiated MCP protocol version. Surface reporting should also distinguish target acceptance from operation-level provider support, as described in #101 and #117.
bsakaguchi 2026-10-15 18:20:50 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#75
No description provided.