If you truly feel you need to clear it, then yes, restarting SQL Server will clear it. However, that will likely be a temporary solution and you'll be back in the same condition after a few days. Restarting SQL Server is the only way to clear the tempdb content from a SQL Server perspective. Another possible alternative would be to restart the application that is creating the objects in tempdb.
It's impossible for us, given the bit of information that you provide, to know what the best course of action is. Some things to consider:
Just because SolarWinds says something is a problem doesn't necessarily mean it's a problem. Many monitoring tools are set with defaults that will send "critical" alerts for things that are 100% expected on a given server. For example, I would expect a Dynamics AX SQL Server to trigger many of the default tempdb thresholds of most monitoring tools. If there is no significant tempdb contention and it's not running out of space, then there's probably nothing critical. Is the application that is using the SQL Server having performance issues? Is anyone complaining about performance? If not, then the SolarWinds alerts aren't reflecting reality and thresholds maybe need to be adjusted. One thing to keep in mind is that many of these applications were initially coded and tested when storage was much slower. If you have tempdb on SSDs, they can take much more beating than a couple of mirrored local SCSI disks that were probably used when SolarWinds decided what thresholds to use.
Do you have tempdb sized appropriately? Some application make heavy use of tempdb and will need far more than other applications typically use. If tempdb is just running out of space, you may just need larger files for tempdb
Do you have one tempdb database file for each processor, with a maximum of 8?
Do you have trace flags 1117 and 1118 enabled if you are using SQL Server 2014 or earlier? If not, research them--if you have an application that has significant tempdb usage, you'll probably want to enable these (I see you have used the sql-server-2016 tag, so this is for the benefit of other readers).
Is there a defect in an application that is causing it to "leak" tempdb objects? If the number of tempdb tables and usage is constantly climbing and never stabilizes, then it would be advisable to investigate this.
If you can't resist the urge to shrink it, shrink it with TRUNCATEONLY. TRUNCATEONLY may shrink it a lot, or none--it just depends on where the last used extent is. If you shrink it to a specified size, it will start reorganizing the data (i.e., fragmenting it) in order to move data from the end of the file to any free space that exists in the middle. In order to do that it will require locks and your users/application my have significant performance impact. And you never know how long it's going to take to reorganize that data.
If you have more info to add to the question about the exact metric(s) SolarWinds is alerting on that would be helpful.