关注更多ai编程资讯请去ai coding专区：https://juejin.cn/aicoding

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 的话，你会发现一个 - 掘金^[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 server

glama.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 at http://localhost:3333/sse#^[12] Message endpoint available at http://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: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 的效果，那确实值得我们反思：是不是应该尝试一些更创新的解决方案？

未来的展望和设想

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

「短期改进：」

我们可以尝试在团队内部推动一个简洁但强制性的设计规范，比如图层命名规则或组件化标准。这样可以先让 MCP 的效果最大化。

「探索新工具：」

我们也可以尝试试点一些低代码平台（比如 Webflow 或 Bubble）结合 AI 工具，看看实际效果如何。这种方法可能比当前 MCP 更贴近我们的真实需求。

「长期方向：」

关注 “低代码 + AI” 的发展趋势，或许可以通过低代码方式更好的提前布局未来。

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

更多的交流欢迎讨论!

注：相关【掘金】文章请点击阅读原文查看。