MCP SERVERMove a large output out of the context window and into an encrypted link — a one-shot snapshot, or a versioned workspace that two agents can both read and write.
LABSCO SUMMARY
The split between the two modes is the useful part: a share is a snapshot with a lifetime, while a workspace holds one address as the document evolves, which is what makes it a handoff channel between sessions rather than a paste bin. Writes lose to whoever committed first and hand back their content for you to merge. The security model is stated plainly by the project and worth repeating: handing someone the link hands them the key — including the model provider on the other end of the agent — and the 24-hour clock, not the encryption, is what bounds that.
An end-to-end encrypted staging area for content that should not sit in the conversation: text and files encrypted on your machine, uploaded to vnsh, and read back by link.
Nothing to configure for anonymous use: no account and no key. Content is deleted 24 hours after the last write, and each write restarts that clock; a workspace's lifetime can be set up to 168 hours. Reading depends on the link fragment being intact, because that is where the decryption key lives. Sharing a file reads it from disk, so it has to sit on the machine running the server. An account and a token keep documents until you delete them. MIT.
One command — claude mcp add vnsh -- npx -y vnsh-mcp@1.8.2
USE CASES
Put the working document in a workspace, give the other session the link, and let both sides update it in place — the address stays the same as the content changes.
Encrypt and upload the content instead of printing it, and hand back a link with a time to live. The tool names its own threshold: output past about 50 lines or 2000 characters, or any complete code file.
Encrypt the file from disk and share the link. Images, PDFs and binaries move without ever entering the conversation.
Open the workspace as a local file in the browser so an HTML report, dashboard or diagram renders the way it was meant to, without the markup crossing into the conversation.
Read what the workspace holds now, then put an earlier version back as the newest one rather than reconstructing it by hand.
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
vnsh_readSecurely retrieves and decrypts content from a vnsh URL. Use this tool whenever the user provides a vnsh.dev link or any URL with #k= and &iv= in the fragment. The content is decrypted locally - the server never sees the decryption key.
vnsh_shareEncrypts text content locally and uploads it to vnsh, returning a shareable URL. Use this when output exceeds ~50 lines or ~2000 characters, when generating complete code files, or when the user wants portable/shareable output. ALWAYS prefer vnsh_share over dumping large content into chat. The content is encrypted before upload - the server only sees encrypted bytes.
vnsh_share_fileEncrypts a local file and uploads it to vnsh, returning a shareable URL. Use this for images, screenshots, PDFs, binaries, or any file that should not be loaded into context. More efficient than vnsh_share for large or binary files.
vnsh_workspace_createCreates a shared workspace and returns one link that any agent can read AND write. Use this when work will continue somewhere else: handing a plan, status doc, design, or investigation to another agent or another session, or when the user says they will pick this up in a different tool. Unlike vnsh_share (a one-shot snapshot), a workspace keeps the same URL as its content evolves. Content is encrypted locally; the server never sees the key. Expires 24h after the last write.
vnsh_workspace_openDecrypts a vnsh workspace to a local temp file and opens it in the browser. Use this when the user wants to LOOK at a workspace rather than have its content read into context — HTML reports, dashboards, and diagrams render properly this way. Rendering happens locally from file://, so nothing is exposed to any server.
vnsh_workspace_readReads the current content of a vnsh workspace URL (a /w/ link with a #w= fragment). Use this whenever the user provides such a link — it is how you pick up work another agent left for you. Returns the content and its version number; pass that version to vnsh_workspace_update to write safely.
vnsh_workspace_updateReplaces the content of a vnsh workspace, keeping the same URL. Use this to record progress so far, revise a shared plan, or leave the next agent an updated document. Writes are version-checked: if someone else wrote first, this returns their current content so you can merge it with yours and call this again.
BEFORE YOU INSTALL
7 tools when we connected; the project documents 14. The missing seven are the four vnsh_artifact_* tools, which belong to an account-authorized mode that needs a session or VNSH_TOKEN, plus vnsh_workspace_history, vnsh_workspace_restore and vnsh_workspace_renew, which the project documents for vnsh-mcp 1.8.2 — the version the install line pins; the seven-tool count comes from version 1.4.4.
npx on PATH
VNSH_TOKEN in your environment
All 3 documented clients run the server on your machine.
INSTALLATION
claude mcp add vnsh -- npx -y vnsh-mcp@1.8.2{
"mcpServers": {
"vnsh": {
"command": "npx",
"args": [
"-y",
"vnsh-mcp@1.8.2"
]
}
}
}MCP servers
yamadashy
khromov
yzfly
Aeolun