googleapis/mcp-toolbox · error

METHOD_NOT_FOUND

METHOD_NOT_FOUND

Error message

invalid method %s

What it means

ProcessMethod dispatches JSON-RPC requests by method name; if the method does not match any known MCP method for protocol version 2025-11-25, this METHOD_NOT_FOUND error is returned. It indicates the client requested a method this server/version does not support.

Source

Thrown at internal/server/mcp/v20251125/method.go:57

)

// ProcessMethod returns a response for the request.
func ProcessMethod(ctx context.Context, id jsonrpc.RequestId, method string, g group.Group, primitiveMgr *primitives.PrimitiveManager, body []byte, header http.Header) (any, error) {
	switch method {
	case INITIALIZE:
		return initializeHandler(ctx, id, body)
	case PING:
		return pingHandler(id)
	case TOOLS_LIST:
		return toolsListHandler(ctx, id, primitiveMgr, g, body)
	case TOOLS_CALL:
		return toolsCallHandler(ctx, id, g, primitiveMgr, body, header)
	case PROMPTS_LIST:
		return promptsListHandler(ctx, id, primitiveMgr, g, body)
	case PROMPTS_GET:
		return promptsGetHandler(ctx, id, g, primitiveMgr, body)
	default:
		err := fmt.Errorf("invalid method %s", method)
		return jsonrpc.NewError(id, jsonrpc.METHOD_NOT_FOUND, err.Error(), nil), err
	}
}

// InitializeResponse runs capability negotiation and protocol version agreement.
// This is the Initialization phase of the lifecycle for MCP client-server connections.
// Always start with the latest protocol version supported.
func initializeHandler(ctx context.Context, id jsonrpc.RequestId, body []byte) (any, error) {
	v, err := util.ToolboxVersionFromContext(ctx)
	if err != nil {
		return jsonrpc.NewError(id, jsonrpc.INTERNAL_ERROR, err.Error(), nil), err
	}

	var req InitializeRequest
	if err := json.Unmarshal(body, &req); err != nil {
		err = fmt.Errorf("invalid mcp initialize request: %w", err)
		return jsonrpc.NewError(id, jsonrpc.INVALID_REQUEST, err.Error(), nil), err
	}

View on GitHub (pinned to 8cc6e09de2)

Solutions

1. Check the exact method string in the request against the supported methods (initialize, tools/list, tools/call, prompts/list, prompts/get).
2. Ensure the client negotiated protocol version 2025-11-25; if using an older client, upgrade it or point it at the matching protocol-version server.
3. Fix typos in the method name in your client code.
4. If the method is genuinely unsupported (e.g. resources/*), remove the call or use a supported server.

Example fix

// before
{"jsonrpc":"2.0","id":1,"method":"tools/listAll"}
// after
{"jsonrpc":"2.0","id":1,"method":"tools/list"}

const SUPPORTED = ['initialize','tools/list','tools/call','prompts/list','prompts/get'];
if (!SUPPORTED.includes(method)) {
  throw new Error(`method ${method} not supported by this server/version`);
}

try {
  const res = await rpc.call(method, params);
} catch (e) {
  if (e.code === -32601) {
    // invalid method: re-negotiate initialize and use only supported methods
  } else throw e;
}

When it happens

Trigger: Sending a JSON-RPC request whose params.method is misspelled, belongs to a different MCP protocol version, or is an extension method (e.g. sampling, resources on a server without resource support).

Common situations: Client negotiated a different protocol version than 2025-11-25 and sends newer method names; typos like 'tools/call' vs 'toolsCall'; custom clients invoking methods not in the MCP spec subset implemented by the server.

Related errors

• UNSUPPORTED_PROTOCOL_VERSION
• METHOD_NOT_FOUND
• METHOD_NOT_FOUND
• METHOD_NOT_FOUND
• MCP Auth cannot be enabled together with the legacy HTTP API

AI-assisted analysis of googleapis/mcp-toolbox@8cc6e09de2 (2026-09-05). Data as JSON: /api/errors/a89f489792b9aebc. Report an issue: GitHub.