The date in the sidebar of every reviewed entry is the least interesting thing on the page and the most important thing about it. It is a promise with an expiry, and it should be read as one.
What was checked on that date
Five things, in this order: the install command resolves; the transport matches what the client expects; the description on this page matches what the project actually does; the permission the server asks for was read; and the failure mode — what happens when an agent misreads a request — was written down.
That is a reading, not a test suite. We do not run the server against your data, and we do not audit its dependencies.
What was not checked
**The code.** We read documentation and, where relevant, the tool registration. We do not review the implementation for bugs or vulnerabilities.
**Your configuration.** A server we reviewed positively can be dangerous with the token you give it. The permission model is yours to set.
**The current release.** A date tells you when we looked, not what version you will install today.
When a date gets old
Thirty days is the point at which we stop calling it current. After that the entry still exists and still says what we found, but the field that says 'verified' is telling you how much to trust it, not claiming it is true now.
That is why the package table exists without dates: mechanical facts (a version, a download count, an install command) can be regenerated nightly. An editorial claim cannot, so it carries a date instead of pretending to be live.
Why not verify more often
Because it would be a lie about capacity. A weekly full pass over 127 entries is only possible with automation, and automation cannot judge a description — which is the part that actually needs a person.
A date that is honest is worth more than a badge that is always green. When you see a date three weeks old, you know someone looked three weeks ago. That is the entire claim.