The Files.com Model Context Protocol (MCP) Server lets your AI application interact with your Files.com site. The AI agent works against your site as if it were an extension of your team, with the same security, auditability, and access controls that apply to any other API client.

Your AI can use the MCP Server to upload and download files, query folders, manage users, and run other site operations.

The Remote MCP Server is hosted by Files.com and is the best choice for most customers. Use it to connect over a network. The Local MCP Server is a Python package for local use only, on the same machine as your AI client.

Model Context Protocol

Model Context Protocol (MCP) is an open protocol that standardizes how applications provide context to Artificial Intelligence (AI) Large Language Models (LLMs). MCP provides a standardized way to connect AI models to different data sources and tools.

MCP Servers are lightweight programs that expose specific capabilities through the standardized Model Context Protocol.

Remote vs. Local MCP Server

The Remote MCP Server is the best choice for most customers. Files.com operates the server, so you don't install anything and the server stays up to date on its own.

Choose the Local MCP Server when your AI client launches the MCP process on the same machine. It requires network access to the Files.com API and does not work offline.

Both versions expose the same available MCP tools. The Remote MCP Server supports Sign In with Files.com and API Key authentication. The Local MCP Server uses API Key authentication only.

Authentication

Before authorizing a client, review MCP to choose appropriate permissions and understand how to end its access.

The Remote MCP Server supports browser-based sign-in using OAuth 2.0. Your AI client discovers the sign-in flow automatically through standard OAuth metadata endpoints and opens a browser to authenticate against your Files.com site. On first connection, you log in and grant access. The client receives a bearer token representing your Files.com session. No API key is required.

If your Files.com site uses single sign-on (SSO), the sign-in flow redirects to your identity provider as normal. SSO authentication works transparently with the OAuth flow.

Dynamic Client Registration(DCR) and Client ID Metadata Documents (CIMD)

Files.com supports two OAuth client registration methods for the Remote MCP Server: CIMD (Client ID Metadata Documents) and DCR (Dynamic Client Registration).

CIMD lets a client use an HTTPS metadata URL as its identity. Files.com reads the client details from that address, giving the application a consistent identity and a domain you can inspect during sign-in. Clients that support CIMD connect without enabling DCR or manually registering the application.

DCR lets a client submit its name and redirect addresses to obtain a client ID at connection time. The client supplies those details itself; registration does not verify that it is published by the company named in its display name. DCR is disabled by default. Leaving it disabled when your clients support CIMD keeps sign-in tied to the metadata URL approach without enabling an additional registration method. The MCP authorization specification retains DCR for compatibility with earlier clients.

Neither registration method grants access to your site on its own or establishes that you should trust an application. You still sign in and approve access, and the client operates with the permissions of the account you authenticated. Check that you initiated the connection and recognize the client and redirect address before approving it.

Site Administrators can enable DCR using the MCP Dynamic Client Registration setting. Check your client's documentation and enable it only if the client requires DCR. If a client connects successfully without DCR enabled, leave the setting off.

When DCR is disabled and a client that does not support CIMD attempts to connect, the sign-in fails with the Couldn't Complete OAuth Redirect error.

Interstitial OAuth Warning Page

Before granting access, the sign-in flow displays a warning page. Confirm that the requesting client and redirect address match the connection you intended to configure.

For CIMD, the page displays the client's metadata domain alongside its redirect destination. A recognizable domain helps you identify the client, but does not replace checking that you initiated the request.

API Key

Both the Remote and Local MCP Servers accept a Files.com API Key for authentication. Pass the key as the value of the X-FilesAPI-Key HTTP header (Remote MCP Server) or the FILES_COM_API_KEY environment variable (Local MCP Server).

For details on what actions each authentication method permits, see MCP Access Permissions.

Getting Started with the Remote MCP Server

The Remote MCP Server is the fastest way to connect your AI client to Files.com. Files.com hosts and operates the server, so there is nothing to install or maintain. You can connect to multiple Files.com sites at once by adding an entry for each site in your configuration.

To connect, configure your AI client to use the Files.com MCP endpoint at https://<mysite>.files.com/api/ai/mcp/v1/ or https://<mycustomdomain>/api/ai/mcp/v1/.

The Remote MCP Server supports two authentication methods. Most clients can use Sign In with Files.com: your AI client discovers the sign-in flow automatically and opens a browser to authenticate with your Files.com account. No API key setup is required. Clients that cannot open a browser, or that need a fixed credential for automated workflows, can authenticate with a Files.com API Key passed as the X-FilesAPI-Key HTTP header.

Sign In with Files.com works with any MCP-compliant client that supports OAuth, including Claude Code, Claude for mobile, and web-based AI assistants. This is the easiest method for most users and the only method that works with mobile clients such as the Claude app for iOS and Android.

For Claude for web and Claude for mobile, use the application's settings to add the Files.com MCP endpoint as a custom connector. Claude will open a browser to complete sign-in the first time you connect. For step-by-step Claude Desktop instructions, see the Quickstart for Claude Desktop. For other AI clients, refer to your client's documentation for configuring a remote MCP server.

Getting Started with the Local MCP Server

The Local MCP Server communicates with your AI client on the same machine through standard input and output (STDIO). The local process connects to the Files.com API to perform site operations. It does not support SSE or accept network connections from AI clients. Use the Remote MCP Server for those connections.

Install the Local MCP Server from our GitHub repository or by using the pip Python package manager. It is also listed on the Official MCP Registry, Glama, PulseMCP, MCP.so, and MCP Market. Then configure your AI client to use it.

Refer to the documentation for your AI application to configure it to use the Files.com MCP Server.

For customers using Claude Desktop, we provide some quickstart instructions to help you get up and running quickly.

Local Directory Restriction

The Local MCP Server can upload files from your computer and save downloads there. If the AI's work belongs in one local folder, set FILES_COM_LOCAL_ROOT to limit these transfers to that folder and its subfolders. This keeps unrelated local files outside the transfer tools' access, even when the operating-system account running the server can access them.

Set FILES_COM_LOCAL_ROOT in the environment your MCP client passes to the server, alongside FILES_COM_API_KEY. Its value must be an absolute path to an existing local directory. Restart the client after changing the setting so it launches the server with the new value. The Claude Desktop configuration example includes this option.

Uploads read from within the configured directory, and downloads write within it. A download can create a new file, but its destination directory must already exist. The server resolves .. and symbolic links before checking that a transfer path stays inside the allowed directory. Relative transfer paths start from the server's working directory, not from FILES_COM_LOCAL_ROOT; use absolute transfer paths to make the intended location clear.

The setting is optional. An omitted or empty value allows transfers to use any local path the server's operating-system account can access. An invalid nonempty value prevents the server from starting. This local restriction is separate from API key permissions, which control access to your Files.com site. The Security Reference explains how the local and site controls work together.

Available MCP Tools

Within an MCP server, a "tool" represents a capability or function that the AI can interact with.

Our MCP server has a limited set of available MCP tools today. More tools will be added over time.

Updating the Local MCP Server

The local MCP Server can be updated to the latest version via the pip Python package manager by using the command:

pip install --upgrade files-com-mcp

For a package installed into a uv virtual environment, use uv pip install --upgrade files-com-mcp. When the client launches the server with uvx, run uvx --upgrade files-com-mcp to refresh its cached package, then restart the client.

Removing the Local MCP Server

The local MCP Server can be uninstalled via the pip Python package manager by using the command:

pip uninstall files-com-mcp

When using the uv environment manager, use the command:

uv pip uninstall files-com-mcp