AI widgets and MCP: showing up as a card, not a sentence

The shift

AI assistants have started answering with an interactive widget — a Maps listing with directions, a product card with a price and a buy button, a bookable calendar — instead of a paragraph of text. ChatGPT, Claude, and Google’s AI Overviews all do it now. That changes the question a business has to answer: not just “can an AI read me,” but “can an AI render me.”

Two mechanisms, and they’re not the same job

A crawl of your website returns text, never a widget. Widgets reach a user through two different channels, and confusing them is where most advice goes wrong.

• Platform-rendered (eligibility). The platform builds the card from your data — Google Business Profile, a product feed, structured data (JSON-LD). Complete, valid data makes you eligible; the platform still decides whether to show it, based on relevance and quality. Google is explicit that valid structured data earns eligibility, not a guaranteed result. So the honest goal is “raise your odds of being rendered,” never “add schema and you appear.”
• Company-built app (provable). You host a small server that speaks the Model Context Protocol (MCP). When a user’s AI client calls one of your tools, your server returns an embedded UI resource and the client renders it inline as a widget. Every step is testable, so this one you can actually prove works — not just hope for.

How a site “replies with a widget”: discover → connect → render

The MCP path is the one people intuit but describe wrong. It is not “crawl my HTML, get a widget.” It’s a chain, and each link is checkable:

• Discover. Your site advertises an MCP server at a well-known URL (the convention is still settling — /.well-known/mcp.json is the leading form). It declares your tools, how to reach the server, and how to authenticate.
• Connect. An AI client (Claude, ChatGPT via connectors) reads that file, connects to your server, and lists your tools.
• Render. When a tool is invoked, your server returns an embedded UI resource; the client renders it inline in a sandboxed frame — the widget.

The honest limit: this proves your server can reply with a widget. It doesn’t mean every AI shows it to everyone — a person still connects or is offered your app. What’s provable is capability; what’s not is passive, universal appearance.

Three states of AI-ready

• Legible — an AI can read and quote you: crawlable copy, clean headings, llms.txt, answer-shaped content. Table stakes.
• Renderable — your data is complete enough that a platform will build a card from you: valid, entity-appropriate schema, a claimed and complete business profile or product feed.
• Actionable — you host an MCP app the AI can operate inline: book, buy, search. A separate build, worth it for the businesses whose customers act, not just read.

What to actually do

• Get renderable first. Make your structured data valid and complete for your entity type —LocalBusiness for a local service, Product/Offer for commerce, SoftwareApplication for a tool, Organization and WebSite for everyone. Claim and complete your Google Business Profile. This is eligibility for the platform-built cards.
• Then consider actionable. If your customers book, buy, or search, an MCP app is the tier that lets an assistant do that inside the conversation. Publish the discovery file and a real tool.
• Don’t chase retired formats. Google retired FAQ rich results on May 7, 2026 — a good reminder that “renderable” is a moving target, and validity today isn’t validity forever.

Where Everfound fits

Everfound audits whether AI can find, understand, and cite you — the legible layer — and checks your structured data against what each entity type needs to be renderable. It won’t promise you a widget (no honest tool can), but it will tell you where your data falls short of eligibility and hand you the fixes. See how it works, or run an audit on your own site.