Private MCP Servers: Share Your Data Without Sharing Your Keys

There's a pattern that keeps coming up as teams start building real workflows with MCP: you want to give a teammate access to your MCP server, but the server calls a database or internal API with a key you don't want to hand out.

The usual workarounds are messy. You either share the raw API key (bad), spin up a separate MCP with a read-only key (cumbersome), or just don't share it and do the AI work yourself (defeats the point).

Private servers are the clean solution.

What private servers do

When you mark an MCP server as Private, Shredly stores your upstream API key securely and removes it from the picture entirely for callers. Instead of supplying an upstream token, callers authenticate using their Shredly API key. Shredly validates who they are, checks whether they have access, and injects the stored upstream key into the request on their behalf.

The upstream key never touches the caller's machine. They can't see it, copy it, or use it outside the MCP.

Public vs. private: when to use each

Public servers are the right default when every user has their own account on the upstream service. The caller supplies their own token; Shredly passes it through. Works great for APIs where access is inherently per-user — GitHub, Notion, Google APIs.

Private servers are for shared resources where you own one key and want to control who uses it:

• An internal Supabase database with a service role key
• A company API with a single team credential
• A third-party tool where your account has the data

With a private server, you decide who gets in. Everyone who does gets exactly the same access — your stored key — without any of them knowing what it is.

Sharing a private server

The flow is intentionally simple.

Step 1: The recipient gets their person ID. They connect to the Shredly MCP Builder and ask: "What is my Shredly person ID?" The AI calls getMySession and returns it. This ID is stable — they only need to look it up once.

Step 2: You grant access. With the Shredly MCP Builder:

Share my "acme-internal" server with person ID abc123...

Or use the Share a Private Server skill for a guided walkthrough.

Step 3: They connect. The recipient points their MCP client at your server's endpoint and uses their own Shredly API key as the Bearer token. That's it.

Access is live immediately. Revoking it is one call to unshareServer — also immediate.

What makes this better than sharing credentials

The obvious thing: you're not handing out a raw API key. But there are a few less obvious benefits too.

Auditability. Every tool call goes through Shredly's request logs. You can see who called what, when, and from what IP. With a shared credential you'd have no idea — all calls look the same.

Instant revocation. Removing someone's access takes one command and takes effect on the next request. There's no key to rotate, no downstream systems to notify.

Access is invisible to callers. Unauthorized callers get a 404 — not a 403. Private servers don't advertise their own existence.

Setting this up

Use the Shredly MCP Builder to set a server to private:

Set my server to Private with api_key eyJ...

Then use shareServer to invite whoever needs access.

The full reference — including all four sharing tools and the guided skill — is in the Private Servers & Sharing documentation.