Figma + MCP 浅尝-法力无边∶lj运营也可以制作活动landing页 关注更多ai编程资讯请去ai coding专区：https://juejin.cn/aicodingMCP 是什么?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 的话，你会发现一个 - 掘金[1] MCP 资源推荐阅读awesome MCP server 大全整理精选的 MCP 服务器 精选的优秀模型上下文协议 (MCP) 服务器列表 - 掘金[2] MCP 目前的趋势全球各大厂商都在拥抱 MCP, 预测 MCP 生态起来后, MCP 会有更多的交互和可能性. Vercel AI SDK 4.2 重要更新支持 MCP 介绍 MCP 客户端、推理、来源等 AI SDK 是一个用于使用 - 掘金[3]赛博菩萨 Cloudflare 正式入场 MCP 服务器构建部署似乎几乎每个人都在构建 AI 应用程序和代理时都在谈论 - 掘金[4]国内首家，百度地图核心 API 全面兼容 MCP 协议作为国内首家支持 MCP 协议的地图服务商，百度地图 MCP Serve - 掘金[5]使用 cursor+ figma mcp serverglama.ai/mcp/servers…[6] demo 成功演示:youtu.be/6G9yb-LrEqg[7] 「运行本地」「源代码」「中的服务器」克隆仓库[8]使用pnpm install安装依赖项复制.env.example为.env，并填写您的Figma API 访问令牌[9]。只需要读取权限即可。使用pnpm run dev启动服务器，并结合命令行参数[10]部分的任何标志。「配置」服务器可以通过环境变量（通过.env文件）或命令行参数进行配置。命令行参数优先于环境变量。 「环境变量」FIGMA_API_KEY: 您的Figma API 访问令牌[11]（必需）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 athttp://localhost:3333/sse#[12]Message endpoint available athttp://localhost:3333/messages[13] ?「连接」「Cursor」「到」「MCP」「服务器」服务器运行后，在 Cursor 的设置中，功能标签页下连接 Cursor 至 MCP 服务器[14]。 连接服务器后，在开始之前可以确认 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:5678imageRef(字符串，可选)：如果节点具有 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 的效果，那确实值得我们反思：是不是应该尝试一些更创新的解决方案？ 未来的展望和设想基于这个想法感觉一些未来展望： 「短期改进：」 我们可以尝试在团队内部推动一个简洁但强制性的设计规范，比如图层命名规则或组件化标准。这样可以先让 MCP 的效果最大化。「探索新工具：」 我们也可以尝试试点一些低代码平台（比如 Webflow 或 Bubble）结合 AI 工具，看看实际效果如何。这种方法可能比当前 MCP 更贴近我们的真实需求。「长期方向：」 关注 “低代码 + AI” 的发展趋势，或许可以通过低代码方式更好的提前布局未来。我也很期待未来设计工具能朝这个方向进化，让产品经理和设计师从繁琐的操作中解脱出来，专注于创意本身。 更多的交流欢迎讨论! 注：相关【掘金】文章请点击阅读原文查看。 点击关注公众号，“技术干货” 及时达！ 阅读原文