OpenAI has added support for WebMCP to the built-in browser inside its ChatGPT desktop app, as well as to ChatGPT Sites, according to Nekuda. When ChatGPT or Codex lands on a compatible page, the agent can call the actions that page has explicitly published rather than clicking through menus meant for a human eye.
The distinction matters because most agentic browsing today is imitation. An agent reads the rendered page, opens a filter, checks a box, and guesses at the next control, the same motions a person would make. Nekuda’s account describes this as workable but slow, error-prone, and invisible to the site owner, who has no clean record of what an automated visitor actually did. WebMCP, an open specification tracked on GitHub by the Web Machine Learning group, gives a site an alternative: publish a structured list of callable actions, such as searching a catalog, checking stock, or starting a checkout, and let the agent invoke those directly.
Nekuda frames the shipping detail as an addition, not a replacement. The in-app browser inside ChatGPT’s Chat, Work, and Codex surfaces still exists for sites that expose nothing, and the agent falls back to reading and clicking there. What changes on a WebMCP-enabled site is that the agent skips the interpretation step and calls a function the site’s own developers wrote and scoped, including which actions require a confirmation step before they execute.
Nekuda also reports two adjacent moves from OpenAI on the same day: ChatGPT Work gaining the ability to log into services on a user’s behalf inside the browser, and the ChatGPT extension expanding beyond Chrome to Edge, Brave, Opera, and Vivaldi. Sam Altman reposted the login-capable browser announcement, which Nekuda cites as a signal of how OpenAI is weighting the launch internally. None of these three items comes with usage figures or a rollout timeline in the material reviewed here.
Nekuda’s own history with this beat is worth naming as context, not as independent confirmation: the outlet has previously reported Google adding an agentic-browsing category to Lighthouse in May and Cloudflare shipping WebMCP-adjacent infrastructure earlier this month. Those were supply-side moves, tools that make it easier for a site to publish actions. This is the demand side arriving: a mainstream agent surface large enough to make publishing those actions worth a product team’s time.
That pairing is the actual news for anyone who runs a website rather than a lab. A site with no declared tools is read by an agent the slow, error-prone way described above; a site with a WebMCP manifest gets treated as a set of callable functions instead of a page to be interpreted. That changes what a site’s engineering team has to test before shipping a redesign: not just how a page renders, but what happens when an agent calls checkout or booking without a human confirming each intermediate screen. A cart action that silently succeeds without surfacing what was added, or a search tool that can’t also check availability, produces a completed call and a customer who still doesn’t have what they wanted.
Site owners evaluating this now have two separate journeys to design for, not one: an agent acting fully on a customer’s behalf, and a person browsing alongside their own agent in real time. Teams shipping consumer-facing checkout or booking flows should treat a WebMCP tool audit, covering confirmation boundaries and state visibility, as a required step before the next redesign ships, not an optional add-on for later.
Reported by Nekuda on 26 August 2026.
