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.

Files.com offers two ways to run the MCP Server. The Remote MCP Server is cloud-hosted by Files.com and requires no installation. Your AI client connects directly to our hosted endpoint. The Local MCP Server is a Python package you install and run on your own machine or infrastructure. The Remote MCP Server is the right starting point for most customers.

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.

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 is a Python package that you install and run on your own machine or infrastructure. Use this option when your organization requires that no outbound connection be made to a Files.com-hosted server, or when you need to run the server inside a private network.

Install the Local MCP Server from our GitHub repository or by using the pip Python package manager. 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.

Authentication

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 is the newer standard. Clients that support it use a metadata URL as their client identity and register automatically without any administrator configuration. Claude Code, Claude for desktop and mobile, and VS Code all use CIMD.

DCR lets clients register themselves at connection time. It is disabled by default because the MCP community is moving away from it due to security concerns. Cursor and Codex are the most common clients that do not yet support CIMD and require DCR to connect.

Site Administrators can enable DCR using the MCP Dynamic Client Registration setting. Enable it only for clients that require it. 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 user completes the OAuth flow and will see an error: Couldn't Complete OAuth Redirect — Your site does not allow this client to register for MCP access. Please contact your site administrator.

Interstitial OAuth Warning Page

For both DCR and CIMD, we present an interstitial warning page to the customer warning them that allowing access can be potentially dangerous if they did not request the access. The warning is strong and clear.

Both DCR and CIMD can be the targets of social engineering attacks. The technical bar is lower for performing attack using DCR and that is why we have made it an opt-in feature. For CIMD, the attacker must control a real domain and use that as part of the attack. We display this domain on the interstitial page alongside the redirectUrl. It is more obvious under CIMD when a social engineering attack is occuring and therefore CIMD is not gated like DCR.

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.

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.

The Local MCP Server is the right choice when your environment requires on-premises execution or restricts outbound connections to third-party-hosted services.

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.

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

When using the uv environment manager, use the command:

uv pip install --upgrade files-com-mcp

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