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 资源推荐阅读
awesome MCP server 大全整理精选的 MCP 服务器 精选的优秀模型上下文协议 (MCP) 服务器列表 - 掘金
MCP目前的趋势
全球各大厂商都在拥抱MCP,预测MCP生态起来后,MCP会有更多的交互和可能性.
- Vercel AI SDK 4.2 重要更新支持MCP介绍 MCP 客户端、推理、来源等 AI SDK 是一个用于使用 - 掘金
- 赛博菩萨 Cloudflare 正式入场 MCP 服务器构建部署似乎几乎每个人都在构建 AI 应用程序和代理时都在谈论 - 掘金
- 国内首家,百度地图核心 API 全面兼容 MCP 协议作为国内首家支持MCP协议的地图服务商,百度地图MCP Serve - 掘金
使用cursor+ figma mcp server
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
# > [email protected] 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"的发展趋势,或许可以通过低代码方式更好的提前布局未来。
我也很期待未来设计工具能朝这个方向进化,让产品经理和设计师从繁琐的操作中解脱出来,专注于创意本身。
更多的交流欢迎讨论!