[iborakove]

Description

Some MCP servers advertise the resources capability but don't implement the optional resources/templates/list method. The resources capability has no separate flag for templates, so the client can't tell in advance. For example, servers built on the low-level Python SDK Server advertise resources as soon as resources/list is registered, and answer every unregistered method with JSON-RPC -32601.

MCPConnection puts every template-listing failure into the server's errors, and those become config errors. As a result, users see Error loading resource templates for MCP Server <name>: MCP error -32601: Method not found for servers whose resources and tools work fine. Reported in #8412, #6226 and ihor-sokoliuk/mcp-searxng#54.

This change treats a structured McpError with ErrorCode.MethodNotFound from listResourceTemplates() as "no templates":

• The check uses the SDK's numeric error code, not the message text.
• It applies only to template listing. -32601 from resources/list, tools/list or prompts/list is still reported.
• Every other template failure is still reported: internal errors, invalid params, timeouts, closed connections, malformed results and unstructured errors.
• Resources, tools, prompts and the connection status are unchanged.

Tests

core/context/mcp/MCPConnection.vitest.ts adds:

• Connection-lifecycle tests against a real stdio server. core/context/mcp/fixtures/stdioResourceServer.mjs is a small fixture built on the SDK's low-level Server, with local synthetic data and no network. The tests cover:
  • templates not implemented;
  • valid templates;
  • -32603 and malformed template responses;
  • a template request that never answers (connection timeout);
  • a tools/list failure;
  • a server that exits during initialization;
  • reconnecting after a failed connection;
  • two servers in parallel.
• Mocked cases:
  • structured MethodNotFound is ignored;
  • an unstructured error with the same text, -32602, -32001 and -32000 are still reported;
  • -32601 from resources/list is still reported;
  • no template request is sent to a tools-only server.

Run on this branch (base 5522c6f44, Node 20.20.1):

• core: npx vitest run context/mcp/ tools/ passes, and so does npx tsc -p ./ --noEmit.
• extensions/vscode: npx tsc -p ./ --noEmit passes (it also type-checks core).

Notes

• If a connection times out during discovery, discovery calls that are still in flight can later reset the status from error to connected. That happens on main too. The new timeout test therefore asserts the recorded errors, not the status. Happy to address it separately.
• Reconnecting an already-connected stdio server (reported in MCP STDIO transport reconnection race condition causes inconsistent state #11886) is out of scope; fix: simplify MCP STDIO reconnection by closing client before reconnect #11887 covers it.
• feat(mcp): support VS Code-style variable interpolation in MCP server config #13036 also edits MCPConnection.vitest.ts. The changes don't overlap, but whichever lands second may need a trivial rebase.