Generally speaking, with MTR (or WinMTR) you shouldn't focus on the packet loss of intermediate hops too much because it's usually caused by thresholds on the ICMP traffic destined to themselves (because usually this kind of traffic require additional resources from them). If you see some amount of packet loss on an hop, followed by a 0% packet loss on the next hop you can be pretty sure that it's not a loss that will affect your traffic actually (in other words, a real loss on one specific hop will show the same or more packet loss in ALL the next hops till the destination). Also, take a look at latency average to understand the performance, keeping an eye on the standard deviation (if it's too high the average latency makes no sense, but I'm not sure WinMTR can show it btw).
By looking at your output anyway, I see about 2% loss and a latency around 160ms to the last tracked hop, nothing that give evidence of an unusable network honestly.
Unfortunately your MTR doesn't show the full path, but if you have the same issue with other internet services you might track IPs that reply like 8.8.8.8 .
However, keep in mind that MTR doesn't represent the same flow you're using with your service; in order to test this connectivity better you should set up an "iperf " test that uses the same sockets of yours, but this is something not achievable if you don't have any access to the remote network. With MTR only, bandwidth information are missed, your traffic could be shaped/policed along the path in a different way compared to the one applied to MTR traffic, and so on.
Again, if your issues are not related to that specific service only, but to the whole Internet surfing, tests like www.speedtest.net/ could give you great insights.