Skip to content

Remove MCP protocol version display from session output#81

Open
jancurn wants to merge 6 commits intomainfrom
claude/remove-mcp-date-output-uKEE0
Open

Remove MCP protocol version display from session output#81
jancurn wants to merge 6 commits intomainfrom
claude/remove-mcp-date-output-uKEE0

Conversation

@jancurn
Copy link
Member

@jancurn jancurn commented Mar 17, 2026

Summary

This PR removes the display of MCP protocol version information from session and target output formatting. The protocol version is no longer shown in the CLI output for both session listings and direct server connections.

Key Changes

  • Removed MCP protocol version display from formatSessionLine() function
  • Removed protocolVersion field from LogTargetOptions interface
  • Removed protocol version concatenation and display from logTarget() function for both stdio and HTTP transports
  • Updated demo output script to reflect the removal of version information
  • Updated unit tests to verify protocol version is no longer displayed

Implementation Details

  • The changes affect three main areas: session line formatting, target logging, and their respective test cases
  • Protocol version information is completely removed from the output formatting logic rather than being conditionally hidden
  • Both stdio transport (command-based) and HTTP transport outputs are updated consistently

https://claude.ai/code/session_01C3RfAyxwnFqemmd8Mvzj9u

claude and others added 6 commits March 16, 2026 23:59
The "MCP: 2025-11-25" info shown in session lines (e.g. `mcpc`) and
logTarget output is redundant noise. Remove it from human-readable
output while keeping protocolVersion in JSON session detail output.

https://claude.ai/code/session_01C3RfAyxwnFqemmd8Mvzj9u
The connect command was catching and silently discarding non-AuthError
exceptions from showServerDetails. This caused a race condition where
fast-failing bridges (e.g. OAuth servers returning 401) would mark the
session as expired before showServerDetails ran, resulting in a
ClientError instead of AuthError, which was then swallowed — making
the connect command succeed (exit 0) when it should have failed.

Fix by letting all showServerDetails errors propagate. Since the health
check blocks until the bridge has definitively connected or failed,
there's no reason to swallow errors.

Also fix bridge's sendError to properly map AuthError to exit code 4
(was falling through to default code 2).

https://claude.ai/code/session_01C3RfAyxwnFqemmd8Mvzj9u
Restore try/catch around showServerDetails but keep auth error
propagation working correctly:

- Bridge now marks auth failures as 'unauthorized' (not 'expired'),
  so ensureBridgeReady throws AuthError which connectSession re-throws
- Non-auth failures (TLS errors, timeouts) are still swallowed so
  connect succeeds and the session can be used later (fixes insecure test)
- Session expiry (404) stays as 'expired' with ClientError (swallowed)

https://claude.ai/code/session_01C3RfAyxwnFqemmd8Mvzj9u
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants