By definition, one-time pad key must be truly random, not derived by function. So if you have 1MB of truly random data, you do not need KDF function to derive key. And if yo do nout have 1MB of truly random data, yout encryption function is not one-time pad.
I don't know if there's a checklist per se, but below are a couple of elements I can think of. Before that, I'll just reiterate (like state elsewhere) that a KDF doesn't produce a one-time pad. I suppose the goal is to achieve something akin to a stream cipher. Anyway, KDFs... A starting point is what are the assumptions on the initial key material?
Uniform random bit string of sufficient length? Then your KDF will probably need to be a secure variable output length pseudo random function. HKDF-Expand can (in theory) generate up to 8160 bytes.
Non-uniform but high (min) entropy ? For a good starting, point, thorough discussion and formalization on KDF security is presented in HKDF paper. In short, a KDF is seen as an algorithm taking some initial keying material, some salt; and outputs a key of some length based on some (non necessarily secret) label. For security, it is demanded that the output key looks random even if an attacker is allowed to see output of the KDF over an arbitrary label. In the previous, the same initial keying material and salt are used, but the attacker can't obviously ask the output on the legit label.
Low entropy data like a password? Then a good starting point is looking into the state-of-the art in password based KDFs and all the pitfalls to pay attention too.
Designing such things is hard, analyzing them (based on reasonable assumptions) isn't easier. So an additional element for this "checklist" would be, understanding the security guarantees of existing schemes and the requirements of the context where they will be used. From there, we can decide on the best choice for each use case.