The way a stateless password manager like this works is that it defines some function F(url, username, counter, settings, master_password) and F() returns some random string which is the password for the site. The settings include the characters to use (a-z, A-Z, 0-9, and symbols - each a boolean - so, 4 options for a total of 16 combinations; there is also a length parameter defaulting to 16 - but lets assume that users primarily use 8 - 20 for a total of 12 different values. This gives us a total of 12 * 16 = 192 total values for the settings field). The user is expected to remember the counter in some way - but the default is 1 and we can assume that most users have a counter value somewhere between 1 and 10. The function F() hashes all this stuff up in some sort of unchangeable way (changing it would modify every password and would thus render the whole thing useless) and produces the random password. Let's note: the url of the site and the username are both public information. As above, the settings field has ~192 possible values. And the counter has ~10 possible values. The only thing that has significant entropy is the master_password.
So, we have an equation that looks like: site_password = F(url, username, counter, settings, master_password). But, as above, we know url and username and there are only about 1,920 combinations that are likely for settings and counter.
Let's say you use this to generate a password for some site that stores the password in plain text. If an attacker gets that password, they now have the opportunity to brute for the master_password value. A GPU based attacked can attempt a very large number of passwords per second (hundreds of thousands to billions per second, depending on how F() works) in a fully offline manner - the only thing slowing them down is that each master password that they check has to be rechecked against each of the 1,920 combinations for settings and counter. This slowdown is extremely minor when the attacker can run a tremendous number of guesses for the master_password in parallel. The settings and counter field basically work as a salt - but unlike a real salt value that would generally be a 32 or 64 bit number, this salt is super tiny.
Anyway, a competent attacker will figure out how to brute force the master_password without too much effort. And the big problem is that that master_password can then be used directly to calculate the site_password for every other site that you log into. A couple reasonable guesses about what counter you used and what settings you likely used for your bank (likely the defaults) and the attacker is in.
The combination of settings and counter provide no real security. If a password is stolen from some random low-value website, the attacker has an easy way to figure out your master_password and thus your site_password for actually valuable sites. You have no way to defeat this outside of changing your master_password - which changes the site_password for every site you use which more or less defeats the entire purpose of this scheme.
Realistically, the biggest security benefit of this scheme is that almost no one uses this type of stateless password manager because of the other obvious ergonomic problems (ie: you have to somehow remember the value of counter and settings that you picked - which is a pain to do for more than a couple websites). But, that is security through obscurity which has long been (rightly) viewed as bad security.
Don't use this. Don't use any stateless password manager. It's fake security.