MCP startup reports interruption when server returns -32601 for optional resources/templates/list

Open 💬 2 comments Opened Aug 7, 2026 by yusoofsh
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex reports:

MCP startup interrupted. The following servers were not initialized: mintlify_index

The MCP server does initialize successfully, but Codex subsequently calls
resources/templates/list. The server returns the valid JSON-RPC response
-32601 Method not found because it does not advertise resource templates.
Codex treats this optional unsupported method as a startup failure.

Environment

  • Codex CLI: 0.147.0
  • macOS 26.6.1
  • MCP transport: streamable HTTP
  • Server: https://index.mintlify.com

Minimal reproduction

Configure:

[mcp_servers.mintlify_index]
url = "https://index.mintlify.com"

The server responds successfully to initialize:

{
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {
        "listChanged": true
      }
    },
    "serverInfo": {
      "name": "mintlify-universal-search",
      "version": "1.0.0"
    }
  },
  "jsonrpc": "2.0",
  "id": 1
}

Codex then logs:

Failed to list resource templates for MCP server 'mintlify_index':
Mcp error: -32601: Method not found

Expected behavior

If the server does not advertise resources or resourceTemplates, Codex should skip those probes. If it probes anyway and receives -32601, it should treat that as an unsupported optional capability rather than failing MCP startup.

Actual behavior

Codex surfaces the unsupported optional method as an MCP startup interruption and reports the server as not initialized.

Workaround

Removing and re-adding the server does not change the behavior. The server itself is reachable and completes the initialize handshake.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 20 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37418

Powered by Codex Action

joshmouch · 9 days ago

I reproduced this against tools-only MCP servers and traced it to the aggregate resource inventory paths issuing resources/list and resources/templates/list without consulting the server capabilities returned by initialize. The MCP resources specification makes the resources capability the negotiation boundary: https://modelcontextprotocol.io/specification/2025-06-18/server/resources

I prepared and verified a source patch here: https://github.com/joshmouch/codex/commit/a1d3f09c5b

The proposed ownership/fix is:

  • capture capabilities.resources once in the managed connection owner from InitializeResult;
  • exclude non-resource servers from both live and step-bound aggregate resource/template inventories;
  • reject explicit list/template/read operations locally before OAuth refresh or a wire request when the capability is absent;
  • preserve not-initialized and shut-down errors rather than misclassifying connection state as unsupported.

The regression exercises live and captured inventories, resources and templates, both explicit calls, and a server-side counter proving zero resource requests reach a tools-only server. Verification is green: codex-rmcp-client 115/115 (5 skipped), codex-mcp 123/123, both scoped clippy --fix passes, and git diff --check.

I attempted to open the PR, but the repository correctly rejected it because external contributions require a maintainer invitation. If this approach matches the intended architecture and a maintainer would like the patch submitted, I can open the PR from the linked branch.