Rebuilding the web for agents — Liad Yosef, MCP Apps

An agent can find hotels, but a person may still want to choose one. It can retrieve a 3D model, but someone needs to inspect it. Seat selection needs a view of the venue. These are the kinds of decisions MCP Apps is meant to support: an MCP server supplies an interactive interface inside an assistant’s conversation, so automation can lead into a useful human interaction.

Liad Yosef introduces himself as MCP Apps co-creator and maintainer, ORA co-founder, and someone who built and led agentic storefronts at Shopify. His starting point is that a chat host needs access to existing services. Hotel arrangements and customer support for changing a venue seat remain work that those businesses perform; an assistant does not gain those capabilities merely by presenting a conversational interface.

What the embedded interface preserves

The server sends a piece of the provider’s UI into the chat. Yosef describes three benefits of that arrangement:

• Provider identity: The service retains its recognizable interface rather than appearing only as text or database records.
• User familiarity: A Booking.com interface gives the person a familiar indication of which service they are interacting with. Yosef treats that recognition as a source of trust.
• Host capabilities: The assistant can offer access to services without recreating the businesses behind them.

Yosef calls this the last mile of interaction. As the agent takes on more of the preceding work, the remaining interface can focus on what the person needs to inspect or decide. His embedded-app example brings Booking and AllTrails into the same conversation: separate services contribute useful information and interaction while the chat keeps the task’s context together. The interface becomes a step within the task, rather than a reason to start over in another application.

Planning an anniversary exposes the coordination problem. A person opens tabs, learns Google’s interface, learns Amazon’s interface, learns Booking’s interface, and expresses parts of the same intent in each. Yosef describes two decades spent perfecting those individual flows. Even when each product works well, the person still has to connect them.

His proposed alternative breaks interfaces into useful atoms that a personal assistant can compose. A Google view establishes that the anniversary is approaching. Shopping and booking services provide ways to act on it. If Claude knows that the user prefers hotels in nature, it can select Booking’s map as the relevant interface. The assistant chooses which piece to bring into the conversation using both the task and the user’s preferences.

Yosef’s claim that he does not need 99% of Booking’s or Airbnb’s dashboard expresses the mismatch between a whole application and one task. The percentage is rhetorical, rather than a measured share of unused functionality. The concrete design move is to return the map or choice that matters now, leaving the rest of the dashboard out of the interaction.

The assistant carries the connections

In this anniversary scenario, Booking would not need to develop its own integration with the user’s calendar, and Amazon would not need to develop an integration with Booking. The assistant has the context and coordinates the service fragments. This is a proposed experience: the example explains where the integration work would live, without establishing that the complete anniversary flow already operates end to end.

Putting a separate agent-shaped text box on every website leaves much of the original coordination burden intact. The person still visits Amazon, Etsy, and Expedia and tells each assistant what they want. Yosef expects people to prefer the personal assistant that already knows them. His sharpest product preference is about continuity: the same assistant should carry the intent across services.

Browser and computer-use agents can operate the web that already exists. Yosef questions why that should be the default workflow. Filters, pagination, sorting, and dashboards were designed to help people navigate information under human perception constraints. Asking an agent to work through those controls keeps the same intermediate steps, even when the task could be expressed directly to the service. His faster-horse analogy challenges that choice of route.

WebMCP, as Yosef describes it, changes how an agent operates within a website. The website exposes JavaScript tools, allowing the agent to call those tools instead of taking screenshots and inferring what to do. His Gemini-and-Chrome example finds deals or buys things while the person browses. This provides a more direct way to act within the browsing experience.

The remaining question is whether the person should have to visit the website. Yosef uses Salesforce to make that objection concrete: opening a complex dashboard so an assistant can click buttons still makes the dashboard the destination. Exposing tools improves the agent’s access to actions; moving the task into a personal assistant changes where the user begins.

When the assistant becomes the entry point

Yosef’s friends who connect Jira’s MCP to their IDEs stop visiting Jira’s website. His mother already uses ChatGPT extensively; he imagines her booking a doctor’s appointment there instead of navigating a clinic’s site. During a trip to Georgia, he encounters a woman whose phone has three apps: WhatsApp, Camera, and ChatGPT. These anecdotes explain why an assistant might become a habitual starting point, although they do not measure how widely that change has spread.

Yosef initially predicts that websites and browsers will become obsolete, then qualifies the claim: they will not disappear completely. He points to Sentry’s Designing for Agents discussion as an example of product interaction expanding beyond a web application into API-first access. The supported design direction is that a website can remain useful while ceasing to be the mandatory path to a product.

Yosef describes Salesforce, Cloudflare, and Sentry as moving toward headless access. The architectural point is that agents can use product capabilities without navigating the full web application. How much interface should come back depends on the task: organizing email may end with a completion message, while booking a honeymoon hotel may require a person to inspect options and choose.

He calls this the nearly headless web. The agent interacts with the service headlessly, then returns selected UI resources when human interaction matters. Product experience consequently splits into two connected concerns: how the agent understands and operates the service, and how the person experiences what the agent brings back. MCP Apps addresses that second concern without requiring every intermediate action to become a screen.

Yosef predicts that 90% will depend on agent experience; that proportion is a forecast without a defined measurement in the talk. His more concrete requirement is to serve several kinds of users: the company’s own agent, a customer’s assistant such as ChatGPT, and a person who still visits the website directly. Agent access adds another way to use the product while human browsing remains a requirement.

Discovery is the beginning of a transaction

Getting found through SEO, AEO, or GEO only begins the job. Yosef identifies additional capabilities an agent needs:

• Understanding: Determine what the business offers and whether it fits the task.
• Interaction: Learn how to use the service and perform the necessary actions.
• Authentication: Establish access to the service.
• Payment: Complete payment headlessly, rather than depend on a person navigating checkout.

Appearing in an answer does not establish that an assistant can complete any of these later steps.

His team’s analytics choice shows how integration can affect a product decision. They asked Claude Code to recommend an analytics service. It suggested PostHog. The team preferred Mixpanel, which they had used for a decade, but Claude Code continued to recommend PostHog because it judged the MCP and API easier to integrate. The team switched. This is one recommendation and purchasing decision, rather than a comparative benchmark of the services; its force comes from how little the team’s accumulated familiarity mattered to the assistant’s reasoning.

Yosef extends this into a warning about repeated friction. An agent that has to launch a browser to use a product may remember the difficulty and prefer a different product next time. The talk presents that as an expected behavior, without demonstrating it across agents. The practical risk follows from the analytics example: when an assistant both recommends a service and integrates it, ease of programmatic use can influence which product reaches the human customer.

At ORA, Yosef’s team began evaluating websites against protocols and best practices, returning readiness scores and agent feedback and comparing results on a leaderboard. Then actual agent behavior challenged a simple checklist assumption. Almost fifty percent of the websites they tested published llms.txt, but agents generally headed to the documentation page and then the homepage.

The usage rate is unclear: Yosef first reports no use of llms.txt, then refers to forty percent using it without defining the denominator. His narrower observation is consistent enough to explain the problem: agents that reached the file found it because the documentation pointed them there. A file can exist without being on the path an agent takes. Publishing useful guidance and connecting it to likely entry points are separate tasks.

Yosef also argues that model improvements make fixed tool-writing conventions age quickly. His example contrasts descriptions of three paragraphs with descriptions of three lines becoming sufficient. That comparison does not establish an optimal length for a particular tool or model. It explains his decision to seek feedback from agents attempting real tasks, rather than treat a prescribed description format as a permanent answer.

Watch the path, then investigate the failure

ORA’s Journey takes a website, an intent, and an agent and records the path the agent follows while trying to complete the task. Yosef says the team ran these journeys tens of thousands of times. Watching the path exposes what the agent searches for and which pages it visits. If a website publishes auth.md but the agent never looks for it, the useful question becomes how the agent actually tries to find authentication information.

The comparison needs more than one harness—the environment through which an agent pursues its task. Yosef runs the same intent against the same website through multiple environments, including Claude Code and ChatGPT, and shows different journeys. He says ChatGPT finds results better in the illustrated case. That observation applies to the example, rather than establishing a general ranking. Keeping the site and intent the same makes the different paths worth investigating.

Journey also connects those paths to business questions and goals for a domain. The point is to understand how an agent tries to accomplish something the business cares about, rather than stop at a score for published files. A successful run in one environment can coexist with a missed resource or an unsuccessful path in another. Readiness therefore depends on observed use as well as the resources a provider exposes.

After studying how agents use websites, Yosef returns to discovery at a different level. Search accompanied the web, app stores accompanied mobile, and feeds accompanied social platforms. What should an agent use to discover an MCP server or an openapi.json description? The object it needs may be a usable connection to a service, rather than a page describing the service.

His hypothetical Airbnb–Booking.com comparison makes the selection problem concrete. Airbnb might offer the better MCP integration while Booking.com offers the better API. Neither preference is presented as an actual evaluation of those companies. The example asks discovery to distinguish between access methods: finding the right business is insufficient if the assistant cannot find the resource that best supports its task.

Three discovery approaches, three limitations

Yosef sees different problems in existing approaches:

• Conventional web search: Human SEO and PageRank shape the results, which he considers insufficiently flexible for discovering agent resources.
• Assistant-specific registries: Closed catalogs require each provider to submit its application to the particular platform.
• A central MCP registry: Shared discovery still needs decisions about curation, governance, and which resources qualify for inclusion.

These approaches answer different questions. A ranking of pages, admission to an assistant’s catalog, and governance of a shared resource directory do not automatically provide the same discovery experience.

Yosef describes two emerging conventions for different parts of that experience. aicatalog.json describes how a website exposes its agent-facing resources. Agentic Resource Discovery, or ARD, describes how a directory exposes itself to agents. A provider catalog helps answer what connections a business offers; a directory gives an agent a way to query a collection of resources. The talk describes their intended roles without establishing broad adoption or resolving the curation questions.

From a scanned domain to a queryable connection

ORA.directory collects domains the team has scanned and exposes descriptions agents can query. In Yosef’s monday.com example, ORA generates an aicatalog.json file identifying the MCP server and API server. Vercel is another example of an entry describing available agent resources and how to access them. Yosef presents the directory as ARD-compliant, making both the collection and its resource descriptions accessible to agents.

This provides a route from discovery to a candidate integration. It does not complete the later work of authentication, payment, or task execution. Those remain separate capabilities to investigate through actual use. A catalog can tell an agent where an MCP or API server is; a journey can reveal whether the agent manages to use it for the intended business goal.

Yosef brings Journey, Directory, and the Ranker together as parts of ORA’s work, then ends with an overlap between agent readiness and human accessibility. An agent relying on nonvisual information needs signals explaining what a website is and how it works. He compares that need to the experience of people with vision disabilities: visual presentation alone cannot carry the meaning required to use the product.

The useful overlap concerns making meaning and capabilities available without depending on sight. It does not imply that every agent lacks visual capabilities—the earlier screenshot-based browsing discussion already describes another mode of access—or that an agent completing a task establishes human accessibility. Yosef’s point is that improving the signals available to one audience can help the other.

His closing goal is to make the existing web agent-accessible. MCP Apps supplies a way to return a useful interface when a human needs to choose. Observed journeys reveal which routes agents actually take. Resource descriptions help them find connections they can use. The work is to prepare services for those different routes while keeping the human interaction that the task still needs.