I think you've got your ideas of clients and servers fuzzed there.
Tomcat is a webapp server. It accepts requests from web clients. Those clients may be running as applications on other server machines, but regardless, from Tomcat's point of view, only Tomcat is the server when web requests come in. Tomcat doesn't care if the request comes from a user's desktop, an Internet of Things device (I actually do a lot of that!) or another machine that itself hosts webapp servers. And, of course, using web services, it's not uncommon for a web request to come into one server, and the web application in that server make requests to backend servers running Tomcat and/or other webapp server programs. We can put load-balancers and reverse-proxy servers in front of Tomcat as well. They are clients for Tomcat, too.
OK. Hope that makes sense. Now if you want to restrict which clients can access stuff on your Tomcat server, you have 2 primary choices. One is via a user identity and the other is by blocking everything at the network level. Often we'll do a little of both.
Using a user login on a Tomcat webapp allows you to establish a security session and you can use this session to allow access only to certain URLs served by the Tomcat server. So, for example, my client may no be allowed to access URLs whose resource path is /admin unless I've granted an admin role to that userid.
Blocking at the network level is usually all-or-nothing for the source IP address. You CAN use a Tomcat Valve to limit what IPs Tomcat will listen to, but it's usually easier to employ the firewall of the machine that Tomcat's running in. Changing a Tomcat Valve requires modifying the basic Tomcat configuration, which requires restarting Tomcat. And should only be done by people who understand Tomcat. Filtering via OS firewall, on the other hand, is a standard sysadmin task and does not require stopping and restarting Tomcat. Also incoming requests are blocked well upstream of Tomcat, which reduces the amount of mayhem that Bad Packets could exploit security weaknesses downstream.
There's also another option, rarely used, where you assign client security certficates and define corresponding keys in your Tomcat server. Doing this eliminates the need for an explicit login and password, but it's best used for permanent internal client machines. The problem with client certs is that 1) if the client machine gets stolen, so does the cert and the thief can happily chat to your Tomcat server, subject only to firewall restrictions. The other problem is that if the client machine breaks down and has to be swapped out, you have to ensure that the replacement has its own security cert installed.