Figma Context MCP
Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.
作者提供的说明(英文原文)
The image pipeline for agents: presets, assets and jobs. Answers with asset ids and stable URLs.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
IMAGESTEP_API_KEY, Authorization标为机密的值是你账户的钥匙。千万不要分享给别人,也不要粘贴到聊天里。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
这个地址需要在请求的 header 中放入密钥,而添加连接器的菜单无法设置。请改用 Claude Code、Cursor 或 VS Code。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"imagestep": {
"command": "npx",
"args": [
"-y",
"@imagestep/mcp"
],
"env": {
"IMAGESTEP_API_KEY": "your-value"
}
}
}
}在终端中运行这条命令
claude mcp add --transport http imagestep https://mcp.imagestep.dev/mcp --header 'Authorization: your-value'claude mcp add imagestep --env IMAGESTEP_API_KEY=your-value -- npx -y @imagestep/mcp运行前请先填写空着的值。
粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"imagestep": {
"url": "https://mcp.imagestep.dev/mcp",
"headers": {
"Authorization": "your-value"
}
}
}
}粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"imagestep": {
"command": "npx",
"args": [
"-y",
"@imagestep/mcp"
],
"env": {
"IMAGESTEP_API_KEY": "your-value"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"imagestep": {
"type": "http",
"url": "https://mcp.imagestep.dev/mcp",
"headers": {
"Authorization": "your-value"
}
}
}
}粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"imagestep": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@imagestep/mcp"
],
"env": {
"IMAGESTEP_API_KEY": "your-value"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个地址需要在请求的 header 中放入密钥,而添加连接器的菜单无法设置。请改用 Claude Code、Cursor 或 VS Code。
你的选择通过 Cookie 保存在这台设备上,无需账户。
Authorization 机密 必填 HTTP header这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
我们还没有读取这个服务器的工具列表;我们会轮流检查各个端点。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过域名 imagestep.dev 验证(注册中心会核实域名所有权)
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
尚未检查;我们会轮流检查各个端点
尚未检查;我们会轮流检查各个端点
尚未检查;我们会在检查端点时读取工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
你需要填写:IMAGESTEP_API_KEY, Authorization
两种方式都可以:安装在你的电脑上,或者连接云端版本。
GitHub 仓库最后更新于–,最新版本(0.2.1)于11天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。
同一分类中有:Figma Context MCP, Claude Real Video, Figma MCP Server
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.
Let any LLM watch a video locally — and search everything it has ever watched.
The Figma MCP server brings Figma design context directly into your AI workflow.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
The image pipeline for agents: presets + assets + jobs, as MCP tools. Images never enter the context window — every tool takes and returns asset references (ids, sizes, public URLs).
| Tool | What it does |
|---|---|
generate | prompt → image(s); returns asset ids + CDN URLs. preset runs it through a saved preset whose subjects keep a character or product identical across a batch (slug@version to pin) |
transform | one atomic op — every op in GET /api/v1/ops but generate, read at startup (stdio) or per request (hosted), falling back to edit remove_bg upscale restore_face colorize analyze resize convert compress crop pad grayscale rotate flip flop trim flatten adjust mask blur_region overlay caption render_template read_metadata when the catalogue cannot be reached. render_template takes no images — parameters: {templateId, items}, one PNG per item. variants (≤ 20) runs the op once per variant in one job, every social size from one call. Two modes, chosen by the input — see below |
run_preset | run a saved, versioned preset — a list of steps, by slug or slug@version (the way to chain ops and keep batches consistent) |
job_status | per-item progress + outputs of a job (an analyze job answers with analyses). A write tool whose wait_seconds runs out returns the job handle with timedOut: true — not an error: the job keeps running and is charged for what completes, so poll this instead of submitting again. Read-only by default: pass publish: true to publish the outputs and get their public URLs. An answer carries at most 20 outputs (search_assets' page; past that outputsTruncated / outputsNote say to read on with search_assets {job_id, cursor}) — publish: true still publishes all of them. Items come a page at a time (the service's page): past the first, itemsCursor goes back as items_cursor for the next, and items_status (FAILED: what a resume would run again) reads only the items in one state; a chain item carries step / failedStep |
search_assets | find assets by collection, keyword, mime, size — or, with group_by: "collection", list your collections. One page per call; the answer's nextCursor, sent back as cursor, reads the next |
save_preset | save a chain you will run again as a named, versioned preset — L1 op steps only, checked by the service before anything is stored; answers slug@version for run_preset to run pinned |
send_feedback | report what ImageStep could not do (capability_gap · bug · other) instead of working around it — free |
Every tool declares an outputSchema: the keys it can answer with in structuredContent, all optional (which ones come back depends on the mode — a finished job, a wait that ran out, a dry run, a synchronous result, a refusal).
Inputs are asset_ids, urls (public http(s), fetched and ingested by the service — never downloaded by this server) or — when the server runs on your machine over stdio — file_paths. Every tool that spends money has dry_run (exact price, nothing created or uploaded — asset_ids are priced as themselves, file_paths / urls by how many) and returns structured errors with retryable, param and the service's requestId (quote it when reporting a failure), so a parameter mistake is refused before any credit is charged.
file_paths are files on your machine, and the agent naming them may be following an instruction it read in a page or a mail, so the server checks each one before reading a byte of it:
. (~/.ssh, ~/.imagestep, .env) — is refused, also when a symlink leads there; ./ and ../ are resolved first;roots, only files under them are read; when it declares none, IMAGESTEP_MCP_FILE_ROOTS (folders separated like PATH) does the same job; with neither, any other folder is readable;A refusal is invalid_param on file_paths and names the path by its index, never its contents. And a job over local files does not publish its outputs unless the call says publish: true — publish defaults to on only when the inputs are asset_ids or urls (and for generate).
The write tools (generate · transform · run_preset · save_preset · send_feedback) take an optional idempotency_key. An MCP client that times out makes the agent call the tool again; with the same key and the same arguments that second call returns what the first one answered — the job it created, the preset it saved — instead of submitting (and charging for) another. The same key with different arguments is refused with idempotency_key_reuse. Without a key, every call is a new submission.
Every tool carries MCP annotations, the hints a client reads to decide what needs your confirmation: job_status and search_assets are readOnlyHint; the write tools are not idempotent (without a key), and none is destructiveHint: every job writes new assets and never overwrites the one it read.
transform has two modes and the agent does not chooseSynchronous when all of these hold: exactly ONE local file or URL, a deterministic op, and wait: true. Nothing is stored in the account — no asset id exists afterwards, because none was created. Sub-second, and the account stays clean.
Where the result goes depends on which of the two servers you are talking to, because the two do not share a filesystem:
| answer | lifetime | |
|---|---|---|
| stdio (this package on your machine) | path — a temp file named for what the service says it produced (convert- .avif, not .bin) | until the server exits; every result of one server lives in one temp directory |
hosted (https://mcp.imagestep.dev/mcp) | url — a signed link, plus expiresInSeconds | ~5 minutes; download it, or run the work as a job if you need a permanent URL |
Both carry mimeType, width and height, so the next tool does not have to guess. The hosted answer is a URL for the obvious reason and it took a bug to notice it: your agent is not on the machine the server runs on, so a path into that container's /tmp is an answer it cannot read. Under the hood that is the API's own ?response=url, which writes the bytes to a short-lived temp object — still nothing in your asset catalogue.
As a job for everything else: several images, asset_ids, any AI op, or wait: false. You get asset ids and public URLs, plus progress, cancellation and webhooks.
Which ops may go the first way is read from GET /api/v1/ops (syncEndpoint), never hard-coded — a deterministic op added to the API is fast here without this package changing. If the catalogue cannot be reached, the job path is used: slower is a better failure than wrong.
A urls input is judged the same on both paths: it must resolve to a public address, and it is refused here — before anything leaves the process — not only by the service that would fetch it. One input never gets two answers because of which transport happened to carry it.
Neither mode ever returns image bytes. An image in the context window is tokens the agent pays for and cannot read; the answer is always a path, an id or a URL.
| URI | What it is |
|---|---|
imagestep://ops | GET /api/v1/ops as is — every op with its parameter contract (type, default, description), prompt and asset requirements, default model and pricing |
imagestep://ops/{op} | one op's entry (template; listed per op when the catalogue was readable at startup) |
imagestep://models/{mode} | GET /api/v1/ai-models?mode= — ai_image or analyze, with prices |
imagestep://usage | GET /api/v1/usage?groupBy=op — what the account spent over the last 30 days, per op |
imagestep://agent-guidelines | the operating contract (below) |
The catalogue resources exist because an MCP-only client (Claude Desktop) cannot curl the API or open the console, and "never invent a parameter" is a rule it can only follow if it can read them. transform also carries a one-line-per-op summary — name(type=default), plus the values a parameter takes when the catalogue lists them, what a required one means, and for an AI op the model's own parameters object — generated from the same catalogue; when that could not be read, it falls back to a built-in summary and says so. All five are read live: a read that cannot reach the service fails rather than answering from a copy.
imagestep://agent-guidelines is the operating contract — read the op catalogue instead of carrying a list, price with a dry run before spending, branch on retryable rather than the status code, keep a batch consistent with a preset, and report a missing capability instead of working around it. It is a resource rather than a tool because a tool is something an agent decides to call and the rules are something it should have read, and it is fetched from the service on every read, so a copy of this package released months ago still serves today's contract.
Get an API key at https://imagestep.dev/keys?utm_source=npm&utm_medium=mcp-readme.
Claude Desktop (claude_desktop_config.json) — local, can upload files from disk:
{
"mcpServers": { "imagestep": { "command": "npx", "args": ["-y", "@imagestep/mcp"], "env": { "IMAGESTEP_API_KEY": "is_sk_…" } } } }
Cursor (.cursor/mcp.json) — same shape:
{ "mcpServers": { "imagestep": { "command": "npx", "args": ["-y", "@imagestep/mcp"], "env": { "IMAGESTEP_API_KEY": "is_sk_…" } } } }
Claude Code — local:
claude mcp add imagestep -e IMAGESTEP_API_KEY=is_sk_… -- npx -y @imagestep/mcp
Remote (any client that speaks Streamable HTTP) — nothing to install:
claude mcp add --transport http imagestep https://mcp.imagestep.dev/mcp --header "Authorization: Bearer is_sk_…"
The remote server is stateless: each request is served by a fresh server bound to the API key in the Authorization header (Bearer or ApiKey). file_paths is disabled there; pass urls or asset_ids. It logs one JSON line per request on stdout: the JSON-RPC method, the tool name of a tools/call, the clientInfo an initialize reports, your key's prefix (the 12 characters the console shows — never the key), whether the key is valid, the HTTP status and the duration. Never a tool's arguments or your prompt. The validity comes from a side request to the API (3 s timeout, not counted as a use of the key), and the answer, valid or not, stands for five minutes. The handshake never waits for it. A request that can call the API on your key (a tool call, a resource read) does, when the server has not seen that key yet, so a wrong key is turned down there with the same unauthorized error the API gives and never reaches the API. An address whose keys turned out invalid 20 times in a minute gets HTTP 429 with Retry-After for any key the server has not seen yet, until the minute is up; a key it already knows to be good keeps working.
The remote server waits at most 90 s per tool call (wait_seconds above that is clamped; the default there is 90). It answers each call as one JSON body, so nothing reaches your client until the tool returns, and Cloudflare's edge drops a response that has not started after 100 s — you would get an HTML 524 with no job id while the job kept running. Past 90 s you get the job handle with timedOut: true instead; poll job_status. Over stdio the wait is what you ask for (default 180 s, max 600 s).
Upload ./product.jpg, remove the background, upscale it 2×, and give me the URL.
The agent calls transform (remove_bg, file_paths), then transform (upscale, asset_ids = the previous output, `parameters:
只显示了开头部分;其余内容请在仓库中阅读