Summary
The current requirement that publicly listed MCP connectors be backed by a hosted production server unintentionally excludes an entire class of privacy-preserving software — particularly end-to-end encrypted (E2EE) and zero-knowledge applications.
Please consider supporting locally running (stdio) MCP servers, paired with a per-user, outbound-only authenticated connection (for example, a secure tunnel) where a network path is required, as a valid distribution model for the public directory. This would allow security-sensitive applications to participate without requiring users’ credentials, encryption keys, or authenticated sessions to leave their own devices.
This isn’t about supporting one specific product, but about enabling an entire category of local-first software that cannot safely adopt today’s hosted deployment model.
Background
I’ve built a ChatGPT connector for an end-to-end encrypted, zero-knowledge cloud storage platform. I’ll intentionally leave the product unnamed, because the architectural issue applies far beyond any single application.
The connector runs as a local stdio MCP server and communicates with the platform’s official command-line client already installed on the user’s machine. By design:
- Authentication happens entirely outside of ChatGPT — the user signs in directly through the CLI’s native password prompt.
- Credentials never pass through the model, MCP tools, or tool arguments.
- Encryption keys never leave the user’s device.
- Authenticated sessions remain entirely local.
This preserves the platform’s zero-knowledge guarantees while still exposing useful functionality through MCP.
Because the connector is local-first rather than centrally hosted, it cannot currently be published in the public directory. I raised this with OpenAI Support, who confirmed that a local/tunnel-backed connector can’t be listed today and suggested I post it here as a feature request.
Why This Matters
The issue isn’t simply that a hosted server is less convenient. For many E2EE systems, requiring a shared hosted production service fundamentally changes the trust model.
A hosted backend generally requires one of the following:
- becoming a custodian (or proxy) for user credentials or authenticated sessions;
- terminating and re-establishing encrypted communication;
- introducing a trusted intermediary where none previously existed.
Even when implemented carefully, this expands the attack surface from an individual user’s own machine to centralized infrastructure serving every user. For zero-knowledge platforms, that is often incompatible with the very security model they are designed to provide. The local-first architecture avoids this entirely, because the trust boundary never leaves the user’s own device.
This Isn’t Lower Security — It’s Often Stronger Security
This request isn’t asking OpenAI to relax its security requirements. For many of these applications, local execution is actually the stronger posture:
- There is no central service storing or proxying credentials, keys, or plaintext — so no high-value target aggregating every user’s secrets.
- Compromising one user’s machine exposes only that user, never the entire user base.
- The security properties the platform already provides — its threat model, audits, and encryption — remain intact, rather than being partially reconstructed inside a new hosted layer.
For privacy-sensitive applications, keeping execution local is a feature, not a limitation.
A Broader Ecosystem Issue
This extends well beyond encrypted cloud storage. Many categories of software are fundamentally local-first, including:
- Password managers
- Encrypted storage
- Developer tooling
- SSH utilities
- Local databases
- Desktop automation
- Hardware integrations
- Self-hosted services
- Enterprise software that intentionally keeps secrets on-device
These are natural fits for MCP, yet many cannot reasonably adopt a centrally hosted production server without weakening their existing security architecture. Anthropic already supports connectors that run locally like this, so it’s a bit of a shame the same isn’t yet possible here — the model fits MCP so naturally. As MCP continues to grow, supporting it would meaningfully broaden the ecosystem of connectors that can participate.
Possible Solutions
Any of the following would solve the problem:
1. Support local stdio MCP servers. Allow local stdio servers as a supported distribution model for public directory connectors.
2. Add a desktop distribution model. Introduce a desktop/local distribution path for directory-listed connectors (similar to packaged extensions), allowing installation without a hosted backend.
3. Support zero-knowledge relay architectures. If a hosted endpoint must exist, define a supported “thin relay” model where the hosted component never stores credentials, encryption keys, or plaintext — allowing zero-knowledge connectors to remain compliant.
Benefits
Supporting local-first connectors would:
- Let privacy-preserving software participate in the public directory without weakening its security model.
- Keep credentials and encryption keys on the user’s device, reducing centralized exposure.
- Broaden the diversity of connectors in the ecosystem — password managers, encrypted storage, developer tooling, and more.
Closing
I completely understand why hosted production services are the default today — they simplify reliability, availability, and operational review. But they also unintentionally exclude an entire category of applications whose defining property is that they cannot safely centralize user trust.
Supporting local-first MCP connectors, or providing an equivalent distribution model, would let the directory embrace privacy-preserving software without compromising either user security or the principles behind end-to-end encryption.
I’d be happy to share the architecture in more detail, or to help evaluate possible approaches, if this is something the team is interested in exploring. Thank you for considering it.