Kiteworks MCP Server Installation & Setup

The setup path depends on your deployment mode and the MCP client you're connecting to. This page covers the one-time Admin Portal enablement and the API scopes it grants, the Claude Desktop Connector, Local STDIO setup for individual users, and Remote HTTPS deployment for administrators setting up a shared server.

Join the Innovators in AI program — Full MCP access included for all members

Unlimited agent workflows, policy controls, and audit telemetry at no additional cost for the first 6 months. Kiteworks admins can activate it through the admin console.

Learn more

Configure MCP in Admin Portal

Start here. Kiteworks MCP is governed by a single fixed OAuth application managed from the Admin Portal console. Enabling it is the one required step before anyone can connect. Once it is on, users can start using the Claude Desktop Connector or any other local MCP installation.

Enable Kiteworks MCP

1. Log into the Kiteworks Admin Portal console

   Sign in as an administrator.
2. Open the Kiteworks MCP settings

   Go to Application Setup → Apps and Plugins and select the Kiteworks MCP tab.
3. Enable Kiteworks MCP

   Toggle Kiteworks MCP to enabled and click Save. That's it — users can now start using the Claude Desktop Connector or other local MCP installations.

Optional configuration

The defaults work for most local deployments. Adjust these only if your environment requires it:

• Disable local MCP — turn off the local redirect if you want users to connect only through an MCP server deployed on a remote server.
• Add the remote callback URL — if you run a remote MCP server, add its callback (redirect) URL so the fixed app can complete the OAuth flow for remote clients.
• Configure scopes — adjust the OAuth scopes granted to the fixed app to widen or narrow what connected AI clients can do. The API scopes section below lists every operation the MCP Server uses, in the order the panel shows them, and marks which ones a fresh instance does not grant yet.

API scopes

API scopes set the maximum that can ever be performed through the MCP Server. They are a ceiling, not a grant: nobody working through an AI client can do more than their own Kiteworks permissions already allow.

These are the scopes to set. Enable every operation marked ● in the table below. The greyed-out operations exist in the panel but no MCP tool uses them, so leave them off.

Claude Desktop Connector

The quickest way to connect Kiteworks to Claude Desktop. The Kiteworks MCP Server is now available directly in the Claude Desktop connector marketplace — you no longer need to download a binary and upload it manually. The full install, permissions, and configuration walkthrough lives on its own page.

If your organization has not enabled the connector marketplace, the same integration ships as a .mcpb native package you can install by hand: download it from the GitHub releases ↗, then in Claude Desktop go to your user name → Settings → Extensions → Advanced Settings, click Install Extension, select the file, and supply your Kiteworks URL and acceptance of the data terms. A browser window opens for credentials on first run, and Claude Desktop may need a restart.

Download the Binary

For Local STDIO deployments (Claude Code and VS Code), native binaries for Windows, Linux, and macOS are available from the Kiteworks MCP GitHub repository. Always download the latest release to ensure you have current security patches.

Local STDIO — Claude Code & VS Code

The Local STDIO binary runs on your machine and gives AI agents a direct data channel for uploading and downloading files — capabilities not available in Remote HTTPS mode. Install it once and register it with your MCP client.

Claude Code

Register the binary as an MCP server using the claude mcp add command. Replace /path/to/kiteworks-mcp with the actual path to the downloaded binary and https://your.kiteworks.domain with your instance URL.

claude mcp add --transport stdio kiteworks \
  /path/to/kiteworks-mcp start https://your.kiteworks.domain

claude mcp add --transport stdio kiteworks ^
  C:\Path\To\kiteworks-mcp.exe start https://your.kiteworks.domain

Start Claude Code and type /mcp, then select kiteworks and authenticate in your browser when prompted.

Optional flags

Append these after the start command as needed:

Flags go between start and the instance URL. A typical setup that allows two directories and turns on move and delete:

claude mcp add --transport stdio kiteworks \
  /path/to/kiteworks-mcp start \
  --allow-dir ~/Documents \
  --allow-dir ~/Downloads \
  --enable-destructive-tools \
  https://your.kiteworks.domain

File access and path security

File transfers are confined to the directories you approve with --allow-dir. Inside an approved directory you can reference files three ways: by absolute path, by home-relative path (~/Documents/report.pdf), or relative to the first approved directory. Anything outside is refused.

Enforcement is handle-based rather than textual: the server holds each approved directory open as an operating-system directory handle and the kernel resolves every path component against it. That makes ../ traversal, symlinks pointing outward, and check-then-open race conditions fail structurally instead of relying on string inspection. On Windows the \\?\ and \\.\ prefixes, drive-relative paths, alternate data streams, and reserved device names are all rejected. If a directory you pass cannot be opened, the server aborts at startup rather than silently dropping it from the allowlist.

Environment variables

Staying signed in between restarts

In Local STDIO mode the access token is held in memory only, so the server runs a fresh OAuth flow every time it starts. On a machine you trust, the login subcommand caches the rotating refresh token in your operating system's encrypted keychain so restarts no longer prompt:

kiteworks-mcp login --persist-token https://your.kiteworks.domain

In-memory is the default deliberately: it means a stolen disk image carries no usable Kiteworks credential. Opt into persistence only on single-user, trusted machines.

Visual Studio Code

Add Kiteworks as an MCP server in your VS Code settings. See the VS Code MCP Servers Guide ↗ for full documentation. A minimal configuration looks like this:

{
  "mcpServers": {
    "kiteworks": {
      "command": "/path/to/kiteworks-mcp",
      "args": [
        "start",
        "--allow-dir", "/Users/you/Documents",
        "https://your.kiteworks.domain"
      ]
    }
  }
}

Each flag and its value are separate entries in the args array, and the instance URL always comes last. Add --enable-destructive-tools or --ca-cert plus its PEM path the same way, and repeat --allow-dir for each additional directory.

Remote HTTPS Server

The Remote HTTPS server runs as a centralized service that multiple users connect to via their MCP clients. Deployment is a multi-step process — creating the directory structure, generating cryptographic secrets, placing TLS certificates, writing the environment configuration, and setting up a reverse proxy. The full, up-to-date instructions live in the Kiteworks MCP GitHub repository.

Connecting a client to the remote server

Once the server is running, clients point at its /mcp endpoint and authenticate with OAuth 2.1 using Dynamic Client Registration — there is no client ID or secret to distribute. From Claude Code:

claude mcp add --transport http kiteworks https://mcp-server.example.com:8443/mcp

Any generic MCP client needs only those two settings: the server URL and OAuth with Dynamic Client Registration.

Security Notes

A few behaviors worth knowing before going to production:

• Credentials are never exposed to the LLM. Tokens never enter the AI context window. In Local STDIO mode the token is held in memory only and discarded on exit unless you opt in with login --persist-token, which caches the rotating refresh token in your OS keychain. In Remote HTTPS mode tokens stay server-side in an encrypted store.
• File data is not automatically shared with the LLM. In Local STDIO mode, binary files move over a separate data channel without entering the LLM context. Text files can be loaded into context explicitly.
• File access is confined to approved directories. Transfers are limited to the directories passed with --allow-dir (or listed in KW_MCP_ALLOWED_DIRS), enforced by the kernel against an open directory handle rather than by string checks.
• Destructive tools are off by default. Move and delete tools are not registered unless the server starts with --enable-destructive-tools, and deletions, member changes, and sending mail each require explicit confirmation on top of that.
• Scopes cap what any AI client can attempt. The fixed MCP application's scope grant is instance-wide — see API Scopes above. Within that ceiling, every call is still bounded by the signed-in user's own Kiteworks permissions.
• TLS certificate validation is enforced. The MCP Server validates the TLS certificate of your Kiteworks instance and will abort the connection if it cannot be verified, blocking man-in-the-middle attempts. Use --ca-cert to supply a custom CA chain for self-signed or private CA certificates.
• FIPS 140-3 mode can be enabled by setting GODEBUG=fips140=only as an environment variable before starting the server.

Next Steps

With the server installed and connected:

• Claude Desktop Connector → Install and use the Kiteworks connector in Claude Desktop
• Kiteworks Agent Marketplace ↗ — Ready-to-use, governed agents built on the MCP Server
• Available MCP Tools ↗ — Full list of tools exposed to connected LLM applications