# WebMCP 的两种接入方式

<div class="grid grid-cols-2 gap-6 mt-7">

<div class="card-blue">
<div class="font-semibold mb-3">声明式：增强表单语义</div>

```html
<form tool-description="提交酒店筛选条件">
  <input
    name="city"
    tool-parameter-description="目的地城市" />
</form>
```

<div class="text-xs op-65 mt-3">适合已有 HTML 表单和渐进增强。</div>
</div>

<div class="card-green">
<div class="font-semibold mb-3">命令式：注册业务工具</div>

```ts
document.modelContext.registerTool({
  name: 'create_order_menu',
  description: '创建订单管理菜单',
  inputSchema,
  execute: createOrderMenu,
})
```

<div class="text-xs op-65 mt-3">适合复杂业务动作和后台系统。</div>
</div>

</div>

<div class="mt-7 card-amber text-sm">
WebMCP 仍属于实验性方向，实际接入要做能力检测、渐进增强和人工确认。
</div>

<!--
这一页讲 WebMCP 怎么接入。

从公开资料和演示里可以看到，WebMCP 的接入大体可以分成两个方向。第一种是声明式接入，也就是在已有 HTML 表单上补充工具描述和参数描述。这样 Agent 不只是看到一个 input，而是知道这个 input 对应什么业务含义。例如这个字段不是普通文本框，而是“目的地城市”；这个表单不是普通表单，而是“提交酒店筛选条件”。

第二种是命令式接入，也就是通过 JavaScript 注册工具。工具里会包含 name、description、input schema 和 execute 函数。Agent 根据用户意图选择工具，传入结构化参数，然后页面执行我们已经定义好的业务逻辑。对复杂应用来说，这个方式更像是把现有业务函数安全地暴露给 Agent。

对高级前端来说，这个区别很关键。声明式方式适合增强已有表单，成本低，和语义化 HTML 的方向一致；命令式方式适合后台系统、复杂流程、跨页面业务，因为它可以复用已有的 service、store、接口封装和权限判断。也就是说，我们不一定要重写一套 AI 专用逻辑，而是把原有能力以更清晰的 schema 暴露出来。

但这里一定要提醒大家：WebMCP 仍然是实验性和快速演进中的方向，不能把它当成所有浏览器都稳定支持的能力。真正落地时，第一要做 feature detection，也就是先判断环境是否支持；第二要做渐进增强，不支持时仍然回到正常 UI 流程；第三，高风险动作必须有人类确认，不能让 Agent 自动越过权限、审计和确认边界。

讲到这里，我们已经有工具了。但真实任务往往不是一个工具就能完成，所以下一页要补一个实践层问题：复杂任务需要流程说明。
-->