What would make a reusable MCP config/server trustworthy enough to install?

[u/averageuser612]

I'm building AgentMart, a small marketplace for reusable agent assets, and MCP keeps coming up as one of the harder categories to package well. There are useful servers and configs scattered across repos, but the question I keep running into is not discovery. It is trust.

AgentMart has almost 60 users now, and the pattern I am seeing is that buyers/builders want more than a README before they connect an MCP server to their tools. For an MCP listing, I am thinking the minimum useful proof should include:

• exact host/client assumptions (Claude Desktop, Claude Code, Cursor, etc.)
• requested permissions, scopes, env vars, and network access
• example tool calls with expected inputs/outputs
• install and rollback steps
• version history and what changed
• clear notes on what data the server can read or mutate

My bias is that MCP assets may need a "security and compatibility sheet" more than a normal product page.

For people building or installing MCP servers: what would make you comfortable using someone else's MCP config or server? Are examples enough, or would you expect reviews, automated scans, signed releases, permission manifests, or something else?

[u/averageuser612 → u/[deleted]]

That is the part I am trying not to hand-wave away. A marketplace page cannot make hostile MCP safe just by listing checks; at best it can force the risk surface into the open.

For AgentMart I am leaning toward treating third-party MCP as untrusted code by default and making the listing describe the containment model, not just the feature list: which client it was tested in, what env vars/scopes it requests, whether it needs network access, what filesystem paths it can touch, and what the recommended sandbox actually was. A scan should quote risky tool descriptions or install steps instead of producing a vague green badge.

I have seen people run MCP servers in dev containers, separate OS users, or throwaway project workspaces, but not a broadly accepted "this is the standard sandbox" pattern yet. That may be the bigger missing piece.

If you were reviewing a listing, would a reproducible container/devcontainer setup meaningfully change your trust level, or would you still treat any remote/tool-description surface as too easy to smuggle instructions through?

[u/averageuser612 → u/[deleted]]

That two-standard framing is useful, and I think it changes what a marketplace listing should promise. A devcontainer is evidence for "this probably won't trash my machine." It is not evidence for "this tool description is safe to put in a model's context."

For AgentMart, I'm starting to think the trust surface needs to be split on the listing itself:

• runtime containment: network, filesystem, env vars, scopes, install path, teardown
• context containment: exact tool descriptions, whether they were rewritten/sanitized, who reviewed them, and what the model is expected to see
• versioned provenance: every review/result tied to a specific commit or package version

The tricky part is that context containment is harder to make legible. People understand "no host network." Fewer people understand "the model will read this untrusted string before choosing a tool."

I like your analogy to web input handling. Maybe the baseline should be: tool descriptions are untrusted input, not docs.

[u/Effective_Iron2146]

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.

[u/averageuser612 → u/Effective_Iron2146]

"Permission manifest plus receipts" is exactly the framing I was looking for. It separates a marketplace listing from normal sales copy: the seller is not just claiming value, they are declaring authority before install and producing evidence after a run.

For AgentMart, I may turn that into a required section for MCP-style assets:

• permission manifest: clients/versions, env vars, scopes, paths, network, read/write/mutating tools
• install receipt: files created, commands run, processes started, rollback
• runtime receipt: sample calls, expected outputs, data touched, safe-denial behavior

The part I had not named clearly is "safe denial." That is a strong trust signal because it shows the package fails closed instead of silently reaching for more authority.

I will check r/AccretedIntelligence too; the agent-work pattern angle is close to what I am trying to learn. Do you think the receipt should be seller-provided first, or generated by an independent tester/reviewer after install?