Here is the response description from the TPM 2.0 spec for the parameters returned from Certify and CertifyCreation:

Here is decodeCertify which is used by all 3 of Certify, CertifyEx, and CertifyCreation:

In particular, note that the second parameter is signature which is the parsed raw RSA signature (exponentiated plaintext modulo key's modulus) or ECDSA signature (r, s pair). This is a loss of the following data:

• sigAlg from TPMT_SIGNATURE
• hash from TPMS_SIGNATURE_ECC if sigAlg indicated an ECC signature, or from TPMS_SIGNATURE_RSA if sigAlg indicated an RSA signature.

This means that a consumer of the output of the Certify command (via Certify or CertifyEx) or CertifyCreation command has to remember or guess the signature algorithm, as well as the hash algorithm that was used.

• Guessing the sigAlg parameter is not trivially "if it's small, it's ECC, else RSA" because TPM supports multiple schemes per algorithm family (e.g., either PSS or PKCS1.5 for RSA). So throwing this data away harms potential users of the API.
• Guessing the hash is reasonably done in 2021 by assuming it's SHA2-256, but this is subject to change and should be expected to as more TPMs support SHA2-384 and users become interested in that algorithm.