Privacy-oriented context API for users, AI agents, and back-office systems. A single HTTP entrypoint (`POST /api/v1/context`) handles **encrypted
Privacy-oriented context API for users, AI agents, and back-office systems. A single HTTP entrypoint (POST /api/v1/context) handles encrypted fact storage, commitment-based proof envelopes, **semantic search over encrypted. That is what the zkshare mcp server brings to an AI assistant: the same capability, reachable through the Model Context Protocol rather than a separate app or dashboard.
The server publishes 7 tools. What each one is for:
Operation — Behaviorstore — Server-sealed: caller sends value. Server encrypts with AES-256-GCM, computes a salted commitment, generates an embedding (or accepts a 1536-dimprove — Loads a server-sealed fact, decrypts in memory, derives a yes/no answer for the supplied query (LLM with temperature: 0, or a heuristic when externalshare — Same as prove, plus inserts a row into share_tokens (recipient_agent_id, expiry, proof) and returns a share_token. The token is a 24-byte base64urlsearch — Embeds the query, calls match_facts (a security definer SQL function with cosine distance over pgvector), and returns ranked summaries forverify_proof — Validates an envelope without loading any fact. Malformed envelope returns 400 / VALIDATION_ERROR; well-formed envelope with a bad HMAC returns 200sandbox — Executes a small allow-listed function inside an isolated node:vm sandbox (no host I/O, 50 ms timeout) and returns the result with attestationConfiguration is passed through the environment: ZKSHARE_API_KEY, ZKSHARE_API_URL, ZKSHARE_ENCRYPTION_SECRET, ZKSHARE_PROOF_SECRET, INVALID_API_KEY, ZKSHARE_ENCLAVE_JWT_SECRET, UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.
zkshare-mcp on npm is all you need. Most clients run it directly, so configuration is a few lines and a restart.
This sits in the database access group, where several servers overlap in what they claim to do but differ sharply once you actually set them up. Zkshare's toolset — Operation, store, prove and 4 more — is a fair guide to whether it matches your workflow. It is maintained by sp0oby; worth a glance at recent repository activity before you build anything load-bearing on it.
We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.
| Tool | What it does |
|---|---|
| Operation | Behavior |
| store | **Server-sealed:** caller sends value. Server encrypts with AES-256-GCM, computes a salted commitment, generates an embedding (or accepts a 1536-dim embedding), and persists with client_encrypted = false. **Client-sealed |
| prove | Loads a server-sealed fact, decrypts in memory, derives a yes/no answer for the supplied query (LLM with temperature: 0, or a heuristic when external LLMs are disabled), and returns an HMAC-signed proof envelope. Returns |
| share | Same as prove, plus inserts a row into share_tokens (recipient_agent_id, expiry, proof) and returns a share_token. The token is a 24-byte base64url string, valid for seven days. |
| search | Embeds the query, calls match_facts (a security definer SQL function with cosine distance over pgvector), and returns ranked summaries for **server-sealed rows only**. Client-sealed rows are excluded at the SQL level **a |
| verify_proof | Validates an envelope without loading any fact. Malformed envelope returns 400 / VALIDATION_ERROR; well-formed envelope with a bad HMAC returns 200 with data.valid: false. |
| sandbox | Executes a small allow-listed function inside an isolated node:vm sandbox (no host I/O, 50 ms timeout) and returns the result with attestation metadata and a short-lived HS256 JWT (proof_of_execution). Every response adv |
// ~/.cursor/mcp.json
{
"mcpServers": {
"zkshare": {
"command": "npx",
"args": ["-y", "zkshare-mcp"],
"env": {
"ZKSHARE_API_KEY": "zk_live_…",
"ZKSHARE_API_URL": "https://zkshare.io"
}
}
}
}Configuration as documented by the project. Restart the client after saving.
| Variable | Description | Required |
|---|---|---|
| ZKSHARE_API_KEY | Credential the server authenticates with. | Yes |
| ZKSHARE_API_URL | Endpoint or connection string the server talks to. | Yes |
| ZKSHARE_ENCRYPTION_SECRET | Credential the server authenticates with. | Yes |
| ZKSHARE_PROOF_SECRET | Credential the server authenticates with. | Yes |
| INVALID_API_KEY | Credential the server authenticates with. | Yes |
| ZKSHARE_ENCLAVE_JWT_SECRET | Credential the server authenticates with. | Yes |
| UPSTASH_REDIS_REST_URL | Endpoint or connection string the server talks to. | Yes |
| UPSTASH_REDIS_REST_TOKEN | Credential the server authenticates with. | Yes |
Read-only SQL access to Postgres — let your assistant inspect schemas and answer questions from real data.
Manage your whole Supabase project in conversation — database, auth, storage, Edge Functions and branches.
Query, modify and analyse local SQLite databases in conversation — the fastest way to chat with a data file.
Metabase ships its own MCP endpoint — search your BI content, build and run queries, and save questions and dashboards without leaving the chat.
Official MongoDB server covering data, schemas and Atlas management — from find queries to spinning up clusters.
Serverless Postgres with database branching — point your assistant at Neon and let it work on disposable copies.