The Kiteworks MCP Server enables Large Language Model (LLM) applications to securely interact with your Kiteworks instance through the Model Context Protocol (MCP). This cross-platform server provides AI assistants with the ability to create Secure Data Forms, manage files, folders, and user information within your Kiteworks environment while maintaining enterprise-grade security.
End-User:
- File Management: Upload, download, retrieve metadata, rename, move, copy, and delete files (single or multiple)
- Folder Operations: Navigate hierarchies; create, rename, move, and delete folders (single or multiple)
- Search by Name or Content: Search for files and folders by name or content
- Request Files: Invite recipients by email to upload files into a Kiteworks folder
- Sharing & Permissions: List folder and file members, add, update, or remove them (with confirmation)
- Secure Email: List and read Kiteworks mail with mailbox counters, compose policy-validated drafts, and send them (with confirmation)
- Forms Creation: Generate Kiteworks Forms from templates with preview links
- User Information: Access current user details and authentication status
Admin:
- User Management: Search users, retrieve detailed user metadata, create users, update user information, and reset TOTP enrollment
- User Profiles: List, inspect, and create profiles, test mapping rules, and assign users individually or in bulk
- Shared Mailboxes: List, create, and delete shared mailboxes and manage their members
- Activity Logs: Query user and admin activity with date range, free-text search, and event filtering
- Risk Policies: Retrieve Kiteworks risk policies (read-only)
Security & Platform:
- OAuth 2.1 Security: Dynamic Client Registration, Authorization Code flow with PKCE, JWT access and refresh tokens with automatic refresh
- FIPS 140-3 Mode: AES-256-GCM encryption, RSA Signature with SHA-256, TLS 1.3 with NIST-approved curves
- Quantum-resistant forward secrecy: Hybrid X25519+ML-KEM-768 key exchange for TLS (FIPS 203)
- Rate Limiting: Configurable limits at global, per-user, and per-session levels
- Cross-Platform: Native binaries for Windows, Linux, and macOS, plus a Docker container image
- Local STDIO Server: Single-user deployment, able to upload / download files locally
- Remote HTTPS Server: Multi-user centralized HTTPS server with OAuth authentication, running as a Docker container or a systemd service
- Claude Desktop extension: Native extension package (.mcpb) for Claude Desktop
- Usage Examples - Check the detailed examples showing more complex operations, such as 'Compliance Review with Forms', 'Sensitive Data Audit', 'Collect and Download Deliverables for Review', 'Project Handover', etc.
- List of Available MCP Tools
This MCP server may handle sensitive data accessible to connected AI assistants. Only install trusted and verified MCP servers.
The Kiteworks MCP Server does not expose credentials or security tokens to the LLM context.
In Remote HTTPS mode, Kiteworks authentication tokens stay on the server, stored in an encrypted credential store, and never reach the agent's machine.
In Local STDIO mode, by default the Kiteworks authentication token is not persisted — it is held in memory only for the life of the server process. This keeps the token out of reach of the agent, so it cannot bypass the MCP Server to call Kiteworks APIs directly. The trade-off is that the server runs a quick OAuth flow each time it starts. For trusted environments and trusted agents, you can opt in to non-interactive restarts with kiteworks-mcp login --persist-token, which caches the rotating refresh token in your operating system's encrypted keychain so subsequent starts reuse it without a browser prompt.
In Local STDIO mode, the Kiteworks MCP Server does not make the data it transfers available to the LLM (in the LLM context).
Separate tools are available for loading small text files into the LLM context.
Local file access is limited to folders you approve. When installed via the .mcpb package, you pick that folder during installation ("Allowed Folder"). Claude may upload from and download to that folder and everything below it — using full paths, which is how it naturally refers to files — and nothing outside it is reachable. See Path Security for how this is enforced.
The Kiteworks MCP Server validates the TLS certificate of the remote Kiteworks server it connects to. It will abort if it can't be validated, to protect against man in the middle attacks. If your Kiteworks instance uses a self-signed certificate or a certificate from an unknown certificate authority, you can supply the Root CA chain using a command line option.
You can enable strict FIPS 140-3 mode by setting the GODEBUG=fips140=only env variable.
In this mode a protected cryptographic module with integrity self-check is loaded and only NIST-approved algorithms are used.
-
Deployment Guide covering:
- Enabling MCP in Kiteworks (needed for both Local STDIO and Remote HTTPS MCP Server deployments)
- Docker container deployment
- Deployment as Linux Systemd service
This mode is more powerful and unlocks capabilities, such as transferring files outside the LLM context.
The MCP protocol by nature is a "command channel". In STDIO mode, the Kiteworks MCP Server gives AI agents a "data channel" as well.
macOS Quick Start Guide - Complete setup walkthrough for macOS users, covering Claude Desktop and Claude Code with AWS Bedrock
- Download the .mcpb package
- In Claude Desktop, click on your User name at the bottom left and select Settings -> Extensions -> Advanced Settings
- Click Install Extension and browse for the .mcpb file and follow the instructions on the screen
- Enter your Kiteworks URL and accept the data terms
On first start, a browser window will open and you will be prompted to enter your Kiteworks credentials.
Due to Claude's active development, it may have bugs and require you to restart Claude Desktop.
# Windows
claude mcp add --transport stdio kiteworks C:\Path\To\kiteworks-mcp.exe start https://your.kiteworks.domain# Linux / macOS
claude mcp add --transport stdio kiteworks /path/to/kiteworks-mcp start https://your.kiteworks.domainStart Claude Code and type /mcp. Select kiteworks and authenticate in your Kiteworks instance.
Optional flags: you can add them after the "start" command
- Approve a folder for file transfers:
--allow-dir /path/to/folder(repeat for more; defaults to the working directory) - Enable move/delete tools:
--enable-destructive-tools(disabled by default) - If Kiteworks uses custom CA certificates:
--ca-cert /path/to/ca_chain.pem
claude mcp add --transport stdio kiteworks kiteworks-mcp start --allow-dir ~/Documents --enable-destructive-tools https://your.kiteworks.domainNote: If your MCP Server uses a self-signed certificate, then Claude Code will need to trust the issuing CA. Set this env variable before starting Claude Code:
- NODE_EXTRA_CA_CERTS=/path/to/ca_chain.pem
The issuing CA certificate must be in PEM format and contain the complete certificate chain.
Uploads and downloads are confined to an allowlist of approved directories. Everything below an approved directory is reachable; nothing outside one is, and there is no way to widen the list at runtime.
Approve directories with the repeatable --allow-dir flag of the "start" command:
kiteworks-mcp start --allow-dir /home/user/documents --allow-dir /home/user/Downloads https://your.kiteworks.domainAlternatively set KW_MCP_ALLOWED_DIRS to a list separated by the platform path separator (: on Linux and
macOS, ; on Windows), which is convenient for containers. The flag takes precedence over the environment
variable. If neither is given, the allowlist is the server's working directory — the directory the MCP client
launched it in — which is where relative paths have always resolved. The effective list is logged at startup
and named in the file tools' descriptions and error messages, so it is never invisible.
Inside an approved directory, all three path forms work, so the agent does not have to guess:
- Absolute:
/home/user/documents/report.pdf,C:\Users\me\Documents\report.pdf - Home-relative:
~/Documents/report.pdf - Relative to the first approved directory:
report.pdf
A directory that does not exist, is not a directory, or cannot be opened is a startup error rather than a silently dropped entry, so the running policy always matches the configured one.
Enforcement is handle-based, not textual. Each approved directory is held open as an operating system
directory handle, and every component of a requested path is resolved by the kernel against that handle.
Directory traversal (../), symlinks pointing out of an approved directory, and the check-then-open race are
therefore refused by construction rather than by string comparison. Windows-specific path forms are also
rejected: UNC and device-namespace prefixes (\\?\, \\.\), drive-relative paths (C:file), alternate data
streams (file.txt:stream), and reserved device names.
Two residual risks are worth knowing about. A hardlink created inside an approved directory that points at a file outside it is indistinguishable from an ordinary file at the path level, so no path check can catch it. And the allowlist governs this server only — anything else running as the same user is unaffected. For high-security deployments, run the server inside an OS-level sandbox (a container with only the approved directories mounted, macOS Seatbelt, or bubblewrap) as an outer layer, as the MCP security guidance recommends.
See: VS Code MCP Servers Guide
Configuration example:
{
"mcpServers": {
"kiteworks": {
"command": "/path/to/kiteworks-mcp",
"args": [
"start",
"--allow-dir",
"/path/to/allowed/folder",
"--enable-destructive-tools",
"--ca-cert",
"/path/to/ca_chain.pem",
"https://your.kiteworks.domain:8443"
]
}
}
}Many MCP Clients only support connecting to remote HTTPS MCP servers. The initial setup is easier as you don't need to install anything, but also the capabilities are limited. Remote MCP Servers do not have access to your file system and can't upload or download files.
The main settings needed by MCP clients are the URL of the MCP server and information on how to authenticate.
- MCP Server URL: https://mcp-server.example.com:8443/mcp (adjust host and port as needed.)
- Authentication: OAuth with DCR (Dynamic Client Registration)
When using it for the first time, your MCP Client will launch a browser and prompt you to authenticate in Kiteworks.
# adjust host and port as needed
claude mcp add --transport http kiteworks https://mcp-server.example.com:8443/mcp- Dev Guide - How to build from source and run a test MCP Server locally.
The MCP Server collects and stores:
- User consent for AI access to Kiteworks data
- OAuth authentication tokens (securely stored in encrypted credentials store)
The server does NOT:
- Share data with third parties
- Store file contents
- Transmit data outside of your LLM interactions
For complete privacy information about how Kiteworks handles your data, see our privacy policy: https://www.kiteworks.com/privacy-policy