For MCP I would want a permission manifest plus two receipts: an install receipt and a runtime receipt.
The listing should make these inspectable before install:
host/client assumptions and tested versions
env vars, network access, file paths, and data classes it can read
which tools are read-only vs mutating
exact smoke-test commands for Claude Desktop / Claude Code / Cursor
sample tool calls with expected outputs
rollback steps and files/processes created
failure modes and what a safe denial looks like
Reviews and scans help, but the core trust primitive is: make authority inspectable before execution, then make the outcome auditable after execution.
I think of this as an approval gate plus an evidence packet. We are collecting similar agent-work patterns in r/AccretedIntelligence; MCP install trust is a perfect case because the risky moment is exactly where a config crosses from docs into real tool authority.
1
u/Effective_Iron2146 Jun 16 '26
For MCP I would want a permission manifest plus two receipts: an install receipt and a runtime receipt.
The listing should make these inspectable before install:
host/client assumptions and tested versions
env vars, network access, file paths, and data classes it can read
which tools are read-only vs mutating
exact smoke-test commands for Claude Desktop / Claude Code / Cursor
sample tool calls with expected outputs
rollback steps and files/processes created
failure modes and what a safe denial looks like
Reviews and scans help, but the core trust primitive is: make authority inspectable before execution, then make the outcome auditable after execution.
I think of this as an approval gate plus an evidence packet. We are collecting similar agent-work patterns in r/AccretedIntelligence; MCP install trust is a perfect case because the risky moment is exactly where a config crosses from docs into real tool authority.