Download the module and modify ROOT_MSSQLstub.ps1 - out of the box it lists just the current server. You will probably want to add more from one of the inventories. Contribute more on Github.
This module exposes a lot of SQL server statistics, metrics, and even source code. No actual data is exposed, only aggregations. You can add reports to select data from specific tables, which you consider technical, so there is no sensitive data inside. All other reports should be safe. Still, some sensitive data can leak thru queries, for example, in Activity Monitor in the hardcoded constants of the queries in WHERE conditions, for example. You can add something like
$v = $v -replace "'([^']{2,})'", "'str'" -replace "[0-9][0-9]+", '999'
to replace all big numeric constants with 999 and 'long strings' with 'str', leaving simple values like =0, =1, ='Y', ='N' intact.
Here is the big picture:
At the top level, we have server-wide statistics:
At a database level we can get the 'biggest tables report' we usually use in SSMS and much more:
We can open any programmatic objects (functions, views, procedures) to inspect the code to confirm that it is really the version we expect. Of course, you can't change the code, it is read only.
When you expand the table list, you can see the number of records in the tables.
Column selectivity report spots values with low and irregular selectivity. Column RecordsInMostFreqVal is the number of records with the 'top 1' value. The last column in the same in percent to the total number of rows, so you can see that while there are 72 distinct values in ReferenceorderLineID, 46% has the same value. Probably it is ID=1, but Bell hides any actual data from a user.
The fragmentation report shows how badly data is fragmented, and charts (Chart by Columns...) are created for all datetime columns, so user can check the distribution - the number of values by date.
The index coverage report lists all columns, covered by any index at least once. Leading column in an index is marked with '1', second with '2' etc. Yuo can easily spot overindexing and bad indexing.
Finally, in SQL server Performance, we can filter SQL error log by day: