The idea of using static key pairs is indeed that data in the key exchange gets signed. It doesn't matter too much what gets signed, as long as it the key exchange cannot be performed by an adversary.
To verify signatures it is required that the public key of the signer needs to be trusted. This is what you are missing in the description. If the verifier only accepts that one key or one set of keys then the signature of the adversary gets rejected, signature verification fails and the keys do not get established or used.
How to put trust the public key then becomes the next problem. This is not part of the key agreement protocol. One way is to explicitly trust one public key, for instance by verifying a fingerprint of the public key over the phone. It may also be that the key is uploaded over a trusted channel; this is something that is for instance often performed with SSH public keys.
For TLS the trust is established by trusting (root) certificates of certificate authorities. These are then responsible for only creating certificates for entities that can show that they control a certain domain. These certificates both contain that domain as well as the public key used for verification. This structure is called PKIX: Public Key Infrastructure using X.509 certificates and Certificate Revocation Lists.
Some notes:
- I've removed any mention of the key agreement or signature generation / verification algorithms - the algorithms used are not important to this question.
- It is also possible to trust a (static) Diffie-Hellman public key, but you would loose forward secrecy - if the long-term private key of that key pair leaks the the adversary could replay the key agreement and decrypt all messages (and it also complicates the PKI).
- Signature generation is not the same as signing a message or message hash and verification is not the same as "decryption with the public key" - the Diffie-Hellman public key would just be send in the clear along with the signature over it.
- There may be additional access control required after the session is established - that's why the certificate used to create a connection is often passed to the back-end and used in an access control system of some kind.
