Tolerate spec-violating list methods on backend init

[tgrunnagle]

Summary

A vMCP backend that advertises capabilities.resources (or capabilities.prompts) in its initialize response but does not actually implement resources/list (or prompts/list) currently fails per-session backend init outright. Every tool from that backend silently disappears from tools/list, leaving users with no signal that anything went wrong — a real problem against third-party servers like Atlassian's Rovo MCP that we don't control. This PR makes the per-session bootstrap tolerate that specific spec violation while keeping all other failure modes fatal.

In initAndQueryCapabilities, a JSON-RPC -32601 Method not found from resources/list or prompts/list is now treated as "the backend has no resources/prompts" rather than a fatal init error, with a WARN log recording the spec violation. tools/list errors and any non--32601 error from the resources/prompts list calls remain fatal.

Closes #5231

Changes Made

pkg/vmcp/session/internal/backend/mcp_session.go

• Detect mcp.ErrMethodNotFound from resources/list and prompts/list via errors.Is and recover with an empty result set instead of returning an error.
• Emit a WARN log on recovery, including backendID and the offending list method, so operators can flag the upstream bug without ERROR-level noise.
• Leave tools/list strict (a backend with no tool surface is not useful to expose) and leave non--32601 list errors fatal (we are not silencing arbitrary failures).

pkg/vmcp/session/internal/backend/mcp_session_capabilities_test.go (new)

• Table-driven tests covering each acceptance-criteria scenario via a fake streamable-http MCP backend.

Implementation Details

• The -32601 detection relies on mcp-go's JSONRPCErrorDetails.AsError() wrapping the sentinel mcp.ErrMethodNotFound, so errors.Is(listErr, mcp.ErrMethodNotFound) is the correct discriminator across upstream message variations (e.g., the doubled "method not found: Method not found" string seen in production).
• The recovery is scoped narrowly to the spec-violation case. Transport errors, timeouts, and other JSON-RPC error codes still abort init, preserving visibility into genuine problems.

Testing

• New unit tests in pkg/vmcp/session/internal/backend/mcp_session_capabilities_test.go cover the acceptance criteria:
  • resources/list returns -32601 after the server advertised resources -> init succeeds with no resources, tools remain reachable.
  • prompts/list returns -32601 after the server advertised prompts -> init succeeds with no prompts, tools remain reachable.
  • Both list methods return -32601 simultaneously -> init still succeeds, tools remain reachable.
  • tools/list returns -32601 -> init still fails (regression guard).
  • resources/list returns -32601 INTERNAL_ERROR (non--32601) -> init still fails (regression guard).
  • prompts/list returns INVALID_PARAMS (non--32601) -> init still fails (regression guard).
• task test (unit tests) and task lint-fix (linting) run clean on the touched package.

Additional Notes

• Manual verification against the Atlassian Rovo MCP server (https://mcp.atlassian.com/v1/mcp) called out in the issue's acceptance criteria has not been performed in this PR; the unit tests exercise the same code path with a fake backend that produces the equivalent -32601 response. Reviewers who have the Rovo wiring available should confirm tools/list returns the workload-prefixed Atlassian tools after OAuth completes.
• The same fragility class is worth a follow-up audit elsewhere in the session bootstrap (subscriptions, completions) — anywhere we derive "the server supports method X" from the initialize response and then unconditionally call X. Out of scope for this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.97%. Comparing base (9211a36) to head (a5648e9).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5232      +/-   ##
==========================================
+ Coverage   67.91%   67.97%   +0.05%     
==========================================
  Files         610      612       +2     
  Lines       62522    62741     +219     
==========================================
+ Hits        42464    42648     +184     
- Misses      16879    16909      +30     
- Partials     3179     3184       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lorr1]

Multi-agent review summary

Recommendation: COMMENT (non-blocking).

The fix is correct, well-scoped, and end-to-end safe. errors.Is(listErr, mcp.ErrMethodNotFound) is the right discriminator against the mcp-go v0.49.0 sentinel (JSONRPCErrorDetails.AsError() wraps it via fmt.Errorf("%w: ..."), so errors.Is matches both bare and wrapped variants). Switch ordering is nil-safe. tools/list strictness is preserved. Empty caps.Resources/caps.Prompts flow correctly through pkg/vmcp/session/factory.go and the aggregator merge — a downstream client resources/list against vMCP simply returns an empty merged set.

Four specialist reviewers (Go correctness, MCP protocol, test coverage, general code quality) consulted. Codex cross-review was attempted but timed out; not blocking.

Summary of inline findings

#	Severity	Theme
1	MEDIUM	Switch default arm (the success-path populate loop) is unverified
2	LOW	Comment phrasing ("spec violation" / "empty resource set")
3	LOW	wantToolsCalled bool redundant with int counters
4	LOW	assert.True(strings.Contains(...)) should be assert.Contains
5	LOW	WARN log lacks workload name and base URL
6	LOW	errors.Is won't match HTTP-level method-missing variants (404/501)

Out-of-scope / informational

• Pre-existing: list calls do not loop on nextCursor — file a follow-up issue if pagination matters.
• PR description references mcp-go v0.43.2; go.mod actually pins v0.49.0. Sentinel and wrapping semantics are identical, so the code is correct — doc nit only.
• WARN may be noisy under reconnect churn; rate-limit per (backendID, method) only if it shows up in practice.
• vMCP does not currently forward notifications/resources/list_changed, so the empty-recovery path does not create phantom subscriptions today.