Figma + MCP 浅尝-法力无边:lj运营也可以制作活动landing页

juejin.cn/aicoding AI编程板块了解更多AI编程干货

MCP 是什么?

MCP 是什么？

MCP，全称 Model Context Protocol（模型上下文协议），是一种标准协议，旨在解决 AI 模型与外部资源隔离的问题。它的核心功能是允许 AI 系统访问实时数据和外部工具，从而突破其训练数据的限制，提升能力和实用性。

MCP 的工作原理

MCP 通过客户端-服务器架构实现这一目标：

AI 应用作为客户端，发起请求以获取外部资源。
资源服务器（如 Google Drive、Slack 或 Figma）则作为服务器端，响应这些请求并提供所需的数据或功能。

开发者可以构建 MCP 服务器，并将其连接到各种外部服务。例如，一个 MCP 服务器可以链接到 Google Drive 来获取文件，或者连接到 Slack 来获取实时消息。AI 工具作为客户端，通过 MCP 协议与这些服务器交互，从而获得超越其内部知识的更多信息和功能。

MCP 的意义

传统的 AI 模型通常受限于训练时的数据，无法直接访问外部实时信息。而 MCP 的出现打破了这一壁垒，使 AI 系统能够：

获取最新的外部数据（如新闻、文件内容等）。
调用外部工具（如协作平台或设计软件）。
在动态环境中更灵活地运行。

简单来说，MCP 就像一座桥梁，连接了 AI 系统与外部世界，让 AI 的应用场景变得更加丰富和实用。

示例

假设一个 AI 工具需要从 Google Drive 获取最新的文档内容：

开发者搭建一个连接 Google Drive 的 MCP 服务器。
AI 工具（客户端）通过 MCP 协议向服务器发送请求。
服务器返回文档数据，AI 即可基于此进行分析或生成内容。

通过这种方式，MCP 赋予了 AI 更强的扩展性和适应性。

总结来说，MCP 是一种用于连接 AI 与外部资源的标准协议，通过客户端-服务器架构，让 AI 系统能够访问实时数据和工具，突破传统限制，为开发者提供了更多可能性。推荐阅读: 【科普】程序员必看，AI时代新协议 MCP 正在连接吞噬一切，20+资源全收录!如果你最近经常刷 X 的话，你会发现一个 - 掘金

MCP目前的趋势

全球各大厂商都在拥抱MCP,预测MCP生态起来后,MCP会有更多的交互和可能性.

使用cursor+ figma mcp server

glama.ai/mcp/servers...

demo成功演示:youtu.be/6G9yb-LrEqg

运行本地源代码中的服务器

克隆仓库
使用 pnpm install 安装依赖项
复制 .env.example 为 .env，并填写您的 Figma API 访问令牌。只需要读取权限即可。

使用 pnpm run dev 启动服务器，并结合命令行参数部分的任何标志。

配置

服务器可以通过环境变量（通过 .env 文件）或命令行参数进行配置。命令行参数优先于环境变量。

环境变量

FIGMA_API_KEY: 您的 Figma API 访问令牌（必需）
PORT: 服务器运行的端口（默认: 3333）

命令行参数

--version: 显示版本号
--figma-api-key: 你的 Figma API 访问令牌
--port: 服务器运行的端口
--stdio: 以命令模式运行服务器，而不是默认的 HTTP/SSE
--help: 显示帮助菜单

连接到 Cursor

启动服务器

npx figma-developer-mcp --figma-api-key=# Initializing Figma MCP Server in HTTP mode on port 3333...# HTTP server listening on port 3333# SSE endpoint available at http://localhost:3333/sse# Message endpoint available at http://localhost:3333/messages

连接 Cursor 到 MCP 服务器

服务器运行后，在 Cursor 的设置中，功能标签页下连接 Cursor 至 MCP 服务器。

连接服务器后，在开始之前可以确认 Cursor 是否建立了有效的连接。如果看到绿色小点且工具栏显示出来，就可以开始了！

PS:这里可能需要注意,我自己公司电脑不知道网络还是什么问题,始终跑不通~

使用Agent Figma 设计一起开始使用

需要注意的是,Cursor 最新版本已经取消composer,Composer已经迭代为agent模式

一旦 MCP 服务器连接上，你就可以开始在编曲器中使用 Cursor 的工具，前提是编曲器处于代理模式。

将 Figma 文件的链接拖放到编曲器中并让 Cursor 做些什么，应该会自动触发 get_file 工具。

大多数 Figma 文件都非常庞大，所以你可能需要链接到文件中的某个特定框架或组。选中单个元素后，可以按下 CMD + L 复制元素的链接，你也可以在上下文菜单中找到它。

一旦你有了某个特定元素的链接，就可以将其拖放到编曲器中，并让 Cursor 做些什么。

检查响应

为了更方便地检查 MCP 服务器的响应，可以运行 inspect 命令，该命令会启动 @modelcontextprotocol/inspector 的 web UI 用于触发工具调用和查看响应：

pnpm inspect

# > figma-mcp@0.1.12 inspect# > pnpx @modelcontextprotocol/inspector## Starting MCP inspector...# Proxy server listening on port 3333## 🔍 MCP Inspector is up and running at http://localhost:5173 🚀

可用工具

服务器提供了以下 MCP 工具：

获取 Figma 数据

获取关于一个 Figma 文件或文件中特定节点的信息。

参数:

fileKey (字符串, 必填): 获取的 Figma 文件的密钥，通常可以在提供的 URL 中找到，如 figma.com/(file|design)/<fileKey>/...
nodeId (字符串, 可选, 强烈推荐 ): 要获取的节点 ID，通常可以在 URL 参数 node-id=中找到
depth (数字, 可选): 遍历节点树的深度，仅在通过聊天明确请求时使用

download_figma_images (正在开发中)

根据图层或图标节点的 ID，下载 Figma 文件中的 SVG 和 PNG 图像。

参数：

fileKey (字符串，必填)：包含节点的 Figma 文件的密钥
nodes (数组，必需)：要获取为图片的节点
- nodeId (字符串，必需)：要获取的 Figma 图片节点 ID，格式为 1234:5678
- imageRef (字符串，可选)：如果节点具有 imageRef 填充，必须包含此变量。下载向量 SVG 图片时留空。
- fileName (字符串，必需)：保存获取文件的本地名称
localPath (string, required): 项目中存储图像的目录的绝对路径。如果需要，会自动创建目录。

设计原图和实现效果图

对比了一下图片复原效果,还原度一般,还是需要bannner 和图片的替换 ,一些元素和效果消失了。

简单来说，除非所有设计师都严格按照设计规范去约束图层，否则这个figma mcp 可能会显得"鸡肋"。

当前的mcp 模式在处理复杂设计、支持交互以及管理上下文方面仍有很大的改进空间，尤其是在团队协作中，严格执行设计规范是充分发挥工具效能的关键。

设计规范执行到位，才能让设计流程更顺畅、工具效果最大化。 ,否则效果可能还不如画页面的低代码产品训练 ai 生成 json "低代码+AI生成JSON"是名气能有效提升设计的准确性，还能推动设计流程的智能化。我认为这是一个值得深入探索的方向，未来设计工具或许会朝此发展，从而让设计师从繁琐的操作中解脱出来，专注于创意本身。

当前 Figma MCP 的局限性

综合最近使用和体验 MCP 模式在以下几个方面我个人觉得还有很大改进空间：

复杂设计：处理多层次、高复杂度的设计时，表现不够理想。
交互支持：缺乏对动态交互的强大支持。
上下文管理：制约于模型限制，难以高效地管理设计上下文。

这些问题确实肉眼可见存在，实现效果好坏的关键是：是否能严格执行设计规范是充分发挥工具效能的前提。

如果团队成员的设计习惯不一致，图层命名混乱或结构随意，MCP 的作用就会大打折扣，甚至拖慢整个流程。

提一下AI时代设计规范的重要性

设计规范到位确实能让设计流程更顺畅。比如：

一致性：统一的命名规则和图层组织能让团队协作更高效。
工具效能：MCP 这样的工具依赖于结构化的输入，规范执行到位才能让它"如鱼得水"。
可维护性：后期修改或扩展设计时，规范化的文件更容易上手。

但我也理解，在团队中强制执行设计规范并非易事。不同设计师有自己的习惯，培训和协调都需要时间和精力,有兴趣的可以去了解一下领域驱动设计DDD,这可能是我觉得 MCP "鸡肋"的一个原因------它本该是助力，却因为现实中的执行难度显得不够给力。

"低代码 + AI 生成 JSON"的潜力

上面我提到的"低代码 + AI 生成 JSON"方向其实是个很有意思的方向，这可能是未来设计工具发展的趋势。这种方法有几个明显的优势：

提升准确性：AI 可以根据设计规范自动生成结构化的 JSON 输出，减少人为错误。
智能化流程：低代码平台结合 AI 能将繁琐的手动操作自动化，比如从设计稿直接生成可用的代码或数据结构。
解放创意：设计师可以把更多精力放在创意和用户体验上，而不是被工具的限制牵绊。

相比之下，如果 MCP 当前的表现还不如低代码产品配合 AI 的效果，那确实值得我们反思：是不是应该尝试一些更创新的解决方案？

未来的展望和设想

基于这个想法感觉一些未来展望：

短期改进：
1. 我们可以尝试在团队内部推动一个简洁但强制性的设计规范，比如图层命名规则或组件化标准。这样可以先让 MCP 的效果最大化。
探索新工具：
1. 我们也可以尝试试点一些低代码平台（比如 Webflow 或 Bubble）结合 AI 工具，看看实际效果如何。这种方法可能比当前 MCP 更贴近我们的真实需求。
长期方向：
1. 关注"低代码 + AI"的发展趋势，或许可以通过低代码方式更好的提前布局未来。

我也很期待未来设计工具能朝这个方向进化，让产品经理和设计师从繁琐的操作中解脱出来，专注于创意本身。

更多的交流欢迎讨论!