MCP Apps lets services return branded interface components to a chat when an agent needs human input.
2
Websites are moving toward a nearly headless model where agents handle most interactions and bring back only the interface a person needs.
3
Agent readiness has to be learned by observing agents, because published guidance such as llms.txt often does not match how agents actually use websites.
Summary
Liad Yosef argues that the web is moving from a collection of interfaces designed for people to a set of services accessed through personal assistants. MCP Apps provides the missing interaction layer by letting services return real UI inside a chat, so a person can choose a hotel, inspect a model, or select a seat without opening a full website. Yosef expects most website interaction to happen headlessly, while human-facing interfaces remain for cases that need approval or choice. He is direct about the commercial effect: agents have no brand loyalty and may recommend a different product because its API is easier to use. His research at Aura found that agents often ignore standards such as llms.txt, so teams should test how agents actually discover, understand, authenticate with, and pay a website. He also connects agent accessibility with accessibility for people with vision disabilities.
MCP Apps gives agents a human interaction layer inside chat
Liad Yosef introduces MCP Apps as the specification behind interfaces embedded in chat applications. A server can send UI components into a conversation, so a service keeps its brand and interface instead of being reduced to text or a database. The user also gets a familiar signal about which service they are using. This matters when an assistant handles tasks that still need a person, such as choosing a hotel, viewing a 3D model, or selecting a venue seat. The assistant handles the surrounding work, while the service supplies the last interaction.
The agentic web breaks large websites into small capabilities
Yosef says people have spent two decades learning separate interfaces for the same intent. Planning an anniversary can require learning the interfaces of Google, Amazon, several booking services, and other sites. He proposes breaking those interfaces into atoms that an assistant can compose. A person may not need most of a booking, Airbnb, or Jira dashboard, but still needs to express intent to the service. The assistant can use context such as a preference for hotels in nature, pull the relevant map, and coordinate services without each company building integrations with every other company.
Browser agents are an interim solution that preserves the wrong interface
Yosef calls browser agents a faster-horse solution because they make an agent operate filters, pagination, sorting, and dashboards designed for human perception. He mentions Google's WebMCP approach, where a website exposes tools through JavaScript rather than forcing an agent to interpret screenshots. That can help with simple tasks, but he questions why someone would want an agent to browse a Salesforce dashboard when the person does not want to use the dashboard at all. The deeper change is that the assistant, rather than a website or browser, becomes the entry point.
Websites become nearly headless while humans still approve some actions
Yosef describes a nearly headless web. An autonomous agent can organize email without showing a user interface, while booking a honeymoon hotel may still require a person to make a choice. The website interaction therefore splits into the agent's experience of the site and the user's experience of the agent. He says businesses need to make their data and actions ready for customer assistants as well as for people who still browse directly. The site may continue to exist, but most interaction can happen through an agent.
Yosef describes asking a coding agent to choose an analytics service. His team preferred Mixpanel because they had used it for a decade, but the agent repeatedly recommended PostHog because its MCP and API were easier to integrate. They followed the recommendation. In his example, a decade of polished user and developer experience lost to a tooling preference. He says agents have no brand loyalty. If an agent has to open a browser to use a product, it may remember that friction and avoid the product next time.
Agent readiness includes discovery, interaction, authentication, and payment
Yosef says being found by an agent is only the first step. A website also needs to explain what it is, how an agent should interact with it, how the agent authenticates, and how it can pay the business headlessly. Aura offers a free readiness benchmark that scores websites against protocols and practices, along with feedback from agents. This frames agent readiness as a full path through a product rather than a single search or metadata problem.
Observed agent behavior can contradict published standards
Aura found that roughly half of the websites it tested published an llms.txt file, but almost none of the agents used it directly. Most went first to the documentation page and then to the homepage. The minority that opened llms.txt did so because the documentation mentioned the file. Yosef uses this to question the practice of telling agents in advance what they need. He says model behavior changes quickly, so guidance that once recommended three-paragraph MCP tool descriptions can become obsolete when three lines are enough. Teams need agent feedback from actual runs.
Agent discovery needs a directory that can describe different resources
Yosef argues that the agentic web needs its own discovery layer. Web search, app stores, and social feeds each became discovery mechanisms for earlier computing shifts. SEO and conventional page rank do not describe whether a service has a better MCP server or API, while closed registries and a single central registry create submission, curation, and governance problems. He describes Aura Directory, which exposes agentic resources for domains through AI catalog files and an agentic resource discovery interface. An agent can query the directory to find a domain's MCP and API resources.
Human accessibility and agent accessibility require similar signals
Yosef connects agent readiness with accessibility for people with vision disabilities. Language models do not perceive a website visually, so they need other signals to understand how to use it. Improving human accessibility can therefore improve an agent's ability to interact with the site, and the reverse can also happen. He closes by saying the goal is not to rebuild the web for agents. It is to make existing websites accessible to agents while preserving human access where people still need to browse or make a decision.
"MCP apps were released as a spec and as a standard few months ago with the support of Claude first as the first client and then all clients followed."01:18
Who should watch
You are building an API, MCP server, or SaaS product and want to know why an agent may choose a competitor with easier integration.
Your website team is adding llms.txt or other agent metadata and needs evidence about how agents actually discover and use it.
You design web interfaces or accessibility features and want to understand how human accessibility overlaps with agent accessibility.
