Filelayer

What Filelayer MCP server does

The Filelayer MCP server provides an authorization layer for SaaS file workflows. Applications can store files as public or private, associate them with a user or organization, list files, retrieve them on behalf of an identity, and create or revoke sharing grants. Sharing can include an expiration time, password, and maximum download count. A named user can also receive access that is later removed for that user.

Access decisions are made through the application layer using the caller identity supplied by the host application. Filelayer records decisions, including denials, in an audit chain scoped by tenant. The design aims to keep ownership, tenant boundaries, delegation, expiration, and revocation in one authorization path instead of duplicating checks in individual route handlers.

How it works

Filelayer sits between an application and infrastructure the application already operates. It uses Postgres for its schema and an interchangeable storage adapter for file bytes. Supported storage choices named in the project include S3, R2, B2, or a local directory. The project does not provide a database or object store of its own.

A file access request is evaluated against grants, roles, expiry, download limits, and revocation state. Signed delivery URLs include a grant identifier and are checked again when used, so revoking a grant can invalidate an otherwise live URL. Download limits are reserved atomically before bytes move. The system also supports byte-range responses, although default delivery proxies bytes through the server rather than providing a CDN path.

The database schema adds constraints against cross-tenant grants and certain cross-project identity or delegation errors. This is not database row-level security: direct queries against the tables are not filtered by Filelayer. Applications that need database-level enforcement must add it separately.

Setup and configuration

The Filelayer MCP server is used with the @filelayer/core package. The quickstart example initializes a Filelayer instance with a base URL. The application supplies its own user or organization identifiers; Filelayer does not require those identifiers to be UUIDs.

Your application must provide Postgres and a configured storage location. The storage bucket must not be publicly accessible if Filelayer authorization is expected to protect files; a public bucket can bypass the authorization layer. The material describes no required environment variables or client-specific configuration.

Tools and capabilities

The documented file operations include putting, getting, and listing files. Share operations create grants, revoke an individual grant, or remove sharing for a named user. File records can be scoped to an owner or organization, and public delivery is represented as an explicit grant rather than an unrestricted schema flag.

The Filelayer MCP server also supports expiry, passwords, download caps, revocation, audit records, and range requests. These features fit documents, contracts, attachments, and exports whose permissions may change. They are less suitable for public images at high volume, media delivery at scale, resumable or multipart direct uploads, or image transformations, which the project says require other infrastructure.

Limitations and notes

The project describes itself as alpha and seeking design partners. Default delivery sends bytes through the application, so it does not provide a CDN for private files. Direct upload is not resumable or multipart; the documented model is one signed PUT and one object. The material also states that the local filesystem adapter receives bytes through the server, while S3 and R2 can keep the process out of that path.