Retyc and AI: connecting your agent to your transfers and datarooms with MCP

Retyc has a simple policy: no artificial intelligence in the product. No analysis of your documents, no automatic summaries, no model trained on your files. That policy has not changed.

What does exist is something else: the ability for your AI agent, the one you chose and that runs where you decided, to drive Retyc on your behalf. Create a transfer, drop a folder into a dataroom, add a member, download files, in plain language. This article explains how it works, how to install it, and above all what it means for the confidentiality of your files.

What MCP is, in two sentences

MCP (Model Context Protocol) is an open standard that lets an AI assistant use external tools: read a code repository, query a database, send a message. An "MCP server" describes the available actions, and the assistant calls them when the conversation requires it.

Claude Desktop, Claude Code, Cursor and Windsurf can connect to MCP servers. Retyc provides one, built into the command-line client, published under the MIT license.

What it enables, concretely

Retyc's MCP server exposes the service's operations as tools that the agent chains on its own. A few requests that work as they are:

• "Send every PDF in ./reports to bob@example.com, expiring in 7 days."
• "Create a dataroom called “Release v2”, upload the contents of ./dist and add alice@example.com as an editor."
• "List my latest transfers and download the most recent one into ./received."
• "Who has access to the “Audit 2026” dataroom, and since when?"

Installation in three steps

1. Install the client and sign in. The binary can be downloaded from the GitHub releases. Signing in opens the browser, no password is stored on the machine.

retyc auth login

2. Declare the server in your assistant. For Claude Desktop, Cursor or Windsurf, add an entry to the client's MCP configuration file:

{
  "mcpServers": {
    "retyc": {
      "command": "retyc",
      "args": [
        "mcp",
        "serve"
      ],
      "env": {
        "RETYC_KEY_PASSPHRASE": "your key passphrase"
      }
    }
  }
}

For Claude Code, a single command is enough, and the passphrase is typed without appearing in the terminal history:

read -rs RETYC_KEY_PASSPHRASE
claude mcp add --transport stdio retyc --env RETYC_KEY_PASSPHRASE="$RETYC_KEY_PASSPHRASE" -- /path/to/retyc mcp serve

Claude Desktop also accepts a .mcpb bundle that installs in one click.

3. Ask. The server starts on the assistant's request, on your machine, with your credentials. The first request can be "check that I am signed in to Retyc".

What the agent sees, and what it does not see

This is the point that matters. The MCP server is the Retyc client itself: encryption and decryption happen inside that program, on your machine, before any network call. Nothing changes compared to sending from the browser.

Two clarifications. Your key's passphrase is handed to the process through an environment variable: it is never returned to the assistant. And downloads write decrypted files to your disk, in the folder you specify: they become ordinary files on your machine again.

The benefits

End-to-end encryption is preserved. Automating with an agent does not change the security model: Retyc still cannot read your files, and neither can the agent.

Nothing is delegated to a third-party service on Retyc's side. The MCP server is local. Retyc hosts no agent, sees none of your conversations, and adds no AI to the product.

Repetitive tasks disappear. Creating one dataroom per client, uploading a folder tree, inviting the right people with the right roles: what took ten clicks becomes one sentence, and the agent chains the calls without picking the wrong folder.

The same tool works for scripts. The binary that exposes the MCP server is the one used on the command line and in continuous integration. What works in a conversation works in a pipeline.

The code can be audited. The client is public, under the MIT license. You can read exactly what each tool does before plugging it in.

The limits, stated frankly

1. Metadata goes to your model's provider. If your assistant relies on a hosted model (Anthropic, OpenAI, Google or another), everything the tools return is sent to it: transfer titles, file names, member addresses, accompanying messages. The content of the files does not leave, but that information can already be sensitive. A locally run model removes this point; a hosted model means accepting its terms.

2. Once downloaded, files are in plaintext on your machine. If your agent also has access to the file system, it can read what it has just downloaded. Retyc is not what allows that, your configuration is. The two tools are independent, but they live on the same machine.

3. The agent acts with your rights, in your name. Anything you can do, it can do: send a file to any address, delete a folder, remove a member. The access log will record your name, not its own.

4. Confirmations depend on the client, not on Retyc. Destructive tools (dataroom_rm, dataroom_user_rm) are flagged as such according to the MCP standard. But each assistant handles that as it sees fit: Claude Desktop tends to refuse without context, Claude Code applies its own permission system, Cursor shows its own confirmations, and Windsurf has been observed ignoring these flags and executing without asking. Test your client's behaviour before entrusting it with a dataroom that matters.

5. An agent that reads text can be manipulated by that text. This is a limit of every agent, not of Retyc. A file name or an accompanying message written by a third party is an input for the model. An agent that is allowed to send files and that reads uncontrolled content deserves to be watched.

6. The passphrase lives in a configuration file. In the JSON file of Claude Desktop or Cursor, it is written in plaintext. This amounts to treating your machine as a trusted space, which is already the case for the key itself, but is worth knowing. Claude Code's read -rs method at least keeps it out of the terminal history.

7. Every encrypted operation unlocks your key. Unlocking uses about 256 MB of memory for a short moment. On Linux, the unlocked key is kept for a few dozen seconds in the kernel keyring, never on disk; elsewhere, the cost is paid on every call.

Good practices

1. A dedicated account for the agent whenever possible, with minimal rights, rather than your main account.
2. No file system access outside a working folder if the agent downloads confidential documents.
3. A local model for datarooms whose file names alone are already confidential.
4. A review before any send or delete, whatever the client, until you have checked its behaviour on destructive tools.
5. A passphrase typed rather than written in a file, whenever your client allows it.

In short

Retyc remains AI-free: the product does not read your files and will not be able to tomorrow either. The MCP server changes nothing about that rule. It simply moves automation to where it can happen without breaking encryption: on your machine, with your credentials and your agent. The limits all stem from that same reality: the agent is on your side, it acts in your name, and what you let it read or do is a matter of your configuration, not ours.

Sources:

• Retyc client and MCP server (source code, MIT license): https://github.com/retyc/retyc-cli
• MCP server documentation (tools, configuration): https://github.com/retyc/retyc-cli/blob/main/doc/mcp.md
• Model Context Protocol specification: https://modelcontextprotocol.io/
• Retyc's zero-AI policy, white paper, section 8.3: /resources/white-paper