Framelink Figma MCP

The server holds one credential, a Figma personal access token or OAuth token, and attaches it only to requests to Figma's fixed API address; image files are fetched from the URLs Figma returns without the token. Its tools only read from Figma, so through this server the token can read designs but not change them. All tools share that one long-lived token and there is no per-request authorization. The token can also come from a .env file in the working directory, which is loaded without any trust decision.

As a tool server it relies on the MCP host to ask the user before calls. The data tool is correctly labelled read-only, but the image tool, which creates directories and writes or overwrites files in the image directory, carries only an open-world label and no explicit destructive or read-only flag, and there is no preview or dry run. Operators can drop the image tool with a flag, but it is on by default. A wrongly approved call can overwrite image files in the project, which is usually recoverable from version control.

Arguments are checked in code: file keys must be alphanumeric, node IDs must match Figma's ID format, file names are restricted to safe characters with a .png, .svg or .gif extension, and the target directory must resolve inside the configured image directory. All requests go to Figma's fixed API address. The directory check is lexical, and the code notes it does not account for symlinks. There are no upper bounds on how many images a call downloads, on the PNG export scale or on traversal depth, and both tools are on by default.

The server never interprets model text as code: there is no shell, eval, subprocess or script execution in its runtime source. Its work is HTTPS requests to Figma, in-process image cropping and writing image files.

The design data the server returns includes text, layer names and descriptions written by whoever authored the Figma file, which may be a third party. It is returned as one block of serialized text with no marker separating that content from the server's own structure and no untrusted flag. The server offers no egress of its own beyond Figma's API, so a hijacked host cannot use it to send data to an arbitrary address, but it can read other Figma files the token can access and write image files into the project without the server asking anyone.

The server keeps no memory and reads no instruction files. At startup, though, it loads a .env file from its working directory, which may be the user's project or a cloned repository, with no trust decision. That file can set the Figma credentials, the outbound proxy, the image directory, whether the image tool is offered and the HTTP host and port, and its settings apply to every launch from that directory.

The server loads no plugins, launches no other MCP servers and installs nothing at runtime; the only dynamic imports load its own modules and Node built-ins. (Hosts launching it with npx -y is the host's supply-chain choice, not something this server does.)

The Figma token is kept out of the places it does not need to be: startup output masks it, error bodies returned from Figma are scrubbed of it before reaching the model, and telemetry error messages are scrubbed of both startup and per-request tokens. Usage telemetry to PostHog is on by default; it sends metrics rather than design content, but error messages (after token scrubbing) can include Figma file identifiers and local paths. The README shows the token passed as a command-line argument in the host's config file, and the token is long-lived.

The server writes plain-text progress lines to stderr for each tool call, such as which file and node were fetched and where each image was saved, plus error lines. These are not structured, do not record all arguments or results consistently, and are not stored by the server; any lasting record depends on the host capturing stderr. Usage telemetry records each call's metrics in PostHog, but that is analytics, not an audit trail the operator controls.

The server sets no timeout on Figma API calls or image downloads, does not cap how many images one call fetches (they all download in parallel), how large a response or file may be, or the PNG export scale, and fetches the whole file tree unless the model passes a depth. Only error bodies and telemetry messages are truncated. Cancellation from the host is not acted on; stopping the process ends everything because it is a single process, and Figma's own rate limits are the only outside ceiling.