# UNDISK MCP

> Undo-first versioned file workspace for AI agents

## What is Undisk?
Undisk MCP is a remote, versioned file workspace exposed over the Model Context Protocol (MCP).
Every file write creates an immutable version. Any single write can be surgically undone in under 50ms.

## Key features
- 20 MCP tools: file CRUD, staged uploads, versioning, cross-file change queries, diff, search, policy admin, workspace secrets, public sharing
- Sub-50ms restores without affecting other files
- Policy engine with path ACLs, size limits, extension rules, secret scanning
- Content moderation via Workers AI (async scan, flagged content marked not blocked)
- Audit trail with SHA-256 content hashes for every mutation
- SSO (OIDC + SAML 2.0) for Team and Enterprise plans
- Organization management with role-based access control
- Works with Claude, Cursor, GitHub Copilot, Windsurf, VS Code, Claude Code

## Links
- Docs: https://mcp.undisk.app/docs
- Full docs (markdown): https://mcp.undisk.app/llms-full.txt
- ForgeTrace: https://mcp.undisk.app/forgetrace
- Use cases: https://mcp.undisk.app/use-cases
- Sign up: https://mcp.undisk.app/signup
- MCP endpoint: https://mcp.undisk.app/mcp
- Blog: https://undisk.app/blog
- GitHub: https://github.com/kiarashplusplus

## Pricing
- Free: 1 workspace, 100 MB, 1,000 ops/day
- Pro ($29/mo): 5 workspaces, 10 GB, 50,000 ops/day
- Team ($99/mo): 25 workspaces, 100 GB, 500,000 ops/day

---

# Agent Operating Procedures
You are connected to an UNDISK remote file workspace via the Model Context Protocol (MCP). This is an immutable, undo-first file system. Your file operations are automatically versioned and strictly audited.

You must adhere strictly to the following operational rules:

## 1. The "Undo" Imperative
Never attempt to manually rewrite or guess previous file content from memory if you make a mistake, introduce a bug, or overwrite the wrong file.
- **Action:** Call `list_versions` on the target path to locate the pre-error state.
- **Action:** Call `restore_version` with that version ID.
- *Note: Deletes are soft-deletes (tombstones). If you delete the wrong file, simply restore it.*

## 2. Intent-Based Writing
Select your write tools based strictly on your intent to prevent accidental data loss:
- Use `create_file` when initializing a new asset to guarantee you do not overwrite existing work.
- Use `write_file` only for deliberate upserts or complete file rewrites.
- Use `append_log` for running notes, shared logs, or session records (never overwrite logs).

## 3. Large File Handling
The standard `write_file` tool has payload limits. If you need to generate or write a file larger than a few megabytes (or if you receive a size error):
- Do NOT attempt to split it manually using standard writes.
- **Action:** Execute the staged upload pipeline: `upload_session` with action "start" → action "append" (keep chunks <1MB) → action "complete".

## 4. Rate Limit Compliance
If you receive a `RATE_LIMITED` error from any tool:
- You MUST halt execution and wait the exact `retry_after_seconds` specified in the error message before making another call to this server. Do not instantly retry.

## 5. Policy Denials
If an action is blocked with a `PERMISSION_DENIED` error, do not attempt to bypass it by moving the file or using a different tool. Read the returned policy reason, explain the blockage to the user, and ask for permission or a policy change via `policy` with action "write" and mode "merge" (if authorized).

## 6. Secret Storage
Never store API keys, tokens, PEM files, or other secrets using `write_file`. Use `vault_secret` instead.
- **Action:** Call `vault_secret({ action: "put", name: "...", value: "..." })` to store.
- **Action:** Call `vault_secret({ action: "get", name: "...", reveal: true, purpose: "..." })` to retrieve.
- Secrets are encrypted at rest, never appear in file listings or search results, and plaintext is never written to audit logs.