I’m not 100% sure I understand your question, so I’m going to make some assumptions. Please let me know if I’ve guessed wrong on any of them.
In 7.9+ you can think of reports as existing in two layers. The main layer, which is the report that you make in the reporting workspace of the designer (and that you execute through scripting or on a schedule), lives on the gateway and can only use gateway resources. So using anything from a client tag won’t work in that layer.
The Report Viewer component is sort of an overlay that lets you see the report that was executed on the gateway in a vision window. That layer can make use of client tags through bindings on the parameters.
If your value-description pairs don’t change from client to client, the easiest way would be to put those in a database and let your report datasource do a join to look them up.
If they could change from client to client, you have a couple of options. You can put the values in a dataset parameter (which you can override with a binding in the client), and then use a query datasource followed by a script datasource to do your lookup. A much easier way is available in 7.9.4+, with named queries. You can still have the data in a database, but the table or even the db itself can be dynamic, with the client only passing in the table/db name. This lets you do a nice clean join with a named query datasource in your report.