Appwrite MCP vs Vercel MCP 实战对比评测

一个 MCP 服务器的优劣，应该由 Agent 能完成多少任务来评判，而不是它的工具目录里堆了多少选项。所以我把同一个 Agent 分别指向 Appwrite 和 Vercel 托管的 MCP 服务器，让它们做完全相同的工作：部署同一个应用、检查构建结果、诊断一个刻意制造的失败、发布第二个版本、再从失败中恢复。

这两个服务器本身是为不同场景设计的，结果也沿着这条线分化：

Appwrite 深度介入了后端操作，是两者中唯一通过 MCP 暴露了回滚、删除和显式写确认功能的。

Appwrite 在这次运行中真的引入了一个 bug——它的运行时日志工具明明成功获取了数据，却告诉 Agent 获取失败了。

Vercel 部署速度更快，运行时失败的上报也更清晰。静态应用在大约 2.1 秒就达到 READY 状态，专用的日志工具过滤效果也很好。

两个托管 MCP 服务器均通过 OAuth 在同一台 Darwin 25.5 arm64 客户端上运行。每个工具我都先丢弃第一次调用以消除冷启动影响，然后交替使用两个服务器以避免后发优势。所有写数据的操作都指向一个用完即删的项目。

测试设计

两套相同的应用，部署在两个平台上：

一套静态站点，包含完全相同的 index.html 和 marker.json 文件，从同一个源码包在两个平台分别部署。

一套 Next.js 15.2.8 SSR 应用，带有确定性构建标记和可控的 200、400、500 响应。

每个 Agent 都需要完成以下步骤：发现工作区、部署两个应用、检查日志和分析数据、从一次故意诱导的构建失败中恢复、发布 v2、尝试回滚，以及处理并发为 10 的 50 个请求。

六个阶段，顺序一致，两个平台各跑一次。

评分标准

六个维度，正确性优先：准确性和完整性占 30%，结果紧凑度、发现能力与调用效率各占 15%，中位数和 p95 延迟、安全与生命周期控制各占 15%，错误恢复质量占 10%。

两者的总分非常接近，差距说明不了什么问题，各自分类下的详细数据也就没有单独整理。值得展示的是读写和可观测性阶段各任务的得分：

Appwrite 在八个任务中赢了五个，而它输掉的三个都输得很彻底。

路由器 vs 工具箱

Vercel 暴露了 33 个直接工具，覆盖项目、部署、日志、分析、Agent 运行、协作、域名、购买和部署保护。一旦 Agent 有了团队或项目 ID，就调用一个与任务同名的工具。

Appwrite 在少数几个元工具背后暴露了 992 个操作，分布在 81 个服务中。Agent 不需要把每个 schema 都塞进模型的上下文，只需要四步调用：

appwrite_get_context 查找账户、组织和项目

appwrite_search_tools 查找某个操作

appwrite_call_tool 执行它

appwrite_search_docs 搜索当前文档

路由器通常在陌生操作前多花一次调用，但换来了从单一界面访问 Auth、Databases、Storage、Messaging、Functions、 Sites、用量、域名和基础设施的能力。Vercel 的工具箱只要工作不超出部署范围，就更容易导航。

各服务器实际覆盖范围

两个各六个强项。"未暴露"仅指我测试的 MCP 工具集，不代表平台本身的能力。

生命周期控制：Appwrite 暴露得更多

把第一个 URL 跑起来只是容易的那一半。运维人员还需要发布更新、切换版本、禁用功能、清理资源。

Appwrite 把 v2 部署到现有 Site，显式命中了构建缓存，切换了活跃部署，然后在 1.32 秒内回滚到了 v1。公共健康端点立即返回了 version: "v1"。禁用 Site 返回了 404 router_deployment_not_found，重新启用后直接恢复了 v1。

Vercel 的内联部署工具为 v2 创建了新项目，这也意味着它报告没有之前的构建缓存。它测试的 MCP 表面没有暴露回滚、没有重新部署到现有项目、没有项目删除、也没有通用的环境变量管理。这些能力在 Vercel 平台其他位置是存在的，但基准测试要求纯 MCP 操作。实际后果是这次运行中的两个 Vercel 项目至今仍然在线，因为 33 个工具里没有任何一个能删除它们。

写操作安全性也有差异。Appwrite 要求每次变更都带 confirm_write=true，并拒绝第一次未确认的创建。Vercel 的部署工具没有对应参数，不过它的商业运营确实把报价和购买分开处理。

部署速度：Vercel 稍快

Vercel 接受内联文件树，静态应用在大约 2.1 秒内就绪，一次写入完成。Appwrite 需要两步：先创建 Site，再上传并激活一个 gzipped 部署，总共大约 27 秒。SSR 场景下差距缩小到 39.1 秒对比 91 秒，构建时间报告上大约快了 2.3 倍。

两个平台都因为合理且不同的原因拒绝了一个更早版本的 SSR 应用：Appwrite 的适配器要求 next.config.* 文件，Vercel 则因为已知漏洞阻截了 Next.js 15.2.4。每个 Agent 从它拿到的日志中诊断出了自己的失败原因。

一旦 Agent 选定了一个项目，Appwrite 在我测量的每次重复读取上都更快，构建日志一项快了 8 倍。

中位数据来自三轮测试，单次调用只成功一次的只取单次结果。越低越好。

两个服务器都无错误通过了有界并发检查。Appwrite 50 个请求在 5.146 秒壁钟时间内全部返回，Vercel 50 个在 4.714 秒。Vercel 略快，但样本量太小，不足以支撑更广泛的速度结论。

紧凑度才是读写差距真正显著的地方，而非边缘差异。请求 100 条日志条目，Appwrite 返回了约 115 KB（96 个事件），被上下文截断，而 Vercel 返回了 12.3 KB 的过滤后事件。

如何选择

当 Agent 需要同时运维后端和部署时——用户、数据、文件、消息、函数、Site——Appwrite MCP 更合适。如果你需要显式写确认、回滚、重复部署到同一资源、以及 Agent 真正能执行的清理工作，它也是更强的选择。

当任务就是部署、检查、诊断和分析 Vercel 托管的应用时，Vercel MCP 更合适。它的直接工具消除了选择歧义，构建速度更快，日志响应体量小到真正可读。

有必要直说：这两个部署站点都做得很好。我交给任何一个服务器的每个应用都成功上线了，两个 Agent 都能读自己的构建失败日志并在没有帮助的情况下修复它。Vercel 更快——静态应用 2.1 秒对比 27 秒，SSR 构建大约快了 2.3 倍，日志响应体量小到可以真正阅读。Appwrite 到第一个 URL 较慢，但到达之后覆盖范围广得多：回滚、删除、写确认，以及路由器背后 992 个操作的其余部分——Vercel 那 33 个工具完全不涉及这些。如果你的工作在部署就停止，那这个速度就是全部故事。如果不是，多花一次搜索调用能换来很多东西。

测试条件

访问方式：托管 MCP 端点，OAuth 认证。

客户端：单台 macOS arm64 机器，一次连续会话。

写操作阶段：静态部署、SSR 部署、诱导的构建失败、第二个版本、回滚。

排除项：未启用付费保护层级，未执行任何购买操作。

范围：结果描述的是所测 MCP 表面，而非受控的基础设施基准测试。

Originally published on chiragaggarwal.tech.