Python Mcp

Files.com MCP Server

The files-com-mcp Python package lets your AI application interact with Files.com. It is for local use only and supports STDIO only: your MCP client starts the package as a subprocess on the same machine.

For MCP connections over a network, use the Files.com hosted MCP service.

Set FILES_COM_API_KEY in the environment your client passes to the subprocess. The local package makes outbound requests to the Files.com API to perform site operations.

Files.com is the cloud-native, next-gen MFT, SFTP, and secure file-sharing platform that replaces brittle legacy servers with one always-on, secure fabric. Automate mission-critical file flows—across any cloud, protocol, or partner—while supporting human collaboration and eliminating manual work.

With universal SFTP, AS2, HTTPS, and 50+ native connectors backed by military-grade encryption, Files.com unifies governance, visibility, and compliance in a single pane of glass.

Introduction

The Files.com Python MCP package lets Claude Desktop and other local MCP clients upload and download files, query folders, manage users, and run automations on your Files.com site. It uses the permissions of your API key, and its actions are logged like those of any other API client.

The Python package supports local use over STDIO (standard input and output) only. Your MCP client starts it on the same machine and communicates directly with that process, without a network listener. The package still needs outbound access to the Files.com API.

What MCP Is

The Model Context Protocol (MCP) is a standard interface through which a Large Language Model calls real APIs as part of its work. An MCP server hands the model a set of tools, and each Files.com tool is an authenticated operation in your site. With the server connected, the model can:

• Transfer files between cloud and on-premises systems
• Query folders and file metadata
• Create and manage users
• Automate workflows such as archiving or sharing

Common Use Cases

Assistants for operations teams. An internal chatbot fetches or archives files on request.

Automated workflows. An agent reacts to an incoming support request, then retrieves or uploads the files the case needs.

Developer copilots. A development-focused LLM creates users, provisions folders, or reads files while debugging.

Local vs. Hosted MCP

Use the local Python package with clients that launch STDIO servers, including Claude Desktop.

For clients that connect to MCP over a network, use the Files.com hosted MCP service. Files.com operates the server, so you do not need to install the Python package. Running the Python package as an HTTP or SSE service is unsupported, including during development.

Install uv, register uvx --python ">=3.11" files-com-mcp as an MCP server in your LLM client, and give it a Files.com API key in the FILES_COM_API_KEY environment variable.

https://pypi.org/project/files-com-mcp/

Installation

The files-com-mcp Python package lets your MCP client call the Files.com API through a process running on your machine. It supports local use over STDIO (standard input and output) only. For clients that connect to MCP over a network, use the Files.com hosted MCP service.

Requirements

Your MCP client must be able to start a local STDIO server. Your machine needs outbound access to the Files.com API.

The examples run the server with uvx, which is part of uv. It runs a Python tool in an isolated environment of its own, so there is nothing to install or configure by hand beyond uv itself. Install uv first. You can also run the server in Docker.

Version 2 of the package needs Python 3.11 or newer; version 1 releases also support Python 3.10. The examples pass --python ">=3.11" so that uvx runs the server with Python 3.11 or newer. Without it, uvx uses whichever Python uv selects by default, which can be older.

Registering The Server

Set your client's local STDIO server command to uvx with --python, >=3.11 and files-com-mcp as its arguments, in that order. uvx downloads the package on first use and starts it each time your client launches the server.

The Claude Desktop configuration shows these settings in JSON. For other clients, follow their instructions for adding a local STDIO server.

Authentication

The server authenticates to Files.com with an API key, read from the FILES_COM_API_KEY environment variable that your client passes to it. Use a dedicated key with the permissions the agent needs. A user key follows its account's permissions, narrowed by the key's permission scope, Workspace, and any path restriction on file operations. API Keys explains how to choose that scope and manage the credential's lifecycle.

Restricting Local File Transfers

Optionally set FILES_COM_LOCAL_ROOT in your client's server environment to an existing absolute directory path, such as /home/user/Documents. This limits the local paths the upload and download tools accept for your client's requests to that directory and its subdirectories. When the variable is omitted or empty, transfers can use any local path accessible to the server.

The server resolves .. and symbolic links when checking each path and rejects paths that resolve outside the configured directory. Relative transfer paths are resolved from the server's working directory. A download can create a new file there if its parent directory exists. A nonempty value must name an existing absolute directory; otherwise, the server will not start.

This setting does not separate operating-system accounts; operating-system permissions do that. Give only the account running the server write access to the configured directory and its subdirectories. Another account with write access there can redirect transfers outside the directory by placing or changing symbolic links, even after a path has been checked.

This setting applies to local transfer paths. Files.com paths continue to follow the API key's permissions.

uvx --python ">=3.11" files-com-mcp

FILES_COM_API_KEY=your-api-key uvx --python ">=3.11" files-com-mcp

FILES_COM_API_KEY=your-api-key FILES_COM_LOCAL_ROOT=/home/user/Documents uvx --python ">=3.11" files-com-mcp

Using With Claude

Claude Desktop uses the Files.com Python MCP package to call the Files.com API from your machine. This setup supports local use over STDIO (standard input and output) only. For a network connection to MCP, use the Files.com hosted MCP service.

Claude Desktop reads its MCP servers from claude_desktop_config.json. Add the entry on the right under mcpServers, replace the FILES_COM_API_KEY value with a Files.com API key, and restart Claude Desktop. The MCP quickstart shows where the file lives on each operating system, walking through the same steps for another server.

The entry starts the server with uvx, so uv has to be installed first; see Installation. Its --python and >=3.11 arguments have uvx run the server with Python 3.11 or newer, which version 2 of the package needs.

Once Claude has restarted, the Files.com tools appear in its tool list. Tools lists them by category and explains why it pays to enable only the ones a task needs.

To restrict local uploads and downloads, optionally add "FILES_COM_LOCAL_ROOT": "/home/user/Documents" alongside FILES_COM_API_KEY in the env object, using an existing absolute directory on your machine. Restart Claude Desktop after changing it. See Restricting Local File Transfers for details.

{  "mcpServers": {    "Files.com": {      "type": "stdio",      "command": "uvx",      "args": [        "--python",        ">=3.11",        "files-com-mcp"      ],      "env": {        "FILES_COM_API_KEY": "your-api-key"      }    }  }}

Running In Docker

The files-mcp repository includes a Dockerfile that packages the MCP server with Python 3.11 and every dependency it needs, so the machine running your MCP client needs Docker but not Python or uv.

The container is still a local STDIO server. Your MCP client starts it with docker run and sends and receives protocol messages over standard input and output. The container stops when the client closes standard input. It does not listen on a port or start an HTTP server. For clients that connect to MCP over a network, use the Files.com hosted MCP service.

Building The Image

Build the image once, and again when you want a newer release. By default, Docker builds the image for the builder's native architecture. Add #v and a release number to the repository address to build a specific release.

The image contains the package from the repository you build and the latest release of the files-com Python SDK that it depends on. To install a specific SDK release instead, add --build-arg FILES_COM_SDK_VERSION= and the version number.

Registering The Server

Set your client's local STDIO server command to docker with the arguments in the example, and put your API key in the server's environment as FILES_COM_API_KEY. Replace 501:20 with your own user and group IDs from id -u and id -g, and replace /Users/you with your home folder.

• -i keeps the container's standard input open for the protocol. Do not add -t. A terminal combines the output streams and breaks the protocol.
• --rm removes the container when the session ends. --init runs a small init process as the container's first process, which forwards stop signals to the server and reaps child processes.
• --user runs the server with your user and group IDs, so it can write to the downloads folder you create and the files it downloads belong to you.
• -e FILES_COM_API_KEY, without a value, copies the key from the environment your client passes, so the key does not appear in the command line.

The server writes its logs to standard error.

Uploads And Downloads

Mount host folders to make their files available inside the container. The image sets FILES_COM_LOCAL_ROOT=/work to restrict local uploads and downloads to /work. Create both host folders before starting the server, and make the downloads folder writable by the container's user. Mount the folder containing upload files at /work/uploads with read-only access and the downloads folder at /work/downloads with write access. Use their absolute host paths in the client configuration.

Docker may create missing host folders with permissions that prevent downloads. Create the folders with mkdir -p first, as shown in the example, and make sure the container's user can write to the downloads folder.

Transfer tools take paths inside the container, not paths on your machine. When you ask the model to transfer a file, give a container path under /work/uploads or /work/downloads, such as /work/downloads/report.pdf. The absolute host paths belong only in the -v mount arguments.

docker build -t files-com-mcp https://github.com/Files-com/files-mcp.git

mkdir -p "$HOME/Files.com/uploads" "$HOME/Files.com/downloads"

{  "mcpServers": {    "Files.com": {      "type": "stdio",      "command": "docker",      "args": [        "run", "-i", "--rm", "--init",        "--user", "501:20",        "-e", "FILES_COM_API_KEY",        "-v", "/Users/you/Files.com/uploads:/work/uploads:ro",        "-v", "/Users/you/Files.com/downloads:/work/downloads",        "files-com-mcp"      ],      "env": {        "FILES_COM_API_KEY": "your-api-key"      }    }  }}

FILES_COM_API_KEY=your-api-key docker run -i --rm --init \  --user "$(id -u):$(id -g)" \  -e FILES_COM_API_KEY \  -v "$HOME/Files.com/uploads:/work/uploads:ro" \  -v "$HOME/Files.com/downloads:/work/downloads" \  files-com-mcp

Tools

The Files.com MCP server exposes the tools below, grouped by category: files, folders, sharing, users, logs, automations and the other Files.com resources. Each tool is one operation in your site, run with the permissions of the API key the server holds.

Keep The Toolset Focused

A model picks the right tool more reliably from a short list. If the LLM uses Files.com tools inconsistently, it is most likely choosing among too many. Most clients let you enable and disable an MCP server's tools one by one; enable only the ones the agent's task needs.

Automations

File System

Integrations

Logging

Sharing / Share Links

User Accounts

Authentication

The Files.com MCP uses API key authentication.

Authenticate with an API Key

Authenticating with an API key is the recommended authentication method for most scenarios, and is the method used in the examples on this site.

To use an API Key, first generate an API key from the web interface or via the API or an SDK.

A user key follows its account's permissions, narrowed by the key's permission scope, Workspace, and any path restriction on file operations. It can perform administrative operations only when both the account and key permit them. API Keys explains credential scope and lifecycle; Workspaces explains request context and delegated administration.

Don't forget to replace the placeholder, YOUR_API_KEY, with your actual API key.

Sort and Filter

Several of the Files.com API resources have list operations that return multiple instances of the resource. The List operations can be sorted and filtered.

Sorting

To sort the returned data, pass in the sort_by method argument.

Each resource supports a unique set of valid sort fields and can only be sorted by one field at a time.

Special note about the List Folder Endpoint

For historical reasons, and to maintain compatibility with a variety of other cloud-based MFT and EFSS services, Folders will always be listed before Files when listing a Folder. This applies regardless of the sorting parameters you provide. These will be used, after the initial sort application of Folders before Files.

Filtering

Filters apply selection criteria to the underlying query that returns the results. They can be applied individually or combined with other filters, and the resulting data can be sorted by a single field.

Each resource supports a unique set of valid filter fields, filter combinations, and combinations of filters and sort fields.

Filter Types

Paths

Files.com preserves the spelling of file and folder paths while comparing them using shared case and Unicode rules. Use the SDK comparison helpers when matching paths locally.

Capitalization

Files.com uses case-insensitive path matching based on its fixed Unicode comparison map.

For example, the following paths have the same comparison key:

This behavior applies across:

• API requests
• Folder and file lookup operations
• Automations and workflows

See also: Case Sensitivity Documentation

Slashes

Use / between folder and file names, without leading or trailing slashes. SDK normalization helpers convert backslashes to /, remove duplicate separators, and discard exact . and .. components. Discarding .. leaves the preceding folder name intact.

Unicode and Path Comparison

Files.com compares paths using a fixed mapping shared by the server and SDKs. It treats case and many accent differences as equivalent: Résumé.txt and resume.txt identify the same file, as do q followed by a combining acute accent and q. The mapping also handles other equivalences, such as Hiragana and Katakana. Lowercasing or applying a standard Unicode normalization form alone does not reproduce these rules.

SDK comparison helpers normalize path separators and dot segments, then apply the bundled versioned comparison map. The shared examples give exact comparison results for integrations that implement their own matching. The map uses hexadecimal Unicode scalar values as keys: a missing entry preserves the character, an empty replacement removes it, and other replacements may contain several characters. Apply each replacement once without normalizing or lowercasing the result again.

Use comparison results only for matching. Send the original path spelling in API requests and preserve it for display and local filenames; comparison results can have a different spelling or length.

Trailing whitespace is significant for comparison. report.txt and report.txt are different file paths, and SDK helpers preserve spaces, tabs, and newlines. Folder names cannot end in whitespace. See Unicode Normalization for the complete path rules.

Workspaces

A Workspace groups files, users, groups, Partners, integrations, and workflows within a Files.com Site. An integration can provision a Workspace for a department or project and delegate its operation to a team without making that team Site Administrators. Every Site has a Default Workspace, with ID 0; additional Workspaces have their own IDs and root folders.

Account membership, request context, and permission grants serve different purposes. Creating an account in a Workspace determines where it belongs. Selecting a Workspace determines which resources a request operates on. A permission grant determines what the caller can do there. Selecting a Workspace never grants access to it.

Accounts and Administrative Access

A user's or group's workspace_id identifies the Workspace the account belongs to. Accounts belonging to a Custom Workspace stay within it. Default Workspace users and groups can receive permissions in one or more Custom Workspaces while keeping their existing accounts in Workspace 0.

workspace_admin is not a summary of a user's effective administrative access. A Default Workspace user can administer a Custom Workspace through a direct or group root grant while their workspace_admin remains false. Groups have no workspace_admin field. See Users and Groups for account fields.

An admin grant on the Custom Workspace root provides full Workspace Administrator authority over its files, users, groups, Partners, workflows, and integrations. An admin grant on a subfolder provides Folder Admin authority over that folder and its descendants; it does not provide Workspace administration. Other permission levels provide their corresponding folder access without Workspace administration. Permissions defines the levels.

Site Administrators manage cross-Workspace assignments to Default Workspace accounts. Workspace Administrators manage accounts and permissions within their own scope. Site Administrators retain access to every Workspace; adding a Workspace grant does not narrow Site Administrator authority. The product documentation explains the administrator's operational scope and site-wide controls.

Request Context and API Keys

You can include the X-Files-Workspace-Id REST header to select a Workspace for a request. SDK request options and CLI configuration send that same selection. When a Workspace is selected, Workspace-scoped resources are listed, created, and changed within that context, and ordinary paths are relative to its root.

A resource's workspace_id request field describes the resource's Workspace membership. It is separate from the SDK's Workspace request option or REST header. Creating a Workspace-scoped resource in a Custom Workspace defaults its workspace_id to the selected Workspace; a mismatching membership value is rejected with not-authorized/insufficient-permission-for-params.

Selecting another Workspace with an API key requires a Full Access key created in the Default Workspace. A user key follows that user's current access, including group permissions. A site-wide Full Access key created in the Default Workspace has Site Administrator authority in every Workspace. A Files Only key stays in its creation Workspace, even if its user has cross-Workspace access. Any key created in a Custom Workspace stays within that Workspace. Selecting another context with these confined keys is rejected with bad-request/invalid-workspace-id-header.

An account belonging to a Custom Workspace is scoped there when it authenticates normally. For a Default Workspace user, explicitly select the intended Workspace for an integration rather than relying on an interactive login preference. API Keys and Authentication cover credentials.

The adjacent request uses the member's own Default Workspace Full Access user key to list the root of Workspace 123, after access has been assigned.

curl 'https://YOUR_SUBDOMAIN.files.com/api/rest/v1/folders/' \  -H 'X-FilesAPI-Key: YOUR_MEMBER_API_KEY' \  -H 'X-Files-Workspace-Id: 123'

Delegating a Workspace to an Existing Group

An operations team already represented by a Default Workspace group can administer a Custom Workspace through one root Permission. The group and its members stay in the Default Workspace, so the same team can receive different access in other Workspaces.

First retrieve the target Workspace and Group IDs as a Site Administrator in Workspace 0. The examples use Workspace 123, group 456, and member user 789; replace them with your own IDs. Confirm that the group belongs to Workspace 0 and that the intended user is a member.

Create the Permission using a Default Workspace Full Access site-wide key or a Full Access user key belonging to a Site Administrator. Keep the request context at 0 and use the qualified root path _/Workspaces/123. Set group_id to the group's ID, permission to admin, and recursive to true. Save the returned Permission id for later removal. For an individual Default Workspace user, use user_id instead of group_id.

For a Default Workspace group, a Site Administrator can also select Workspace 123 and use an empty path to grant access to its root. The qualified path in Workspace 0 works for both Default Workspace users and groups and keeps the account scope and target Workspace explicit. Appending a subfolder to the path would grant Folder Admin access instead of Workspace Administrator authority.

After the grant, make a request as the member, using their own credential with Workspace 123 selected, such as listing that Workspace's root folder. That member can work with the Workspace's files and perform Workspace Administrator operations, such as managing its users, Partners, and integrations. A Site Administrator's successful request does not establish that the member has the intended access.

curl 'https://YOUR_SUBDOMAIN.files.com/api/rest/v1/workspaces' \  -H 'X-FilesAPI-Key: YOUR_SITE_ADMIN_API_KEY' \  -H 'X-Files-Workspace-Id: 0'curl 'https://YOUR_SUBDOMAIN.files.com/api/rest/v1/groups' \  -H 'X-FilesAPI-Key: YOUR_SITE_ADMIN_API_KEY' \  -H 'X-Files-Workspace-Id: 0'

curl 'https://YOUR_SUBDOMAIN.files.com/api/rest/v1/permissions' \  -X POST \  -H 'X-FilesAPI-Key: YOUR_SITE_ADMIN_API_KEY' \  -H 'X-Files-Workspace-Id: 0' \  -H 'Content-Type: application/json' \  -d '{"path":"_/Workspaces/123","group_id":456,"permission":"admin","recursive":true}'

Permission Inspection and Removal

List the member's Permissions with user_id and include_groups=true to include grants inherited through group membership. Listing only direct user grants can miss the Permission that provides Workspace administration. In Workspace 0, the Custom Workspace root appears as _/Workspaces/123; in Workspace 123, paths are relative to that root. Inspect the root path and permission=admin, rather than treating the user's workspace_admin field as their effective administrative access.

Permission lists show individual grants, rather than a single flag for effective administrative access. Membership in several groups combines their access. A Permission using group_ids instead of group_id requires membership in all the specified groups; it is not a shorthand for assigning the same grant to several independent groups.

Removing a member ends access received through that group. Deleting the root Permission ends the group's Workspace Administrator grant for every member. These changes leave independent direct and other group grants in place, so review all applicable grants when withdrawing access. Default Workspace user API keys follow those permission changes without being recreated.

Group membership maintained through SCIM follows the same rule. A Group Admin allowed to add members can give those users the group's existing Workspace Administrator access. Choose who manages the group with that authority in mind.

Delete the Permission by its returned id as the Site Administrator in Workspace 0. The removal examples use Permission ID 9001; replace it with the ID returned by your create request. Permissions are created and deleted, rather than updated in place. If narrower folder access is still needed, assign it explicitly; deleting a broad grant does not restore narrower grants it previously replaced.

curl 'https://YOUR_SUBDOMAIN.files.com/api/rest/v1/permissions?user_id=789&include_groups=true' \  -H 'X-FilesAPI-Key: YOUR_SITE_ADMIN_API_KEY' \  -H 'X-Files-Workspace-Id: 0'curl 'https://YOUR_SUBDOMAIN.files.com/api/rest/v1/permissions/9001' \  -X DELETE \  -H 'X-FilesAPI-Key: YOUR_SITE_ADMIN_API_KEY' \  -H 'X-Files-Workspace-Id: 0'

Foreign Language Support

The Files.com MCP will soon be updated to support localized responses by using a configuration method. When available, it can be used to guide the API in selecting a preferred language for applicable response content.

Language support currently applies to select human-facing fields only, such as notification messages and error descriptions.

If the specified language is not supported or the value is omitted, the API defaults to English.

Errors

Mock Server

Files.com publishes a mock Files.com API server, which is useful for testing your use of the Files.com SDKs and other direct integrations against the Files.com API in an integration test environment. It never checks credentials: send any placeholder API key, such as YOUR_API_KEY, and never use real Files.com credentials with it.

The server has two modes, chosen when it starts:

• Legacy mode (the default) checks required parameters and parameter types, then returns a fixed example response for each API endpoint. It does not maintain state and it does not deeply inspect your submissions for correctness, which makes it useful for testing basic network operations and JSON encoding for your SDK or API client.
• Simulation mode keeps records, files and folders in memory, so a test can create, list, update and delete resources, upload a file and download the same bytes, and make chosen requests fail, stall or lose their connection on purpose. Requests it does not simulate fail with a clear error instead of returning an example response.

Quick Start with Docker

With Docker installed, start the published image from Docker Hub with the command shown. It runs legacy mode at http://127.0.0.1:4041, reachable from your machine only: point your integration's Files.com API base URL there and use a placeholder API key. Stop it with Ctrl+C; --rm removes its container.

The published image is built for linux/amd64 only, so the command asks for that platform; without it, Docker on a machine of another architecture, such as an Apple silicon Mac, looks for an image the tag does not have. The latest tag moves to whichever server was published last, and --pull=always fetches it again each time, so it need not include simulation mode. To run simulation mode, build the image from the source as below.

docker run --platform linux/amd64 --rm --pull=always -p 127.0.0.1:4041:4041 filescom/files-mock-server:latest
## In another terminal, with a placeholder API key:curl -H "X-FilesAPI-Key: YOUR_API_KEY" http://127.0.0.1:4041/api/rest/v1/users

Simulation Mode in Docker

To run exactly the server the source's README describes, simulation mode included, build the image from a checkout of the source on GitHub and run it by the image ID you record with your test results. Only linux/amd64 builds of the source have been checked, so both commands ask for that platform.

Simulation mode listens only on loopback unless told otherwise, so the command binds it to the container's interfaces with -b tcp://0.0.0.0:4041 and publishes the port on your machine's loopback address only. FILES_MOCK_TRANSFER_ORIGIN tells it the address your tests use, so the upload and download URLs it returns point at the published port.

Simulation mode keeps its state only in the server process. Its control endpoints under /__files_mock/v1 report when the server is ready, reset it with your fixtures, add fault rules and return the journal of the requests it received. It refuses work over its limits instead of truncating it. The README in the source describes all of these, the operations it simulates and how to configure its limits.

## In a checkout of the source:docker build --platform linux/amd64 -t files-mock-server:local .image=$(docker image inspect --format '{{.Id}}' files-mock-server:local)echo "$image"   # record this ID with your test resultsdocker run --platform linux/amd64 --rm -e FILES_MOCK_MODE=simulation \  -e FILES_MOCK_TRANSFER_ORIGIN=http://127.0.0.1:40410 \  -p 127.0.0.1:40410:4041 "$image" -b tcp://0.0.0.0:4041
## In another terminal:curl http://127.0.0.1:40410/__files_mock/v1/ready

From the Source with Ruby

Start the server from its source with Ruby and Bundler. FILES_MOCK_MODE is read once at startup: leaving it unset or setting it to legacy starts legacy mode, simulation starts simulation mode, and any other value stops startup with an error. Legacy mode listens on port 4041 on all IPv4 interfaces, and simulation mode on 127.0.0.1:4041.

bundle install
## Legacy modebundle exec puma
## Simulation modeFILES_MOCK_MODE=simulation bundle exec puma

Compatibility

Version 2 of files-com-mcp needs Python 3.11 or newer, up from the previous Python 3.10 minimum, and version 2 of the Files.com Python SDK (files-com>=2.0.0,<3), which it installs itself. To use version 2, make sure your client starts the server with Python 3.11 or newer, for example with uvx --python ">=3.11" files-com-mcp.

Changes in version 2:

• A tool call that fails, such as for a missing required input, an API key the site rejects, a permission or not-found error, a local path outside FILES_COM_LOCAL_ROOT or a failed transfer, now returns an MCP tool result with isError set. The message text is unchanged.
• List tools that return one page of results at a time take the cursor their response gives for the next page, and a per_page page size.
• Tool calls run concurrently. Cancelling a call, or closing the connection, stops its request or transfer before the call ends: the client receives the cancellation only after the call has stopped, and an interrupted download does not leave a partial file.
• The server no longer prints a banner or checks PyPI for FastMCP updates when it starts. files-com-mcp --version prints its version.
• The package installs FastMCP 3.4.7 as fastmcp-slim with the requirements of its server extra, but with the memory and file-tree key-value stores only, not the keyring store (and the keyring package it brings). The server uses neither keyring nor that store. Python code that embeds this package and configures FastMCP's KeyringStore must now install py-key-value-aio[keyring] itself.
• It requires exactly the FastMCP (3.4.7) and mcp (1.30.0) releases whose internals it adapts, and refuses to start with others. It adapts them by replacing methods on their classes when create_mcp() first builds a server (the STDIO server calls it), so from then on the changed cancellation and end-of-input handling apply to every FastMCP server in the process, including those of other applications hosted beside this package.

Development

Run the Python MCP package locally over STDIO when developing or modifying tools. Upload and Download tools rely on the file system where the MCP is running. For network connections, use the Files.com hosted MCP service.

pyproject.toml lists FastMCP's server requirements itself, so upgrading FastMCP means reconciling that list with the new release's metadata: ./test.sh fails until the list matches fastmcp-slim's server extra, apart from the deviations it explains, and the adapters in files_com_mcp/patches must be checked against the new FastMCP and mcp internals before files_com_mcp/framework.py accepts them.

The server depends on the Files.com Python SDK generated with it. ./test.sh checks formatting, lint and types and runs the tests without changing any file; set FILES_COM_SDK to that SDK's wheel, or generate the python target next to this one and it is built for you. PYTHON chooses the interpreter (3.11 or newer). scripts/tasks.py also builds and tests the wheel and sdist (package) and resolves the hash-pinned requirements in requirements/ (lock).

To test LLM tools we recommend a popular command-line program called inspector. This will start a WebUI on a local port, the output of the command will give you the link to the inspector GUI. Ex: http://127.0.0.1:6274

Development - STDIO

FILES_COM_API_KEY="dummyKey" npx @modelcontextprotocol/inspector uv run -m files_com_mcp

uv run resolves the package's dependencies, and cannot find the unreleased SDK version that a development build requires; run it in an environment that already has that SDK installed, or use an environment built by scripts/tasks.py.

Development Claude Config

{  "mcpServers": {    "Files.com": {      "type": "stdio",      "command": "uv",      "args": [        "--directory",        "/path/to/folder-containing-files_com_mcp",        "run",        "-m",        "files_com_mcp"      ],      "env": {        "FILES_COM_API_KEY": "CHangeME"      }    }  }}

Development - Shared Mock Server

tests/shared_user_find.py checks the generated Find_User tool end to end against the mock server's shared users-find scenario. It starts this package as a child MCP STDIO server pointed at the mock server, and compares the user the tool returns with the scenario's expected_user.

In the generator repository, generate this target, python and mock-server, install the mock server's gems (see its README), and run pip3 install ../python . in generated/python-mcp to install the SDK generated beside this package with it. Then run from that directory:

ruby ../mock-server/with-scenario.rb --scenario users-find --out "$(mktemp -d)" -- python3 -m unittest -v tests.shared_user_find

The launcher passes the mock server's address, a placeholder API key and the scenario file. The test gives the address and key to the server it starts as FILES_COM_BASE_URL and FILES_COM_API_KEY. unittest discover does not run it, and it fails when run without the launcher.

MCP Registry Metadata

mcp-name: com.files/python-mcp