These pages would appear to be generated by the tags component, which are paginated lists of articles.
Each individual tag can have separate meta data if you create a
tagged items menu item for each one, though sub-pages within each tag can not have their own meta data.
Whilst it should technically be possible to write a plug-in to achieve this, it would seem a mistake since it does actually make sense that they share meta data between list pages. This is because the purpose of each page is exactly the same - ie to list articles that match that specific tag. There is no logical change of description to individualise these beyond possibly "page x of...".
It is also possible for users to be able to switch between amounts shown per-page, so the page shown to the user may not always be the same as the one in Google.
Google's guidelines on paginated content are here: https://webmasters.googleblog.com/2011/09/pagination-with-relnext-and-relprev.html
They do say that doing nothing is an option:
Leave whatever you have exactly as-is. Paginated content exists
throughout the web and we’ll continue to strive to give searchers the
best result, regardless of the page’s rel=”next”/rel=”prev” HTML
markup—or lack thereof.
If you want to add the
rel="next" tags, these can be overriden in your template. An example of a pagination override in action can be seen in the core Protostar template under templates/protostar/html/pagination.php
You could possible also set the first page as canonical, again with an override.
Ultimately, I wouldn't worry about listings pages - beyond helping Google crawl your site, they don't have any major SEO benefit. It's the actual article pages that need to be listed correctly.