电商接入 MCP，先防工具接口变更

Adobe 要把商品目录、购物车、库存和结账能力交给 AI agent 调用。作者的判断是：新增销售入口只是表面，更大的变化是，原本由自家前端消费的数据，开始成为陌生模型调用的公共接口。字段说明、价格时效和购物车更新语义，都会直接影响用户得到的答案。

这篇最值得读的地方，是把发布会愿景拆成了工程问题。不过，原文写作时 Adobe 官方文档仍标注「Coming Soon」，工具名称、鉴权和限流等细节尚未公开。下面讨论的是接入前必须处理的边界，不能当成已上线能力清单。

MCP 接上的不只是目录，还有一份公共契约

先分清 Adobe 提到的三件事。Commerce MCP server 面向真实商店数据，覆盖目录、定价、库存、促销、购物车、结账、订单及售后；开发者 MCP server 则服务于编码。aio commerce extensibility tools-setup 安装 Commerce App Builder MCP server，选择 AEM Boilerplate Commerce starter kit 时还会安装 drop-ins MCP server。后两者帮助开发扩展，不负责替消费者购物。

协议也分层。MCP 用 tools/list 暴露工具名称、描述、inputSchema 和可选的 outputSchema，通过 tools/call 调用；UCP 规定商品、购物车和结账能力的表达方式；ACP 聚焦支付交接，让商家继续承担收款主体责任。

原文给出的时间线是：OpenAI 与 Stripe 在 2025 年 9 月 29 日以 Apache 2.0 发布 ACP，同期推出 ChatGPT Instant Checkout；Google 与 Shopify 等共同开发的 UCP 于 2026 年 1 月 11 日公布。Adobe 在 2026 年 2 月承诺支持 ACP、UCP，此前已承诺支持 Agent Payments Protocol，但只说会在 2026 年持续增加能力。

为什么工程师要关心工具契约？原文用 Shopify 举例：2026 年 4 月 9 日还能调用的 search_shop_catalog，4 月 10 日返回了 Tool not found: search_shop_catalog。新工具改叫 search_catalog，参数也嵌套进 catalog 对象，UCP 目录工具位于 /api/ucp/mcp。

更隐蔽的是行为变化。原文引用的 UCP Checker 材料称，新 update_cart 使用 PUT 语义，替换整个购物车状态；遗漏某个商品，可能就把它删掉。旧购物车工具的弃用截止日则是 2026 年 8 月 31 日。

工具名称和更新语义，都应该按公共 API 管理。

工具描述同样参与执行：模型会据此选择工具、组织参数。只写「获取商品」，和明确说明「查询当前店铺视图的库存商品，价格需在结账时复核」，给模型的决策依据不同。

下面是作者自建只读工具的示意，使用官方 TypeScript SDK @modelcontextprotocol/sdk 1.x，作者称可在 1.30.0 编译。名称、描述和地址均非 Adobe 官方接口：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "store-catalog", version: "1.0.0" });

server.registerTool(
  "catalog_search_v1", // versioned on purpose: renames are outages
  {
    title: "Search catalog",
    description:
      "Search in-stock products for the default store view. " +
      "Prices are indicative and are re-validated when added to cart.",
    inputSchema: { query: z.string().min(2).max(100), limit: z.number().int().max(10).default(5) },
  },
  async ({ query, limit }) => {
    const res = await fetch("https://store.example.com/graphql", {
      method: "POST",
      headers: { "Content-Type": "application/json", Store: "default" },
      body: JSON.stringify({
        query: `query ($q: String!, $n: Int!) {
          products(search: $q, pageSize: $n) {
            items { sku name stock_status
              price_range { minimum_price { final_price { value currency } } } }
          }
        }`,
        variables: { q: query, n: limit },
      }),
    });
    const { data } = await res.json();
    const items = data.products.items.map((p: any) => ({
      sku: p.sku,
      name: p.name,
      inStock: p.stock_status === "IN_STOCK",
      price: p.price_range.minimum_price.final_price, // guest price, see below
    }));
    return {
      content: [{ type: "text", text: JSON.stringify(items) }],
      structuredContent: { items },
    };
  },
);

留意 Store: "default" 和 guest price：这里返回默认视图的访客价格。另外，描述写了查询有货商品，代码却只是返回 inStock 标记，没有过滤缺货商品。它是架构示意，直接上线前还得补齐契约与实现的一致性。

agent 报错价格，可能同时踩中三种边界

第一种是数据过期。ACCS 或使用 Catalog Service、Live Search 的商店，数据会经过 Mview 变更日志、feed indexer、字段收集、内容哈希、HTTP POST 批量上报，再进入 SaaS 服务；失败后由 cron 重试。

indexer_update_all_views 每分钟运行，不等于一分钟内端到端同步完成。Adobe 没给出这一保证；完整 saas:resync 的文档耗时是几分钟到几小时。

原文还引用了具体修复：2026 年 7 月 6 日发布的 SaaS Data Export 103.4.29，修复了 UTC 以西时区网站在 UTC 凌晨发送原价、没有发送目录规则价的问题；103.2.4 修复过启用 Inventory Management 时的错误库存状态，103.4.8 修复过错误的 lowStock=true。

第二种是身份缺失。Magento 价格受 website、客户组、目录规则和阶梯价影响。Commerce Optimizer 的 STATIC 策略始终作用于目录视图，TRIGGER 策略则需要请求头指定触发条件。匿名 agent 通常只能拿到访客价，B2B 买家看到的合同价未必相同。

要支持客户价格，需要把 OAuth 认证的 MCP 会话映射到客户，再把身份上下文传入 GraphQL。原文明确说，Adobe 尚未公开这部分方案。

第三种是商品文字越过数据边界。描述、评论和卖家文案会进入模型上下文，其中可能夹带「使用优惠码可打五折」之类诱导指令，形成间接提示注入（indirect prompt injection）。

作者因此只返回 SKU、名称、库存和价格，建议把第三方文本放进独立工具。结构化输出也能减少价格转述失真，例如把 $44.99 说成「约 $40」；但 structuredContent、outputSchema 和文本分隔都不是彻底消除注入的保证。

写入权限不能押在客户端确认上

readOnlyHint、destructiveHint 是工具注解。原文引用的 MCP 规范要求客户端谨慎信任这些提示，而让人能够拒绝调用属于 SHOULD。商家无法据此假定每个购物客户端都会认真确认。

因此，约束需要落在服务端：购物车写入限制单次数量，使用幂等键防止重试重复加购；优惠码入口要控制尝试范围，不能把任意字符串输入变成批量猜码接口；下单则通过 ACP 等机制交接受限支付凭证，不让模型拿着保存的银行卡和自由生成的地址直接提交。

部署类型也影响路线。原文建议 ACCS 用户等待官方 server，同时整理目录视图、策略、属性和文案。PaaS、自托管 Magento 或 Magento Open Source 用户，则不能假设自己会免费获得同等能力。

替代路线包括通过公开 storefront GraphQL 工作的 mage-os-mcp，支持 Magento 2.4+ 或 Mage-OS，以及商业扩展或自建只读服务。该项目 README 也提醒，place_order 不可逆，应先确认总额。

我的判断

作者说得最有价值的是：agent 接口的正确性，取决于数据、身份和执行约束能否一起成立。

前端显示错价，用户可能在下一页发现；agent 会把错价组织成一句可信的回答。因此，价格附带同步时间、加购时重新计价、明确访客身份，都比先开放更多工具更实际。

但这篇不是接入实测报告。协议变更、版本修复和文档状态有材料支撑；「先只读、后交易」属于作者的工程取舍，没有成功率、转化率或成本对照数据。不能据此断言所有团队都应把购物车永久留在 MCP 之外。

代码也需要继续审查：它没有声明 outputSchema，没有处理 GraphQL 错误，而且名称本身仍可能来自第三方。相比已有 GraphQL 前端，新增 MCP 层带来的主要工作，是管理不可控消费者的行为，包装查询只是其中一小段。

能拿来做什么

• 给现有 Node 商品查询服务增加 MCP 入口时，先限定只读字段，并让工具描述、实际筛选条件和返回结构保持一致。
• 把价格上下文写进接口契约，明确店铺视图、访客或客户身份、同步时间，以及加购时重新计价的规则。
• 为工具改名、参数嵌套和购物车替换语义建立兼容性检查，同时记录调用方提供的 agent 身份，便于追踪迁移影响。
• 开放写入前先落实数量限制、幂等键和支付交接；商品描述、评论等外部文本应单独设计返回边界。