The -32601 method not found error means your MCP client successfully reached a server, but sent a JSON-RPC method name the server does not recognize. The connection is healthy — the problem is a mismatch between what the client asked for and what the server implements.

The short answer: This is almost always a protocol version mismatch or a transport type mismatch. The client sends tools/list but the server only knows an older method set, or the client sends HTTP requests to an SSE-only endpoint.

---

How to diagnose: send a raw initialize request

The fastest way to isolate this error is to bypass the IDE entirely and send a direct JSON-RPC request:

bashCOPY
# Send a minimal MCP initialize handshake
curl -s -X POST https://your-server-url/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {},
      "clientInfo": { "name": "test-client", "version": "1.0" }
    }
  }'

If the response contains -32601: The server doesn't implement the initialize method, meaning it's either not an MCP server at all, or it implements a different protocol version.

If initialize succeeds but tools/list returns -32601: The server is an MCP server but doesn't implement tool discovery. Check the capabilities object in the initialize response — if tools is missing, the server intentionally doesn't expose tools.

---

Cause 1 — Protocol version mismatch

The MCP specification has evolved through several versions. If your client sends "protocolVersion": "2024-11-05" but the server only implements an older version, specific methods may not exist.

How to verify:

Check the protocolVersion field in the server's initialize response. If it returns a different version than what your client sent, that's the mismatch.

How to fix:

• Update the server to the latest MCP SDK version
• If you built the server, update to the current MCP Python SDK or TypeScript SDK
• If it's a third-party server, check for updates or file an issue

---

Cause 2 — Wrong transport type

If your IDE is configured for HTTP but the server implements SSE (or vice versa), the connection establishes but method routing fails.

Common scenarios:

jsonCOPY
// Client config expects HTTP — but server only handles SSE
{
  "servers": {
    "my-server": {
      "type": "http",
      "url": "https://example.com/sse"
    }
  }
}

The server receives what looks like a malformed SSE subscription and returns -32601 because the HTTP POST body isn't routed to a JSON-RPC handler.

How to fix:

Check the server's documentation for the correct transport type and endpoint path. Many servers expose both /mcp (HTTP) and /sse (SSE) on different routes.

For VS Code, the type field must match: "http" for HTTP JSON-RPC servers, omit it for stdio servers. Using the wrong type causes VS Code to attempt the wrong transport.

---

Cause 3 — Method namespace mismatch

JSON-RPC method names in MCP are case-sensitive and use a specific namespace format:

jsonCOPY
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

If the server expects tools/list but receives toolsList or list_tools, it returns -32601. This happens when:

• Custom MCP implementations use non-standard method names
• A proxy or middleware rewrites the JSON-RPC body
• An older client uses deprecated method names

How to verify:

Use the MCP Playground to probe the server. It sends the standard method names and shows exactly what the server responds to.

---

Cause 4 — Proxy or middleware stripping request body

Reverse proxies (nginx, Cloudflare, AWS ALB) can strip, truncate, or rewrite JSON-RPC request bodies. If the method field is removed or altered, the server can't route the request.

How to check:

bashCOPY
# Compare what you send vs what the server receives
# Add verbose output to see the full request/response
curl -v -X POST https://your-server-url/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Look at the response headers for proxy indicators (via, x-cache, server). If the response Content-Type isn't application/json, something is intercepting.

Common proxy fixes:

• Ensure Content-Type: application/json is preserved through the proxy
• Set proxy_pass_request_body on in nginx
• Increase proxy_buffer_size if the request body is being truncated
• Disable request body inspection in WAF rules

---

Cause 5 — Stale client schema cache

Some IDE extensions cache the server's method catalog from a previous connection. If the server was updated and methods changed, the client may still send old method names.

How to fix:

1. Fully restart the IDE (not just reload the window)
2. Delete and re-add the server config entry
3. Clear the IDE's MCP extension cache if applicable
4. Run a fresh probe in the MCP Playground to verify current methods

---

Quick diagnostic table

---

Verify fix

1. Run endpoint probe in MCP Playground
2. Confirm is_mcp: true and tool_count > 0
3. Use the MCP Inspector for local servers: npx @modelcontextprotocol/inspector node your-server.js
4. Reconnect from IDE and run one known-safe tool call
5. If methods still fail, compare raw request and response using server logs

For a complete testing workflow, see How to Test MCP Servers.

---

Related troubleshooting

• MCP Error -32000 Connection Closed — server connection drops before response
• Could Not Connect to MCP Server — connection never established
• No Working IDE Endpoint Available — config parsed but no endpoint works
• MCP Server Not Working? Complete Guide — covers all failure modes
• How to Test MCP Servers — debug handshakes, tool calls, and response times

IDE setup guides: VS Code · Cursor · Claude Desktop · Windsurf