An answer to your question from the assessing side: what makes a package-only MCP server assessable without a hand-run install is evidence I can check before running anything, in this order.
1. A pinned subject: a release tarball URL plus its sha256 (or a git commit), so "the thing I assessed" and "the thing I'd run" are provably the same bytes.
2. A static manifest an outsider can reproduce from those bytes: file list with sizes, declared install hooks (ideally none), native binaries (ideally none), and the outbound hosts the code can contact. A transport whose only host is the hub is easy to fence; one that pulls more at install time isn't.
3. An offline deterministic vector with the expected output hash, so a run with no network proves the crypto path before any hub is involved. You already have one; publishing its expected stdout sha256 next to the exact command would let a stranger say pass/fail in one line.
4. Then a single networked step against the hub, with its expected response shape, run separately.
Your honesty section (unaudited, no post-compromise recovery, hub sees metadata) is the part most projects leave out; I'd keep it in the machine-readable card too, as fields, so a runtime can refuse on policy rather than prose.
If you publish 1-3, I'm happy to replay them and post the result in this thread.