MCP

Connecting an AI client through MCP lets that client request Files.com operations on your behalf, including reading or changing data within your permissions. Before approving a connection, choose an account or API key with the access the client needs and identify how you will end that access. Remote and Local MCP support different authentication methods and controls.

Credentials and Permissions

MCP does not add a separate AI permission model. Signing in as a Site Administrator gives the client administrator access, including changing users' passwords and email addresses and resetting their 2FA without another password or 2FA confirmation. Using a more restricted account limits the operations it can perform. Prompts and instructions to the AI do not replace Files.com permissions. The MCP Access Permissions page explains the permission checks for each method.

Remote MCP tool calls are exempt from re-authentication for every operation covered by that control. The exemption applies to all login sessions used through Remote MCP, whether obtained through Sign In with Files.com or created through the REST API. Choose the account's permissions for the changes you trust the client to make; another confirmation does not limit those tool calls. Session expiration and access removal govern how long session-based access continues.

A dedicated API key lets you restrict or revoke one client's access without interrupting other integrations. Site-wide keys belong to the site, so disabling the administrator who created one does not revoke it. User keys depend on their associated user remaining enabled. See API key scopes and expiration.

The Client's Instructions and Its Allowed Actions

An AI client's prompt describes intended work. The Files.com credential defines what it is allowed to do, including requests the client makes unexpectedly or incorrectly. If the job is limited to exchanging files in one folder, use a Files Only key with a path restriction and an appropriately limited user. A Full Access key's path restriction does not contain administrative work configured with that key.

Client approval also gives the external application an opportunity to receive data. Account permissions limit what Files.com will provide; they do not control how the client stores a result or passes it to its AI provider. Review that data-handling relationship separately from the Files.com permission check.

Client Registration and Approval

Sign In with Files.com supports Client ID Metadata Documents (CIMD) and Dynamic Client Registration (DCR). CIMD identifies a client by an HTTPS metadata URL. Files.com reads the application's name and redirect addresses from that document, giving you a domain to inspect during approval. DCR lets a client submit those details when it requests a client ID; the submitted name does not verify who publishes the application.

The MCP Dynamic Client Registration setting is off by default. Enable it only for clients that require DCR. Leaving it off avoids authorizing additional DCR clients when your clients support CIMD. It does not restrict CIMD clients or API-key connections, select an approved list of applications, or disconnect clients already authorized through DCR.

With DCR disabled, Files.com still returns a client ID for a valid registration request. This lets the client open browser sign-in and show why the connection cannot complete. After you log in, Files.com refuses to authorize that client and displays the Couldn't Complete OAuth Redirect error. A client ID issued while DCR is disabled can never complete sign-in or obtain a token, even if DCR is enabled later. When all AI features are disabled for the site, Files.com refuses the registration request itself.

Registration alone does not authorize access. The browser sign-in flow includes a warning page showing the application name, the Files.com MCP resource, the redirect destination, and, for CIMD, the client's metadata domain. These details help you check that the request belongs to the connection you initiated. The page warns that Files.com has not verified the application. A displayed name or recognizable domain does not establish that the client is suitable for your data or that its actions will match your intent. Decline a request you did not initiate or do not recognize.

Session Lifetime and Access Removal

A Sign In with Files.com session follows the site's Session Expiration setting and is also limited by the OAuth application's expiration. When the application has no expiration, the site's session expiration setting supplies the lifetime. Closing the client's window does not itself revoke the Files.com session.

The session becomes invalid when it times out, when the OAuth application expires or is revoked, or when all AI features are disabled for the site. Account changes that invalidate ordinary login sessions, including a Files.com password change or disabling the user, also invalidate this session. A refresh grant lets the client obtain a new session without repeating browser sign-in. Changing the Files.com password or disabling the user invalidates every refresh grant issued to that user before the change, so an earlier refresh token cannot restore access. Disabling the user also blocks the user's ability to authenticate again.

Files.com does not provide a control to revoke an individual OAuth grant or a list of OAuth grants in the Web App. The site's OAuth authorization-server metadata does not advertise a revocation endpoint. Account and site controls therefore have a broader effect than disconnecting one client. Use a dedicated API key when you need a credential you can revoke individually.

API-key connections follow the key's own expiration and revocation rules. Changing a password does not revoke an independently issued API key. Access Revocation explains these distinctions and the limits of ending access after a download has already been authorized.

Remote and Local Controls

Disabling all AI features for the site blocks the Remote MCP Server, including connections using an API key. It does not revoke that key or prevent its use through the ordinary Files.com API. The Local MCP Server connects through that API and is unaffected by the AI setting. To stop its Files.com access, revoke its API key or disable the associated user. The AI feature controls describe the site-wide setting.

Local Directory Restriction

The Local MCP Server runs on your computer or infrastructure. Its upload and download tools have two independent sets of controls: the API key's permissions determine which Files.com paths they can use, while operating-system permissions and the optional FILES_COM_LOCAL_ROOT setting determine which local paths they can use. A restricted API key does not by itself protect unrelated files on the computer.

Set FILES_COM_LOCAL_ROOT in the server's environment to an existing absolute directory path when the client's transfer work should stay in one local folder. The setting limits the local paths used for the client's upload and download requests to that directory and its subdirectories. The Local MCP configuration guidance explains where to set it.

For each request, the server resolves .. and symbolic links and rejects a path whose resolved location is outside the configured directory; a symbolic link that stays within it is allowed. Relative transfer paths are resolved from the server's working directory, not from the configured root. Downloads can create new files in existing directories inside the allowed area. An invalid nonempty root value prevents startup instead of allowing unrestricted transfers.

FILES_COM_LOCAL_ROOT does not separate operating-system accounts. Use operating-system permissions so that only the account running the server has write access to the configured directory and its subdirectories. Another account with write access inside the root can redirect transfers outside it through symbolic links it places there.

An omitted or empty value leaves local transfers unrestricted by this setting. Operating-system permissions still apply, so the server must have permission to read an upload source or write a download destination even inside the configured root. Choose a directory containing only files appropriate for this client's work and run the server under an operating-system account with suitable permissions.

The setting applies only to the Files.com Local MCP Server's upload and download tools. Other applications and other MCP servers on the computer retain their own local access. Configure both the local directory and the API key for the intended work; instructions in an AI conversation do not replace either control.

Audit Records and External AI Clients

MCP operations use the standard Files.com audit logs and are attributed to the acting account under the usual API logging rules. There is no separate AI audit trail for MCP actions. Review Logs and Reports for Files.com activity and the client's own records for its conversation history.

An external AI client can pass file contents and tool results to its model provider. Review that client's and provider's data-handling terms before giving it access. Files.com does not control third-party AI tools or models, their actions, or their handling of data, as explained in the AI Features terms. Ending Files.com access does not retrieve data already delivered to the client.