The master key must be a sufficiently long, randomly-generated key. It must be at least 16 bytes generated uniformly at random (not 16 random printable ASCII characters and definitely not a human-chosen password or passphrase). Otherwise it would be possible to find the master key from any of the derived passwords.
This means that the master key is not realistically memorable by a human, so this scheme is not really vaultless.
If you use HMAC as the hash, then it's ok if the master key is not generated uniformly at random, but it still needs to have sufficient entropy to make a brute force search infeasible. For example, with Diceware, you need 10 words to reach 128 bits of entropy. Given that you'd have to change all your passwords if the key is ever compromised, don't settle for less.
Generating different keys from a master key is called key derivation. You're using a MAC as a key derivation function. This is probably ok with MAC that are used in practice, but it's dodgy. Any MAC guarantees that there's no way to find the master key from any number of (input, output) pairs, except for a brute force search over the set of permitted master keys. A MAC also guarantees that there's no way to find the output for a particular input without knowing the master key, even knowing the output for some other inputs. What a MAC does not guarantee is that there's no way to find the truncated output, and password length limits may require you to truncate the output. Rather than using a MAC, use a recognized KDF, such as HKDF (which is very easy to implement on top of HMAC, if your crypto library doesn't have it).
You could replace the MAC-should-be-KDF step by a password-based key derivation function such as scrypt or Argon2. This would let you use a master key with less entropy. Password-based key derivation functions are designed to take a password as the secret input and compensate for a smaller input space (less entropy than a normal-sized key) by being intrinsically slower to compute. For example, if the stretching factor makes it 1 billion times slower than HKDF (so it takes about 1 second on a PC) then it's enough to have 7 Diceware words (giving you 120 bits of entropy). Keep in mind that in this scheme, you won't be able to upgrade the stretching factor without changing all your passwords, so choose it conservatively.
The “quality assurance” step is badly named since it (slightly) decreases the security. It doesn't separate “weak” from “strong” outputs: all outputs have exactly the same strength. The strength if the output comes from how the output was generated, not from what it is. Call it an “output constraints” step, with outcomes “acceptable” and “not acceptable”. Note that you'll need different acceptability rules for every site (for example some sites insist on the presence of a punctuation character while others reject all punctuation characters).
Remember that you'll sometimes need to change your password on a site. So you need an additional public input “version” in addition to the site name. Make sure that the site name, the version and the counter are combined unambiguously. For example, plain string concatenation would not be ok since
example.com123 could be version 1 with counter 23 or version 12 with counter 3. If you use printable strings for the site name, version and counter then you can concatenate them with a null byte as separator. You may also want to include a user name in there to support multiple accounts on the same site.
A practical limitation of this scheme is that you must only ever input the master key/passphrase on a system that you trust. This means only your own PC, only in circumstances where nobody might be spying on you (for example, not in view of security cameras). In particular, there's no way to create a password in a low-security environment and later upload it to your keyring. Every password must be generated in a high-security environment.
Since you need to carry your own PC to use this scheme, it is of limited benefit compared to a password vault. The only benefit is that if your PC is stolen while it doesn't have the master key in memory, you haven't leaked any secret. Balance that with the risk that if the master key is ever compromised, you've instantly compromised all of your passwords.
This scheme, if implemented correctly, is theoretically safe, but doesn't work well in the real world. It's well-protected against cryptographic attacks, but poorly protected against “out-of-band” attacks such as a physical keylogger, a keylogger malware or a security camera, or against revealing the master key through coercion or by accidentally typing it in the wrong field.
Your scheme is basically a single-factor authentication (only the master key) where a password vault is two-factor authentication (the vault content and the vault unlocking key). Two factors are more robust than one. A vault protected by a strong password is just as resistant to all the same attacks as your scheme, and additionally resists attacks such as shoulder surfing.
In terms of usability, both schemes require you to use your own trusted PC. Your scheme has the advantage that you can buy a new PC, retrieve your software from a trusted source, obtain an offline copy of the master key, and get access to your passwords. A vault requires the extra step of downloading the encrypted vault, but this is hardly ever a problem in practice: when would you need passwords but no have Internet access? As mentioned above, a vault has the advantage that it works in a common scenario where you want to create a password in circumstances where you don't have access to your PC, for example to create a password for shared work/personal use (e.g. a password for a travel-related site if you travel for work) on a work machine and then copy it to your personal vault.
I would strongly recommend a password vault over this scheme. It's more robust in real-world use cases.