AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
The following article originally appeared on the Agentic AI Foundation blog and is being reposted here with the author’s permission. Websites are designed for people. We can look at a page and quickly understand where to enter information or which control will complete an action. AI agents don’t see or use the web the same way we do. An agent may have to process a screenshot or inspect the page’s underlying structure, then reason about which control matches the request. The additional context increases token use, and each interpretation step creates another chance for error. WebMCP (not to be confused with MCP) gives web developers a standard way to publish structured tools to access the capabilities of their website enabling agents to call those functions with structured inputs. A developer can register a tool through document.modelContext and give it a name and description. The tool also defines an input schema and the function that runs when an agent calls it. For example, an article site could publish a search tool that calls the same application code as its visible search form. const searchToolController = new AbortController(); await document.modelContext.registerTool( { name: "search-articles", title: "Search articles", description: "Search published articles by topic.", inputSchema: { type: "object", properties: { query: { type: "string", description: "The topic or phrase to search for." } }, required: ["query"], additionalProperties: false }, async execute({ query }) { const articles = await searchArticles(query); renderSearchResults(articles); return { articles }; } }, { signal: searchToolController.signal } ); // Call this when the search tool should no longer be available. // searchToolController.abort(); The name and description tell the agent when to use the tool. The input schema defines the arguments it can send. The execute function calls the site’s existing search logic and updates the page with the results. The browser makes the registered tool available to a supported agent while the page is active. When the agent calls it, the browser passes the structured arguments to execute and returns the result. When the search tool should no longer be available, the page can unregister it by calling searchToolController.abort(). A page registers tools that match its current state. A content view may provide a search tool, while an editor can provide tools for changing the selected content. The agent then discovers the tools available for the page’s current state. WebMCP also proposes a declarative path for existing HTML forms. The article search could be exposed through attributes on the form itself. The browser uses the form attributes and controls to create the tool definition. Because the form omits toolautosubmit, the browser populates the field but leaves the final click to the person. The person can review the search query and click the Search button. Keep the person and agent in the same interface A WebMCP tool uses the state already visible in the application and the person’s active session. The shared page gives the person a place to review the agent’s work. When the agent completes an action, the person can see the updated state and make changes through the normal interface. Web developers can also reuse application logic that already handles the visible interface. OpenAI’s Runme example is a browser application that registers tools for reading instructions and updating notebook content. Runme can offer those functions through the page without adding a separate server only to expose an MCP endpoint. Pair WebMCP with MCP WebMCP and MCP both expose tools to agents, but they operate in different parts of an application. Understanding the difference helps developers decide where each one fits and how they can work together. An MCP server can provide tools when no related page is open. A WebMCP tool is attached to the current document and can use the page’s current state. WebMCP standardizes how a page registers tools with the browser. The browser can present those tools to its agent through MCP or another function calling mechanism. MCP Apps address another part of the interaction. An MCP server can provide an interactive interface that a compatible host displays to a person. WebMCP lets an agent use functions from an existing website. WebMCP and MCP Apps can work together. For example, a shopping website could publish a compare_products tool through WebMCP. An MCP server could provide an MCP App for the comparison, so the person can adjust the options while the agent handles the supporting work. The comparison interface could also be described with A2UI, which lets an agent describe an interface in a declarative format. The client renders the description with components from its own design system, so the client controls which components are available and how they behave. People and agents can use the same interface at the same time. Developers need to decide which functions the agent can call and what the person should see while those functions run. Design the page for agent use Agent use begins before the first click. An agent may need to discover the website and determine how to authenticate. It may choose an API or structured documentation before opening a browser. Web teams should study how agents use their site before deciding which interface to add. Check the server logs to see whether agents are crawling HTML or requesting machine readable content. Tool activity can reveal which WebMCP functions agents discover and which calls they abandon. Keep existing controls in the execution path WebMCP reduces the amount of interface interpretation an agent has to do, but a structured tool is still an entry point into the application. The website should apply its existing access controls and input validation whenever the tool runs. For example, an update_cart tool can accept a product identifier and quantity. The server should confirm that the product exists and that the current user can modify the cart. Structured input doesn’t automatically make the request trusted, so the server should run the same checks it uses for updates made through the website. The browser also has a responsibility. OpenAI reviews each site tool call before it runs and asks the person to confirm sensitive actions. The WebMCP draft requires origin isolation, and its tools permissions policy allows same origin use by default. Clients need to handle tool changes during a task. A page can change a tool’s identity or schema after the agent begins working, so the client should review the tool again before using the new definition. Researchers are already testing those boundaries. A June preprint on WebMCP tool surface poisoning found that changes to tool registration and metadata could redirect agents in its test environment. The researchers used a polyfill and a headless agent, so a native browser implementation may behave differently. But these reported attacks can serve as great test cases as you’re adding WebMCP to your site. Test WebMCP while the design is open WebMCP already has several experimental implementations. Chrome offers an implementation through a flag and an origin trial. Sarah Drasner created an interactive WebMCP demo of this implementation that you can try in your browser. Cloudflare released a developer preview that can add a WebMCP bridge to a website, and Brave has tested WebMCP with its Leo assistant. Testing WebMCP against varied applications can reveal assumptions in the current draft. For example, a form may need a declarative feature that has not been specified yet. Also, look for lifecycle problems when a website changes its tools during a task. Bring your findings back to the WebMCP issue tracker.