A-开发者指南：如何使用WebMCP这一尚未被广泛采用的标准化技术

@mcp-b/global这个polyfill库填补了这一技术空白。它实现了provideContext()机制，在Chrome 146 Canary及以上版本中可以正常使用，而在其他浏览器中则会默默地降级使用，而不会引发任何错误或影响用户体验。

以下是src/lib/webmcp.ts文件的核心代码，总共有146行：


// src/lib/webmcp.ts
// 为chudi.dev提供WebMCP兼容性支持
// 规范：W3C社区组草案（预生产阶段）
// 兼容性实现：@mcp-b/global（遵循navigator.modelContext.provideContext规范）

try {
await ctx.provideContext({
name: 'chudi-dev',
description: 'chudi.dev的内容与相关信息——AI技术应用与智能Web架构设计',
tools
});
} catch (e) {
//默默忽略错误；因为规范可能还在修改中
console.debug('[webmcp] provideContext失败：', e);
}
}


这些工具被设计为仅支持读操作。不支持任何写操作，也不涉及身份验证或会话状态的管理。相关规范并未规定这一层需要进行身份验证，而我也不想发布一个可能会为这个仍在发展中的标准带来安全风险的产品。

我在 SvelteKit 的布局加载函数中调用了 `initWebMCP()` 函数，并传入了 `posts` 数组：

// src/routes/+layout.ts
import { initWebMCP } from '$lib/webmcp';
import type { LayoutLoad } from './$types';

export const load: LayoutLoad = async ({ fetch }) => {
  const res = await fetch('/api/posts');
  const posts = await res.json();

  // 非阻塞操作；仅在浏览器环境中执行
  initWebMCP(posts);

  return { posts };
};

这种设计实现了清晰的职责分离：布局模块并不需要关心 WebMCP 操作是否成功完成；而 polyfill 代码要么会添加相应的功能，要么就不会进行任何操作。

实验 2：citability.dev（Next.js，manifest 方式）

我的第二个网站 citability.dev 需要采用不同的实现方式。这是一个拥有真实 API 的产品，因此如果 WebMCP 真正被应用到生产环境中，我希望 citability.dev 能够被 AI 代理直接调用。

对于这个网站，我选择了使用 `.well-known/webmcp` 这种 manifest 路由方式，而不是使用 polyfill 代码。随着相关规范的不断完善，manifest 方式更符合服务器端 MCP 发现机制的预期工作方式。

manifest 文件保存在 public/.well-known/webmcp 目录下：

{
  "name": "citability",
  "version": "1.0.0",
  "description": "用于检测网站被 AI 引用情况的工具。通过扫描可以了解 ChatGPT、Claude 和 Perplexity 等模型多久会引用一次您的网站。",
  "tools": [
    {
      "name": "run_citability_scan",
      "description": "为某个网站免费进行引用率检测。该操作会检查在 20 条测试查询中，ChatGPT、Claude 和 Perplexity 等模型会多频繁地引用该网站。",
      "inputSchema": {
        "type": "object",
        "properties": {
          "domain": {
            "type": "string",
            "description": "需要检测的网站域名，例如 example.com"
          }
        },
        "required": ["domain"]
      },
      "endpoint": "/api/scan",
      "method": "POST",
      "pricing": {
        "type": "free",
        "cost": 0
      }
    },
    {
      "name": "request_audit",
      "description": "申请一次全面的引用检测服务，会得到详细的改进建议。系统还会返回对应等级的 Stripe 结账链接。",
      "inputSchema": {
        "type": "object",
        "properties": {
          "domain": {
            "type": "string",
            "description": "需要检测的网站域名"
          },
          "tier": {
            "type": "string",
            "enum": ["starter", "growth", "authority"],
            "description": "检测服务的等级"
          }
        },
        "required": ["domain", "tier"]
      },
      "endpoint": "/api/audit/request",
      "method": "POST"
    },
    {
      "name": "get_audit_result",
      "description": "根据审计 ID 查取检测结果。",
      "inputSchema": {
        "type": "object",
        "properties": {
          "audit_id": {
            "type": "string"
          }
        },
        "required": ["audit_id"]
      },
      "endpoint": "/api/audit/{audit_id}",
      "method": "GET"
    },
    {
      "name": "list_audit_tiers",
      "description": "列出所有可用的引用检测服务等级，包括价格和功能详情。",
      "inputSchema": {
        "type": "object",
        "properties": {}
      },
      "endpoint": "/api/tiers",
      "method": "GET"
    }
  ]
}

我还将citability.dev的A2A AgentCard发布到了.well-known/agent.json文件中：

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "citability",
  "url": "https://citability.dev",
  "description": "用于检测并提升您在ChatGPT、Perplexity和Claude等平台上的AI引用率。",
  "applicationCategory": "DeveloperApplication",
  "featureList": [
    "AI引用率检测功能",
    "针对不同AI引擎的详细分析结果",
    "提高引用率的建议",
    "包含可操作修复方案的审计报告"
  ],
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD",
    "description": "可免费进行检测"
  },
  "provider": {
    "@type": "Person",
    "name": "Chudi Nnorukam",
    "url": "https://chudi.dev"
  }
}

通过发布citability.dev的A2A AgentCard，我加入了那0.0081%已经发布了该工具的域名行列。其实这个群体并不大。

从发布别人没有的东西中我学到了什么

我原本以为会遇到这样的情况：没有任何代理请求，日志中也看不到任何有用的信息，只是一个功能简单但毫无实际效果的实现版本。

但实际上发生的情况是这样的。我在2026年2月23日发布了chudi.dev的WebMCP工具。在之后的93天内，没有任何一个外部AI代理调用过searchPosts、listPosts或getAuthorContext这些接口。真的一个都没有。到了5月22日，我又发布了citability.dev的.well-known/webmcp资源文件，其中包含了四个可供生产环境使用的工具，还包括一个免费的检测端点。在随后的五天内，仍然没有任何代理调用过run_citability_scan这个接口。Vercel提供的边缘函数调用日志清楚地显示了当时的访问情况：只有人类浏览器、Googlebot在爬取页面内容，以及ClaudeBot和GPTBot也在进行同样的操作。根本没有人使用过WebMCP工具。

这种没有收到任何反馈的结果，实际上才是这次实验中最有意义的部分。

目前使用的polyfill实现方式（.provideContext()）并不是最终的规范。Chrome 146 Canary版本的实现使用了与polyfill不同的方法签名，这意味着目前还没有任何生产环境中的浏览器能够完全执行我发布的代码。因此，这个polyfill功能实际上是在默默地失效。我的工具已经准备好了，但还没有人真正使用它们。

这并不算失败。在规范尚未稳定的阶段，这种情况正是“先发优势”应该呈现的样子。

我想在这里明确说明，“定位”到底意味着什么，因为这不仅仅是一个营销术语而已。

当某种技术规范开始被应用到生产环境中的浏览器中时，那些实现了该规范的网站会通过最先出现的那种索引机制被纳入搜索索引系统。以2009年的robots.txt文件为例，早期采用这种文件的网站已经制定了相应的爬取规则，而此时谷歌的搜索引擎机器人还未改变它们的行为模式；对于2010年的Open Graph标准来说，那些包含了正确元数据的页面在这一标准被广泛理解之前，就已经能够显示更丰富的预览内容了；至于2027年的WebMCP技术规范，一旦它开始被实际应用，那些配备了相应工具配置的网站就会立即被那些实现了该规范的智能系统所识别并进行处理。

另一种选择是等待以后再实施。但在这种情况下，“以后”意味着要和其他人同时进行实施，而到那时基础设施带来的优势就已经消失了。

还有另一个好处：你可以在规范还处于可修改阶段时学习这些内容。

W3C社区小组制定的草案发生了一些我未曾预料到的变化。规范中规定的registerTool()方法与provideContext()的实现方式并不一致，而且manifest文件的存放位置(/.well-known/webmcp)也尚未被确定为标准格式。WebMCP层面的认证机制至今仍未得到解决。由于我提前进行了部署，因此已经遇到了其中两个问题，并对此做出了相应的调整。

真正让我感到惊讶的部分：当前这种采用曲线意味着什么

再回到那张数据表，看看曲线的拐点在哪里。

所有位于双线以上的内容（从robots.txt到OAuth discovery）都代表了实际的采用情况。许多网站都在实际使用这些技术。即使是在那一组中占比较低的选项，比如Markdown协议的采用率为5.3%，OAuth discovery的采用率为5.2%，也意味着有成千上万的域名正在主动向AI代理提供关于自己内容或身份的结构化信息。

而所有位于双线以下的内容，其采用率基本上都为零——甚至不是个位数的低比例，而是真正的零或者接近零。

这并不是一条直线，而是一道悬崖。这道悬崖几乎精确地反映了“被动信号”与“主动能力”之间的区别。

被动信号包括robots.txt、ai.txt、站点地图、链接头信息以及内容相关信号。这些信号只是告诉AI代理你拥有什么资源，以及你是否允许它们使用这些资源。

而主动能力则包括WebMCP、A2A Agent Cards、x402支付协议以及ACP等。这些技术能够让AI代理知道他们可以使用你的基础设施来做什么。

之所以会出现这道“悬崖”，并不是因为开发者不了解这些主动能力的相关标准，而是因为这些标准本身还不够稳定。如果规范在实施过程中发生了变化，那么你就无法发布一个会让你蒙受损失的支付协议。

不过需要注意的是，那些位于“悬崖”以上的标准也同样不稳定。robots.txt不断有新的扩展功能被添加进去，ai.txt/llms.txt的标准也在不断变化中。尽管如此，许多网站还是选择了使用这些技术，因为犯错的代价相对较低。

而对于WebMCP来说，如果使用不当，其带来的负面影响会更大。但是，在仅用于读取数据的场景下，你完全有可能正确地使用它。有三种工具可以让AI搜索你的内容，并获取关于你身份的结构化信息，但这些工具的适用范围几乎为零。如果规范发生了变化，你只需要修改146行代码，然后重新部署即可。

提前实施的成本非常低，而延迟实施的后果虽然尚不清楚，但很可能是严重的。

今天如何开始使用WebMCP（完整的实施路径）

如果你想自己动手实现这个功能，以下就是我具体遵循的步骤。

步骤1：安装相应的polyfill插件（适用于基于SvelteKit或Vite的项目）

npm install @mcp-b/global

对于 Next.js 来说，使用清单文件的方法比使用polyfill更加简洁：

# 不需要安装任何 npm 包；只需创建清单文件即可
mkdir -p public/.well-known
touch public/.well-known/webmcp

步骤 2：首先将你的工具设置为只读模式

在开始任何操作之前，先确定你希望让 AI 工具能够查询哪些结构化数据。可以先从以下功能入手：

• 搜索工具（接收查询请求并返回匹配结果）

• 列表工具（返回最新或相关的条目）

• 上下文工具（提供关于你的网站或产品的结构化元数据）

不要一开始就尝试写入操作。相关规范并没有规定这一层需要进行身份验证；只读工具本身也不会带来任何安全风险。

步骤 3：集成 SvelteKit 的 polyfill 功能

根据上述模式创建文件 src/lib/webmcp.ts。其中需要检查的关键代码如下：

if (!browser) return;                          // 防止在服务器端渲染时出现错误
const ctx = (navigator as any).modelContext;
if (!ctx?.provideContext) return;              // 防止在非 Canary 版本的浏览器中出现问题

这两项检查都是必不可少的。如果忽略了 browser 的判断，那么在服务器端渲染时就会抛出 ReferenceError: navigator is not defined 错误；如果忽略了 provideContext 的判断，那么在任何没有实现 modelContext 功能的浏览器中都会出现错误。

步骤 4：使用 Next.js 的清单文件方法

创建文件 public/.well-known/webmcp（该文件不需要扩展名，其内容应以 application/json 格式提供），并将你的工具定义信息填充到其中。在发送请求时需要设置正确的 Content-Type：

// app/api/well-known/webmcp/route.ts
import { NextResponse } from 'next/server';

export async function GET() {
  const manifest = {
    name: 'your-site',
    version: '1.0.0',
    description: 'Your site provides the following services.',
    tools: [
      // Your tool definitions here
    ]
  };

  return NextResponse.json(manifest, {
    headers: {
      'Access-Control-Allow-Origin': '*',
      'Cache-Control': 'public, max-age=86400'
    }
  });
}

CORS 头部信息非常重要。在浏览器环境中运行的 AI 工具会从与你的网站不同的来源地址访问这个端点。

步骤 5：添加 A2A AgentCard

你已经在创建 .well-known 目录了。A2A AgentCard 只需要 20 行 JSON 代码，就能让你的网站在被扫描的域名中排名前 0.0081%。既然已经开始了这个过程，就一定要添加它，这样才能确保你的网站获得更好的排名。

步骤 6：在 Chrome Canary 中进行测试

下载 Chrome 146 及更高版本的 Canary 版本。打开你的网站，然后打开 DevTools 的 Console 标签页，运行相应的测试命令。

navigator.modelContext?.provideContext

如果兼容性解决方案已经加载成功，你就会看到相应的功能。但如果它返回undefined，那就说明该解决方案没有成功加载（请检查你的初始化代码），或者你使用的并不是兼容版本。

目前还没有任何正式发布的AI代理会使用这些工具。你现在所做的只是在测试基础设施是否已经准备就绪，而不是验证它们是否已经被实际应用。

“为什么现在要费心去做这件事”的实际答案

每当我向开发者介绍这个项目时，他们都会问同一个问题：既然等到2027年浏览器才能原生支持这些功能，而且相关规范也会变得稳定，那么现在发布这些东西意义何在呢？

这个问题的答案分为三个部分。

首先，目前的开发成本很低。我实现的chudi.dev项目仅包含146行代码；citability.dev项目的配置文件也只有60行JSON代码以及一个Next.js路由配置。这并不是一个需要经过多个开发阶段的复杂项目。如果相关规范发生了重大变化，我也只需要修改那146行代码而已。

其次，学习效应会逐渐累积。目前这些相关规范还处于发展阶段，阅读有关WebMCP的文档并实际进行开发是两回事。在实现之后，我会遇到很多问题，比如registerTool()和provideContext()之间的区别、跨源请求时数据是如何被检索到的、当两个工具的名字相同时会发生什么等等。而这些问题，如果只是单纯阅读规范文件是无法了解的。在2027年之前掌握这些知识是非常有必要的。