Encryptor MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vaultsA | List the vaults this app may use: whether each is open or locked, read only or not, and when an open one locks by itself. Call it first, to learn the vault names the other tools take. Changes nothing: use unlock to open a locked vault and lock to close one. |
| unlockA | Ask the user to open a locked vault. The user types the password on their own computer (a local page or a password box), never in this chat, and chooses how long it stays open. purpose: a few words on why, shown to the user. Never ask the user for the password yourself. |
| lockA | Lock one vault now, or every open vault this app can see when vault is left empty: its keys are wiped from memory and a Finder mount of it closes. Use it when the task is done (vaults also lock by themselves after some minutes without use); unlock asks the user to open it again. No file is changed, and locking a locked vault is harmless. Returns which vault was locked, or that it was already locked. |
| control_centerA | Open the Encryptor MCP control center for the user: all their vaults (unlock, lock), what changed (undo), the trash, and settings (which vaults, what the AI may do, auto-lock). On this computer it opens in the user's own browser; the link is never shown here. |
| list_folderA | List what's directly inside one folder of an open vault: one line per item, marked [folder], [file] (with its size) or [link] (with its target), or "(empty)". Use find instead when you don't know which folder holds something, and file_info for one item's details. Changes nothing. Fails if the vault is locked (call unlock) or the path isn't a folder. |
| read_fileA | Read the text of one file in an open vault. Returns the text, starting with a version line to pass to write_file if you replace the file (left out when the vault is read only), and ending with the offset for the next part when more is left; max_chars is capped at 200,000. Pictures and other binary files only get a note with their size. Changes nothing in the vault; the read and its purpose go in the user's private read log. Fails if the vault is locked (call unlock) or the path doesn't exist; use find or list_folder to find paths. |
| file_infoA | Show the details of one file or folder in an open vault: kind, size, last change, where it's stored encrypted, and for a file the version that write_file needs to replace it. Use read_file for the contents. Changes nothing. |
| findA | Search an open vault for files and folders whose name contains some text (any case) and list their paths. Use it when you don't know where something is; use list_folder to see one folder. It matches names only, not what's inside files. Changes nothing. |
| health_checkA | Check an open vault for damage: broken folders, long names or files (the same kinds of problems Cryptomator's own health check reports), files cut short or swapped, and sync conflict copies. Returns one line per problem (how serious, where, what, and whether a safe repair exists), or that the vault is healthy. It changes no file in the vault: the first run only records file fingerprints, kept encrypted outside the vault, so later runs can catch cut or swapped files. Repairs are made by the user on the vault's page (call control_center). |
| locateA | Where a file or folder of an open vault is stored encrypted on disk (relative to the vault's folder): handy for sync conflicts or backups. |
| decrypt_nameA | Turn an encrypted path from a vault's folder (like d/AB/CDEF.../name.c9r, as a sync app or file browser shows it) back into the real path of that file or folder. The vault must be open. Use it to see which file a sync conflict or a backup entry is; locate does the opposite. Changes nothing. |
| write_fileA | Create a new text file, or replace a whole existing one, in an open vault that may be changed. To replace, pass the version read_file or file_info gave you: without it, or if the file changed since, nothing is written. To add to the end of a file use append_file; the parent folder must exist (make_folder). The old contents are kept, the change is logged, and undo or restore_version can take it back. Returns the new version and the change id; if the user asked to approve replacements, it may instead return a question for them. |
| append_fileA | Add text to the end of an existing text file in an open vault that may be changed, exactly as given (start it with a line break to begin a new line). Unlike write_file it needs no version and keeps what's there; to create a file, use write_file. The previous contents are kept as a version and the change is logged, so undo can take it back while the file is unchanged since. Returns the file's new version and the change id; fails if the file doesn't exist or the text is over 5,000,000 characters. |
| make_folderA | Create one new, empty folder in an open vault that may be changed. Its parent folder must already exist (create each level in turn), and nothing may have that name yet. Use move to rename a folder. The change is logged; undo removes the folder again while it's still empty. Returns the folder's path and the change id. |
| moveA | Move or rename a file or folder (with everything in it) inside one open vault that may be changed. Nothing is overwritten: the new path must be free and its parent folder must exist. Use copy_file to keep the original, or trash to remove something. The change is logged and undo moves it back. Returns the old and new paths and the change id; if the user asked to approve moves, it may instead return a question for them. |
| copy_fileA | Copy one file to a new path in the same open vault, which must be one that may be changed. It's copied encrypted, never decrypted. Files only, not folders; the new path must be free and its folder must exist, so nothing is overwritten. Use move to rename instead. The change is logged; undo puts the copy in the trash while it's unchanged. Returns both paths and the change id. |
| trashA | Put a file or folder (with everything in it) in the vault's own trash, the way to remove things here. It stays encrypted in the vault, the change is logged, and undo takes it back out; trash_list shows what's there. Deleting for good happens only with empty_trash, which the user approves. Returns the path and the change id; if the user asked to approve this, it may instead return a question for them. |
| trash_listA | List what's in an open vault's trash: each item's id, original path and when it was put there. Use it to find an item to bring back with undo, or to delete for good with empty_trash. Changes nothing. |
| empty_trashA | Delete for good from an open vault's trash: one item (its id from trash_list), or everything when item is empty. This is the only tool that deletes for good and it can't be undone; to remove something undoably use trash. The user approves it outside the chat (a box on their Mac or the app's own question), never with a code from you; if that can't be asked, or the user switched it off for AI apps, it sends them to the control center. Returns how many items were deleted, or that nothing was changed. |
| recent_changesA | List the latest changes made in an open vault, newest first: each change's id, when, what, which app, why, and whether it was undone. Use it to show the user what changed, or to find the id undo takes. Changes nothing. |
| undoA | Take back one change made in an open vault: the one with change_id (from recent_changes), or the latest one not yet undone. A new file or copy goes to the trash, a replaced or appended file gets its old contents back, a move is moved back, trashed items come back out, and an empty new folder is removed. It refuses when the file changed since (use versions and restore_version then), and an undo or empty_trash can't be undone. Returns what was done; the undo itself is logged too. |
| versionsA | List the earlier versions of one file that its changes kept, newest first, with the ids restore_version takes. Use it to pick which version to put back. Changes nothing. |
| restore_versionA | Put back an earlier version of a file, using its id from versions. The current contents are kept as a version too, so this can be undone. To take back a whole change (a move, a trash), use undo instead. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Each tool targets a distinct action or resource, and the descriptions explicitly cross-reference adjacent tools (find vs list_folder, undo vs restore_version, locate vs decrypt_name). Even where concepts are close, the boundaries are clear enough for an agent to choose correctly.
All names are snake_case, but the conventions are mixed: imperative verbs (lock, move, find, trash), noun phrases (vaults, versions, file_info, control_center), and verb_noun names (list_folder, read_file, restore_version). They remain readable, but the pattern is not predictable.
23 tools is above the typical well-scoped 3-15 range and feels heavy for a single server. The domain is complex—vault lifecycle, file operations, trash, versions, and security—so many tools earn their place, but the surface is still borderline large.
The tool set covers vault discovery/unlock/lock, file reading/writing/appending, folder and move/copy operations, trash lifecycle, undo, versions/restore, search/locate/decrypt, health checks, and change history. No obvious agent-facing lifecycle gap remains; vault creation and some user approvals are appropriately handled outside the chat.