Check whether you would ever hear about a failed TLS delivery to your own mail servers.
TLS-RPT asks receiving providers to send you a daily summary of how TLS delivery to your domain went: what succeeded, what failed, and why. It changes no delivery behaviour on its own. It exists so that a failure is visible.
Without it the failures are silent by nature. An expired certificate on your own MX, a downgrade attack in progress, a misconfigured MTA-STS policy rejecting legitimate senders: none of these produces a bounce you will see, because the problem is on the sending side and the sender simply gives up or falls back. The first you hear of it is a customer saying they emailed you last week.
It costs one DNS record and an address to receive reports at, and it is the cheapest visibility available anywhere in mail. Anyone publishing MTA-STS should publish this at the same time, because enforcing TLS without watching the failures is how you discover a broken policy from a complaint rather than a report.
Compressed JSON, sent daily by each provider that delivered to you. They are meant for tooling rather than reading by hand, which is what a monitoring service does with them.
No. TLS-RPT is useful on its own and is the safer of the two to publish first, because it only observes. Reading the reports for a few weeks tells you whether enforcing would break anything.