| FMRS | 64 / 100 · C | 63 / 100 · C |
|---|
| Reliability | 8 / 20 | 8 / 20 |
|---|
| Security and permissions | 17 / 20 | 13 / 20 |
|---|
| Maintenance | 10 / 20 | 15 / 20 |
|---|
| Documentation | 16 / 20 | 14 / 20 |
|---|
| Setup experience | 13 / 20 | 13 / 20 |
|---|
| Best for | - Teams and individuals who already manage docs/wikis in Notion and want AI clients (Claude Desktop, Cursor, etc.) to operate on that content directly
- Developers who want to self-host a local MCP server rather than use a remote hosted option
- Automation/agent workflows that need to query or update Notion database records programmatically
| - Designers and design system teams looking to integrate AI into their workflow.
- Developers needing quick prototyping or visual spec generation.
- Product managers who need to communicate visual requirements during discussions.
- Teams managing multi-file design systems (via figma_execute_across_files).
- Developers who need to export tokens from Figma to their codebase (token sync).
|
|---|
| Not for | - Users who want the standard-OAuth, zero-JSON-config install with active official support — Notion recommends its newer remote Notion MCP server for that
- Users uncomfortable handing a Notion integration token to a locally-run LLM client
- Use cases needing capabilities the integration deliberately excludes, such as deleting databases
- Long-term production deployments that need guaranteed maintenance, given this repo may be sunset
| - Users who need read-only access and want to avoid installing Node.js — consider Remote SSE mode (9 read-only tools).
- Users who strictly need code generation (e.g., React/HTML) — the official Figma Dev Mode MCP is more suitable.
- Users who want quick evaluation without write capabilities — Remote SSE is sufficient.
- Users who want to design in the cloud but avoid installing the Desktop Bridge plugin (Cloud Mode still requires the plugin).
|
|---|
| Required permissions | - A Notion internal integration token (NOTION_TOKEN or the Authorization value in OPENAPI_MCP_HEADERS), scoped by that integration's Capabilities (can be limited to read-only)
- Access limited to the specific pages/databases explicitly connected to the integration, not the whole workspace
- A separate bearer auth token when using the Streamable HTTP transport (--auth-token / AUTH_TOKEN)
- Network access to the Notion API
| - Figma personal access token (PAT): file content read, file versions read, variables read, comments read/write (local mode).
- Desktop Bridge plugin permissions: access current file via plugin API, read selection, console logs, document changes, and execute write operations (create frames, variables, etc.).
- Local filesystem: the server writes/reads plugin files in ~/.figma-console-mcp/ (auto-created).
- WebSocket ports 9223-9232: the server listens on these ports locally for plugin connections.
- For Cloud Mode, OAuth is required (remote endpoint) or PAT (Cloud Mode bypasses Enterprise restrictions).
|
|---|
| Risks and side effects | - If the integration is granted broad read/write capabilities and connected to many pages, that content is effectively exposed to the LLM, risking data leakage or unintended edits
- Running with --unsafe-disable-auth removes bearer authentication on the HTTP transport, potentially making it reachable via DNS rebinding from pages a user visits — the README says to only use it on an isolated network
- Multi-tenant token passthrough requires careful TLS/gateway configuration; misconfiguration risks leaking or misrouting Notion tokens between tenants
- The README states this local server may be sunset in favor of the remote Notion MCP, and that issues/PRs here are not actively monitored, so long-term maintenance and security fixes are not guaranteed
- Storing NOTION_TOKEN or OPENAPI_MCP_HEADERS directly in shared client config files risks leaking the secret
| - Write operation risk: tools like figma_execute can run arbitrary plugin code, potentially modifying or deleting designs unintentionally — test on a copy file first.
- Token leakage: FIGMA_ACCESS_TOKEN is stored in plaintext in client configs; if the config file leaks, the token could be abused.
- Remote server trust: the remote SSE endpoint is hosted by a third party (southleft); data (design info) passes through their infrastructure; self-hosting options exist.
- Multi-instance issues: port conflicts may cause connection issues, but multi-instance support is implemented (automatic port fallback).
- Update banner issue: plugin-server version mismatch may cause persistent re-import prompts — fixed in recent releases, but restart clients after upgrading.
|
|---|
| Supported clients | Claude Desktop, Cursor, Zed, GitHub Copilot CLI | Claude Desktop, Claude Code, Cursor, Windsurf |
|---|
| Tools | 9 | 74 |
|---|