智能体电商
商店的 UCP MCP 端点暴露了哪些工具？
更新于
在我们测量的每家商店中都有13个：目录有三个（search, lookup, get product），购物车有四个（create, get, update, cancel），结账有五个（create, get, update, complete, cancel），订单有一个（get order）。它是一个完整的商务 API，而不是一个结账附加组件。列出这些工具不需要任何东西；调用它们则要求代理提供其自身可解析的身份，因此匿名请求会被拒绝。
这13个
通过向每家商店的发现文档中指定的 MCP 端点发布工具列表请求而观察到的。提供此类文档的70家商店中有69家返回了完全相同的集合；一家则什么都没有返回。
| 组别 | 工具 | 它允许代理做什么 |
|---|---|---|
| 目录 | search_catalog, lookup_catalog, get_product | 直接查询目录，而不是抓取和解析产品页面。 |
| 购物车 | create_cart, get_cart, update_cart, cancel_cart | 在多次对话中组装和修改购物车。 |
| 结账 | create_checkout, get_checkout, update_checkout, complete_checkout, cancel_checkout | 将购物车通过地址和配送选择，完成购买。 |
| 订单 | get_order | 事后检索订单，用于追踪或支持。 |
改变你思考方式的两个
目录搜索具有战略重要性。能够直接查询你目录的代理没有理由渲染你的产品页面，这意味着商品陈列、页面布局和页面上的说服力都无法触及它。触及它的是数据。
订单检索是另一个。它将服务范围从购买延伸到支持，这正是代理价值的很大一部分所在——也是商家现有流程假设是人类在提问的地方。
列出是开放的；调用则不是
工具列表请求不需要凭据，这就是为什么上述清单任何人都可以验证。调用工具则不同：我们测试的服务器拒绝了匿名请求，要求调用代理首先提供其自身可解析的配置文件。
这是一种双向身份握手，而不仅仅是商家发现，它比这种故事的夸张版本所暗示的更为周全。任何未识别的调用者都可以访问的结账 API 将是一个滥用接口；而这并非如此。
集成前值得了解的架构详情
每个工具都带有一个完整的 JSON 架构，并接受一个元数据参数。价格以带货币代码的整数最小单位返回，架构说明明确警告代理在向买家报价前必须进行转换——这种细节区分了已发布的 API 和规范存根。
常见问题
- 这个列表在每家商店都一样吗？
- 在我们测试的70家商店中有69家是相同的，所有商店都报告了相同的协议版本。有一家商店提供了一个有效的发现文档，但随后根本没有宣传任何工具，这看起来像是一个半配置的部署，而不是不同的实现。
- 我可以调用这些工具来测试我自己的商店吗？
- 你可以自由列出它们。调用它们需要你的代理提供一个可解析的身份，因此一个裸脚本会被拒绝。列出足以确认该接口存在及其涵盖范围。
- 暴露这些工具是否意味着代理会绕过我的店面？
- 对于发现和购买，很大程度上是的——使用目录搜索的代理永远不会渲染你的页面。这使得你的产品数据的准确性，而不是你的页面设计，成为决定代理向买家介绍你的内容的关键。
来源
- DTC AI 爬虫索引 — 147个品牌，于2026年8月14日收集 — PlatformDTC (primary data)
- 代理结账已在半数 DTC 商店上线 — PlatformDTC (primary data)