@muloka/figma-console-mcp 0.5.1 → 0.5.4

package/README.md

@@ -14,8 +14,9 @@
 - **Mode-limit safety** — `figma_setup_design_tokens` and `figma_create_variable_collection` roll the collection back on a mode-limit failure instead of orphaning it, and the setup tool returns your file's real ceiling as `planModeLimit`; the schema's stale 4-mode cap is now a 40 sanity bound (current Figma plans allow 10/20/unlimited — the runtime limit governs)
 - **No orphaned nodes on failure** — `figma_create_connector` validates endpoints before creating (a stale nodeId can no longer strand an endpoint-less connector), and create-child / add-text-to-slide / create-table remove their partially-created node on error; batch stickies report the id of any sticky a failed row left behind. `figma_create_child` also gains the POLYGON/STAR/VECTOR types the plugin always supported
 - **Per-command dispatch budgets** — long-running bridge commands (variable refresh and component scans at 300s, lint/audit at 120s, large component sets) no longer get silently cut off at 30s: the server's real timeout rides in each WS frame and the dispatcher honors it, on both local and cloud transports ([upstream #94](https://github.com/southleft/figma-console-mcp/issues/94) lineage)
-- **Streamable HTTP transport** in local mode — connect multiple local clients to one running instance ([upstream #48](https://github.com/southleft/figma-console-mcp/issues/48))
-- **Per-call file targeting** — `figma_execute` and the token-sync write tools (`figma_setup_design_tokens`, `figma_batch_create_variables`, `figma_batch_update_variables`, `figma_delete_variable`, `figma_rename_variable`, `figma_rename_node`) take an optional `fileKey`. With it, the call runs only in that file, whatever the active file or target lock, so several clients can work in different files at once. If that file isn't connected the call is refused, naming the file and listing the connected ones, rather than landing in the active file. Without it, nothing changes. Local mode only; the cloud relay refuses a `fileKey` ([details](docs/tools.md#targeting-a-file-filekey))
+- **Streamable HTTP transport** in local mode — set `MCP_HTTP_PORT` to serve MCP at `http://localhost:<port>/mcp` and connect multiple local clients to one running instance ([upstream #48](https://github.com/southleft/figma-console-mcp/issues/48)). Loopback only: it binds `127.0.0.1`, and every request must name a loopback `Host` on that port and carry either no `Origin` (non-browser clients) or a loopback one, so web pages can't reach it through DNS rebinding — anything else gets a 403. The HTTP port is published as `mcpHttpPort` in the instance's port-discovery file, and stays there if the file is deleted and the heartbeat re-creates it. (Upstream added its own, separate HTTP endpoint in v1.44.0 under `FIGMA_MCP_HTTP_PORT`, advertised as `mcpHttpUrl`; this fork's `MCP_HTTP_PORT` / `mcpHttpPort` are unchanged.)
+- **Per-call file targeting** — `figma_execute` and the token-sync write tools (`figma_setup_design_tokens`, `figma_batch_create_variables`, `figma_batch_update_variables`, `figma_delete_variable`, `figma_rename_variable`, `figma_rename_node`) take an optional `fileKey`. With it, the call runs only in that file, whatever the active file or target lock, so several clients can work in different files at once. If that file isn't connected the call is refused, naming the file and listing the connected ones, rather than landing in the active file. Without it, nothing changes. `figma_execute` results carry `fileContext` — `{ fileName, fileKey }` of the file the code actually ran in — and `resultAnalysis`, so a caller can verify the targeting from the response. Both arrive only once the Desktop Bridge plugin has been re-imported from v0.5.4 or later; an earlier plugin drops them, so a missing `fileContext` means the targeting is unverified. Local mode only; the cloud relay refuses a `fileKey` ([details](docs/tools.md#targeting-a-file-filekey))
+- **Security ahead of the v1.36.0 base** — MCP SDK 1.32 (fixes, among others, a single oversized HTTP request exhausting server memory); `figma_scan_code_accessibility` never executes `<script>` tags or inline handlers from the HTML it scans (they previously ran inside the server's Node process)
 - **`VariableID:` alias support** in `figma_batch_create_variables` and `figma_setup_design_tokens` ([upstream #52](https://github.com/southleft/figma-console-mcp/issues/52))
 - **`page`/`pageSize` honored in `figma_get_variables` `format: "full"`** ([upstream #98](https://github.com/southleft/figma-console-mcp/issues/98))
 - **Plugin + server build versions surfaced** in the Desktop Bridge UI and diagnostics
@@ -24,10 +25,10 @@
 ## Relationship to upstream
 
 - Frozen at the upstream **v1.36.0** base — this fork does **not** track upstream releases.
-- Upstream fixes are cherry-picked selectively when they matter to this fork's use cases, with original authorship preserved (so far: the v1.38.2 orphan-reaper fix and the v1.39.1 plugin-update-banner direction fix).
+- Upstream fixes are cherry-picked selectively when they matter to this fork's use cases, with original authorship preserved (so far: the v1.38.2 orphan-reaper fix, the v1.39.1 plugin-update-banner direction fix, the v1.39.0 relay fix that lets `figma_execute`'s `fileContext`/`resultAnalysis` reach the server, and the Local Mode part of the v1.41.0 accessibility-scan script-isolation fix).
 - Bugs and requests for this fork go to [this repo's issue tracker](https://github.com/muloka/figma-console-mcp/issues) — do not file them upstream.
 - The hosted `*.southleft.com` endpoints referenced in the documentation below are upstream's service, not this fork's.
-- **Plugin re-imports never announce themselves in this fork.** `PLUGIN_VERSION` tracks the vendored upstream lineage (not the fork's `0.x`), so Figma's "update available" banner only ever fires after an upstream sync — never for fork-side plugin changes. When a fork release says `figma-desktop-bridge/` changed (e.g. v0.5.0's orphan cleanup and dispatch budgets), re-import the manifest manually; the upstream re-import guidance further down doesn't account for this.
+- **Plugin re-imports never announce themselves in this fork.** `PLUGIN_VERSION` tracks the vendored upstream lineage (not the fork's `0.x`), so Figma's "update available" banner only ever fires after an upstream sync — never for fork-side plugin changes. When a fork release says `figma-desktop-bridge/` changed (e.g. v0.5.0's orphan cleanup and dispatch budgets, v0.5.4's `fileContext` relay), re-import the manifest manually; the upstream re-import guidance further down doesn't account for this.
 - Upstream's docs site and sponsorship: [![Documentation](https://img.shields.io/badge/docs-docs.figma--console--mcp.southleft.com-0D9488)](https://docs.figma-console-mcp.southleft.com) [![Sponsor](https://img.shields.io/badge/Sponsor-southleft-ea4aaa?logo=github-sponsors&logoColor=white)](https://github.com/sponsors/southleft)
 
 ---