Yes, its possible but you have to rely on RSTP itself to block one of the links, as you know there is no link aggregation on the MX devices. Although the MX doesn't participate in RSTP it will forward BPDUs.
Configure another port on the MS355 stack the same as the one currently connected to the MX, and likewise on the MX configure another port that is identical to the one connecting to the MS355 stack, and then put a cable between them.
BPDUs will be sent up the links, forwarded by the MX, and then down the other link back to MS355 stack. On receiving its own BPDUs the MS355 stack will block one of the ports based on the interface/port number (which goes towards determining the superior BPDU), so one of the ports will be blocked, and the other will become designated. Then if you experience a failure BPDUs will cease to be received on the blocked port and it will move into the designated state.
Couple of points: the ports will ideally need to be trunk ports on the MS. Ensure RSTP is enabled on the MS. If they are access ports then they'll run PortFast by default which will cause an initial issue, but it should recover. You shouldn't need to run Loop Guard or Root Guard, and you definitely don't want BPDU Guard on the ports.
I personally DO rely on STP to resolve these uplinks.
If you designed your network well then you should not have any STP events that could cause an STP crash at your Core switches. It is in the design documents of Meraki and they will fully support this. A stackmember failure can happen too causing a blackhole because someone onsite has to refit the uplink to the other switch...
In the above drawing you can see a stack that is uplinked to two MX appliances in a HA configuration. I would always uplink two stack members, not three or more so you can easily predict what should happen with the blocked links. Here you can see the first switch blocking both it's links that go to the master and the spare. On the second switch you can see port 23 that goes to the spare which is not marked as uplink because of it and port 24 that is connected to the master MX so that port is marked as uplink for the stack.
The uplinks are made as follows: MX Master 3 -> SW1/23 MX Master 4 -> SW2/24 MX Spare 3 -> SW2/23 MX Spare 4-> SW1/24
The only weird thing in my book is that stackmember two is apparently having lower switchport ID's and thus it gets the forwarding ports instead of switch 1. It does not matter in the end but that's one of the things that you just cannot configure on Meraki 🙂
We use TP-Link switches on the edge.. non managed of course. This was after days of troubleshooting with Cisco Meraki support they finally said it wasn't supported. I suppose there are ways to do it, but at that point we found non-managed switches on the edge worked best for us.