ZKshare stdio MCP: store/prove/share, semantic search, sandbox proxy to HTTPS /api/v1/context.
MCPpedia last refreshed this data
io.github.sp0oby/zkshare is an MCP server that ZKshare stdio MCP: store/prove/share, semantic search, sandbox proxy to HTTPS /api/v1/context. Its tool list has not been published yet over stdio, sse and http, requires no API key, and scores 77/100 on MCPpedia's security, maintenance and efficiency rubric.
Config is the same across clients - only the file and path differ.
{
"mcpServers": {
"io-github-sp0oby-zkshare": {
"args": [
"-y",
"zkshare-mcp"
],
"command": "npx"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
ZKshare stdio MCP: store/prove/share, semantic search, sandbox proxy to HTTPS /api/v1/context.
This server supports HTTP transport. Be the first to test it - help the community know if it works.
Five weighted categories - click any category to see the underlying evidence.
No known CVEs.
Checked zkshare-mcp against OSV.dev.
Click any tool to inspect its schema.
Be the first to review
Have you used this server?
Share your experience - it helps other developers decide.
Sign in to write a review.
Others in search
Open-source web scraper for AI agents with scrape, crawl, and map tools
MCP server for advanced web search using Tavily
MCP server for enterprise local codebase indexing, semantic search, and code dependency graphs.
The official MCP server implementation for the Perplexity API Platform
MCP Security Weekly
Get CVE alerts and security updates for io.github.sp0oby/zkshare and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
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 data, end-to-end-encrypted (client-sealed) facts, and a
isolated sandbox execution for sensitive computations. The implementation is a Next.js
(App Router) application backed by PostgreSQL with pgvector.
This document is for developers integrating against the API and operators self-hosting the service. It is not a marketing brochure — pricing tiers, dashboards, and billing are optional layers defined separately in the application code.
The platform is designed around three trust boundaries:
| Boundary | What the operator can see | What stays private |
|---|---|---|
| Server-sealed store | Ciphertext, IV, auth tag, commitment, embedding vector. The server holds the AES-256-GCM key (ZKSHARE_ENCRYPTION_SECRET) and decrypts in memory only when the caller invokes prove, share, or search summaries. | Database operators (without the encryption secret) and direct table readers (RLS denies anon and authenticated) cannot read plaintext. |
| Client-sealed (E2EE) store | Opaque ciphertext blobs, IV, auth tag, commitment, and a caller-supplied embedding vector. The server never receives or derives plaintext, and never calls an embedding model on the fact. | The platform operator. Decryption requires the caller's own key, which never leaves the caller. |
| Proof envelopes | A versioned, HMAC-signed JSON envelope (commitment + query + yes/no answer + nonce). Verifiable by anyone holding ZKSHARE_PROOF_SECRET. | The fact plaintext used to derive the answer is never included in the envelope. |
verify_proof.share_token
bound to a recipient agent identifier.SECURITY.md is the canonical reference for the threat model, the trust
model summary, vulnerability disclosure, the operator checklist, and third-party LLM exposure
controls.
| 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: caller sends ciphertext, iv, auth_tag, commitment, and the required embedding. Server stores blobs and the vector, sets client_encrypted = true, and never derives anything from the plaintext or label. |
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 422 / CLIENT_ENCRYPTED if the fact is client-sealed. |
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 ove |