面向制造商的 MCP 实践指南

用大白话说，MCP 是什么？

Model Context Protocol（模型上下文协议）是一套标准化的做法，让 AI 助手能够调用别人的系统，并拿回带类型、有结构的答案。

Anthropic 于 2024 年 11 月 25 日将其开源，称之为“一套把 AI 助手连接到数据所在系统的新标准”。2025 年 12 月 9 日，Anthropic 把 MCP 捐赠给 Agentic AI Foundation——这是 Linux Foundation 旗下的一支定向基金，由 Anthropic 与 Block、OpenAI 共同发起，AWS、Bloomberg、Cloudflare、Google 和 Microsoft 以白金级别提供支持。到那时，MCP 的 SDK 月下载量已超过 9,700 万次，公开发布的服务器超过 10,000 台，并在 ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot 和 VS Code 中获得一流的客户端支持。

对不写代码的决策者来说，真正要紧的区别是这样的：助手读取你的网站时，它是在解读一份文档——它可能看错表格、漏掉脚注，或者把两个型号变体混为一谈。助手调用你的 MCP 服务器时，它是在查询一个系统——它请求某个零件，接收字段，然后如实报告。前一种方式产出的是听上去合理的答案，后一种产出的是正确的答案——前提是背后的数据本身没错，而这恰恰是大部分真功夫所在。

这个行业里，已经有谁上线了？

这件事早已不再停留在设想阶段，而且现有案例的类型相当有参考价值：

• Microchip Technology 于 2025 年 11 月 6 日上线了一台免费的公开 MCP 服务器，通过 MCP Streamable HTTP 对外提供经过核验的产品规格、数据手册、库存、价格与交期，响应以 JSON 编码，面向各类 copilot、聊天机器人和企业智能体。
• Siemens 在 mcp.siemens.com 运行着一台公开服务器，其文档中列出的插件——资产、开发者门户、搜索与网页内容——无需身份认证即可使用。
• Zoovu 于 2025 年 12 月 11 日推出 MCP 服务器，让智能体在受治理的前提下访问产品数据，其定位就落在兼容性与应用场景类问题的回答准确度上。
• ECIA 于 2026 年 6 月 11 日推出 TrustedParts.com Inventory AI Agent Service，把授权渠道的电子元器件库存直接送进 Microsoft Copilot、ChatGPT 和 Claude。
• Shopify 为店铺提供 Storefront MCP 服务器，地址形如 https://{shop}.myshopify.com/api/mcp，工具包括 search_catalog、lookup_catalog 和 get_product，storefront 这一层无需认证。

有两点规律值得留意。上述每一个案例，都建立在一套已有的权威数据源之上。而且每一个案例，都在公开目录数据与任何涉及商业敏感的信息之间划出了一条清晰的界线。

工具还是资源——零件服务器该用哪一种？

规范对二者的区别写得很明确，一旦搞反，做出来的服务器模型就用不顺手。

工具由模型控制。 规范写道，工具“被设计为由模型控制，即语言模型可以基于自身对上下文的理解和用户的提示，自动发现并调用工具”。发现用 tools/list，调用用 tools/call。每个工具都带有一个 inputSchema（默认采用 JSON Schema 2020-12）、一个可选的 outputSchema，并返回符合该 schema 的 structuredContent。

资源由应用驱动。 规范写道，资源“被设计为由应用驱动，由宿主应用根据自身需要决定如何纳入上下文”——通常表现为一个选择器、一份列表，或由宿主自动纳入。每个资源以一个 URI 标识，模板则支持带参数的 URI。

产品目录是一个查询空间，而不是一份固定的文档清单。没有人愿意在一个装着 4 万个零件的资源选择器里一路下拉。因此，零件服务器的主体应当是工具，另加两点讲究：用 resource_link 内容块指向数据手册和 CAD 文件，而不要把大体积内容内联进来；把真正意义上的资源，留给分类字典或变更日志这类少数几份稳定文档。

现行规范里有两个细节值得琢磨。工具列表不得因连接而异，但可以随请求所出示的授权而变化。另外，服务器应当以确定的顺序返回工具，因为稳定的排序能让客户端缓存这份列表，并提高提示词缓存的命中率。

2026-07-28 规范改了什么？

这一版重塑了传输层，任何依据 2025 年资料写成的设计方案，都会在几个具体的地方出错。

如今的传输形态平淡得让人舒心。服务器只暴露一个接受 POST 的 MCP 端点，例如 https://example.com/mcp。每一次 JSON-RPC 请求都是一次独立的 POST。客户端必须发送 Accept 请求头，同时列出 application/json 与 text/event-stream，并附带 MCP-Protocol-Version 请求头；该值必须与请求体 _meta 中的值一致，否则服务器必须以 400 和 HeaderMismatch 错误予以拒绝。服务器必须校验 Origin 请求头，若该头存在且无效，则返回 403。

这对基础设施团队的实际影响是：由于协议层不再有会话，你的 MCP 服务器可以像任何其他无状态 HTTP 服务一样，部署在一台普通的轮询负载均衡器之后。Roots、Sampling 和 Logging 现已弃用，过渡期至少十二个月；旧的 HTTP+SSE 传输方式也已正式弃用。

如何用 OAuth 守住价格与库存？

在 MCP 中，授权是可选的，这一点对零件服务器来说恰到好处：公开目录完全不该需要任何令牌，只有涉及商业敏感的工具才应该发起认证质询。

真要实现时，要求写得很具体。MCP 服务器充当 OAuth 2.1 资源服务器，遵循 OAuth 2.1 的 IETF 草案。它必须实现受保护资源元数据（Protected Resource Metadata，RFC 9728），客户端必须依据这份元数据来发现授权服务器。客户端必须实现资源指示符（Resource Indicators，RFC 8707），在授权请求和令牌请求中都发送一个标识你规范服务器 URI 的 resource 参数；而你的服务器必须校验令牌确实是以它为目标受众而签发的。授权服务器应当按 RFC 9207 返回 iss 参数，客户端必须对其加以校验。动态客户端注册（Dynamic Client Registration）现已弃用，取而代之的是客户端 ID 元数据文档（Client ID Metadata Documents），但出于向后兼容仍可继续使用。

对分销商或制造商行之有效的模式是：

1. 01免认证层——规格参数、参数化检索、替代料、合规文件、CAD 链接，以及你本就公开的目录价。
2. 02需认证层——合同价、客户专属可供量、报价创建。以 403 加 error="insufficient_scope" 发起质询，并写明所需的 scope，让客户端一个来回就能完成权限升级，而不必反复试探。
3. 03绝不要把客户标识写进工具参数，并以此作为唯一的访问控制手段。句柄只是一个名字，不是一种权限；每一次调用都要校验授权。

一台零件 MCP 服务器应该暴露什么？

六到八个工具是合适的量级。再多，模型的工具选择就会变差。

一份工具定义看上去应该平平无奇，而这正是重点所在：

{
  "name": "search_parts",
  "title": "Parametric part search",
  "description": "Search the catalog by product class and typed parameter constraints. Returns matching parts with their key parametrics, units and last-verified date. Use get_part for the full record.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "product_class": { "type": "string", "description": "ETIM class code or class name" },
      "constraints": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "parameter": { "type": "string" },
            "operator": { "type": "string", "enum": ["eq", "gte", "lte", "between", "in"] },
            "value": {},
            "unit": { "type": "string" }
          },
          "required": ["parameter", "operator", "value"]
        }
      },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["product_class"],
    "additionalProperties": false
  }
}

留意这段描述做了什么：它既告诉模型这个工具会返回什么，也告诉模型什么时候该换用另一个工具。仅这一个习惯，对答案质量的提升就胜过在 schema 上反复打磨。

一个完整的实例

美国得州一家代工厂的设计工程师，正要为一块电路板更换一颗停产的元器件，而这块板子同时还要供给德国的一家成套设备厂。这位工程师的助手已经连上了这家制造商的 MCP 服务器。

工程师： 我们降压级里那颗 60 V N 沟道 MOSFET 要停产了。我需要一颗同封装的直接替代料，10 V 栅极驱动下 R_DS(on) 不高于 12 毫欧，而且我要知道它到底有没有货。

助手发起了四次调用。

→ tools/call  get_part
   { "part_number": "XYZ-60N12-D2PAK" }
← structuredContent
   { "package": "D2PAK", "vds_v": 60, "rds_on_mohm": 11.5,
     "vgs_meas_v": 10, "lifecycle": "EOL", "last_verified": "2026-08-04" }

→ tools/call  find_alternates
   { "part_number": "XYZ-60N12-D2PAK", "basis": "form_fit_function" }
← structuredContent
   [ { "part_number": "XYZ-60N10-D2PAK", "equivalence": "drop-in",
       "rds_on_mohm": 9.8, "differences": ["lower R_DS(on)", "higher Qg"] },
     { "part_number": "XYZ-60N14-D2PAK", "equivalence": "footprint",
       "rds_on_mohm": 13.5, "differences": ["exceeds R_DS(on) limit"] } ]

→ tools/call  get_availability
   { "part_numbers": ["XYZ-60N10-D2PAK"] }
← 403 Forbidden
   WWW-Authenticate: Bearer error="insufficient_scope",
     scope="stock:read", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

   [client performs step-up authorisation, then retries]

← structuredContent
   { "part_number": "XYZ-60N10-D2PAK",
     "stock": [ { "location": "US-TX", "qty": 14200 },
                { "location": "DE-BW", "qty": 3800 } ],
     "lead_time_weeks": 8, "as_of": "2026-08-09T06:12:00Z" }

→ tools/call  get_compliance_documents
   { "part_number": "XYZ-60N10-D2PAK", "types": ["rohs", "reach"] }
← content: [ { "type": "resource_link", "uri": "https://…/rohs-2026-03.pdf",
               "name": "RoHS declaration (issued 2026-03-11)" } ]

随后助手作答：第一个候选料是直接替代件，导通电阻更低但栅极电荷更高，值得对照栅极驱动器复核一下；第二个封装吻合，却没能满足 R_DS(on) 的上限；截至今天上午，得州有 14,200 颗、巴登-符腾堡有 3,800 颗库存，交期八周；RoHS 与 REACH 声明已随附，并标明各自的签发日期。

单从工程角度看，这里没有什么了不起的技术。了不起的是它作为一桩生意的意义。三项采购决策就此做成，全程没有人打开过浏览器，而且每一个数字都能回溯到一条带时间戳的记录。

今天究竟谁能连上你的服务器？

在这个问题上请对董事会实话实说，因为真实答案比大多数厂商宣传材料所暗示的要窄得多。

所以，MCP 能触达的是那些自己配置了助手的工程师，以及由 IT 部门帮忙注册了你服务器的企业采购方。按互联网流量的标准衡量，这是一个很小的人群；按销售管道的标准衡量，这是一个非常大的人群。

智能体怎样发现你的服务器？

并不存在 DNS 层面的发现机制。目前只有三种途径：

1. 01官方 MCP 注册表，位于 registry.modelcontextprotocol.io，它是面向公开可访问服务器的集中式元数据仓库，由 Anthropic、GitHub、Microsoft 和 PulseMCP 共同支持。它是开源的，支持子注册表，目前仍处于正式发布前的预览阶段——所以要做好它还会变动的准备。
2. 02客户端侧的目录，例如 Claude 的连接器目录和 ChatGPT 的应用目录，各自都有一套自己的审核流程。
3. 03你自己的文档。 今天绝大多数连接其实就是这么建立起来的：一个开发者页面写明端点 URL、工具清单和授权 scope，客户把它粘贴进自己的客户端。

即便大部分工具都是公开的，也请发布你的 .well-known/oauth-protected-resource 文档，并为端点路径加上版本号。你的工具面迟早会变，而你希望那是一次有计划的迁移，而不是一次悄无声息的中断。

实施清单

1. 01为每个零件归一出唯一的规范记录，带上有类型的属性、单位、数据来源和最后核验时间戳。不要一上来就从协议入手。
2. 02挑选六到八个工具，并在每个工具的描述里写清楚什么情况下不该用它。
3. 03声明输出 schema 并返回 structuredContent。每一份返回内容都要包含单位和核验日期。
4. 04只提供一个 POST 端点，正确处理 Mcp-Method 与 Mcp-Name 请求头，校验 Origin，并在列表结果上设置 ttlMs 和 cacheScope。
5. 05把公开工具与受控工具分开，实现 RFC 9728 元数据，按 RFC 8707 校验令牌受众，并用 scope 质询让权限升级在一个来回内完成。
6. 06以确定的顺序返回工具，并保持工具名称稳定，这样客户端缓存才能真正发挥作用。
7. 07记录每一次调用——工具、参数、延迟，以及这次查询是否命中。没有分析数据的 MCP 服务器，是一条你管不了的渠道。
8. 08持续对照事实基准监测准确率。一个信誓旦旦返回过期额定参数的工具，比没有这个工具更糟。

Partsgraph 以托管层的形式提供这一整套能力：我们把你现有的产品目录归一为一张经过核验的 Parts Graph，托管 MCP 端点并为受控层配置 OAuth，同时向你报告哪些智能体调用了什么、以及哪些答案出了错。

如果你想在动手写代码之前先摸清自己的现状，可以把你的域名交给 /audit 上的免费评分工具跑一遍——它会检查机器目前能从你的目录里读到什么，以及一个 MCP 端点是否真有可靠的内容可供输出。