When we shipped the UCP Checker Chrome extension six weeks ago, the goal was modest: give developers a way to see whether the storefront they're looking at has a UCP manifest, without opening DevTools.
Developer browser extensions have a long history in ecommerce. Wappalyzer — with over 3 million installs — built a business around passive technology detection: visit a site, and the extension tells you what stack it's running. Shopify's own Theme Inspector plugs into DevTools to profile Liquid rendering performance, targeting sub-200ms render times. Koala Inspector took a different angle: reverse-engineering Shopify stores to expose best-selling products, installed apps, and estimated sales — over 250,000 users doing competitive intelligence from their toolbar.
What these tools share is a pattern: a lightweight, always-on detection layer that fires on every page visit and surfaces a single, useful signal. Wappalyzer tells you the stack. Theme Inspector tells you the bottleneck. Koala tells you the competition.
UCP Checker tells you whether the store is agent-ready.
We posted it to Hacker News as a "manifest debugger for the agentic web." The feedback was sharp — and it confirmed a direction we were already exploring. More on that below. But first, here's the technical story of what we built, what it found, and where we think it should go.
How the extension works
The architecture is deliberately simple. Compare it to Wappalyzer, which injects content scripts to analyse the DOM, reads meta tags, checks JavaScript globals, and matches against a database of 1,000+ technology fingerprints. Or Shopify Theme Inspector, which hooks into Chrome DevTools, intercepts the Server-Timing header, and renders flame graphs from Liquid profiling data.
UCP Checker does none of that. There are four moving parts, and the entire detection mechanism is a single HTTP request.
1. Navigation listener. The extension uses the webNavigation.onCompleted event to detect when you land on a new domain. No content scripts, no DOM injection, no page content access. It only fires on completed navigations — not iframes, not AJAX loads, not redirects.
2. Manifest probe. On every new domain, the extension makes a single fetch() call to https://{domain}/.well-known/ucp. That's it. One HTTP request per domain visit. The fetch uses credentials: "omit" — no cookies, no session tokens, no authentication headers are ever sent. The response is parsed for HTTP status, response time, and manifest structure.
This is architecturally closer to how a browser checks for /.well-known/security.txt or /.well-known/openid-configuration than how Wappalyzer fingerprints a technology stack. There's no heuristic matching, no DOM analysis, no pattern library to maintain. Either the endpoint exists and returns a valid manifest, or it doesn't.
3. Badge system. Based on the probe result, the extension updates its toolbar icon:
- Green dot: valid UCP manifest found. The store is agent-ready.
- Gray dot: no manifest detected. Either the store hasn't deployed UCP, or the endpoint returned 404/redirect.
- No badge change on error states (timeouts, network failures) — the extension stays silent rather than showing misleading status.
4. Optional telemetry. There's a toggle — on by default — labelled "Share anonymous uptime stats." When enabled, the extension sends the public manifest data (domain, HTTP status, response time, manifest version) to our monitoring pool. This is how we crowdsource the discovery data. The key word is "public" — this is data any HTTP client can retrieve from /.well-known/ucp. No browsing history, no page content, no cookies, no personally identifiable information.
That's the entire technical surface. Four components, one HTTP request per domain, zero page content access.
The permission model
Chrome extensions live and die by their permission model — and this is where the architectural choices get interesting.
Wappalyzer requires <all_urls> and content script injection to analyse every page you visit. That's the trade-off for detecting 1,000+ technologies: broad access in exchange for broad detection. Koala Inspector needs similar access to read page DOM and extract product data. Shopify Theme Inspector requires DevTools access and hooks into the network layer to read server timing headers.
Here's ours:
"permissions": ["activeTab", "webNavigation", "storage"],
"host_permissions": ["https://*/.well-known/ucp*"]
activeTab— read the current tab's URL (domain only) to know where to probe. This is the most restrictive tab permission Chrome offers — it gives access to the active tab only when the user interacts with the extension.webNavigation— detect when you navigate to a new domain. Required for the automatic probe on page load.storage— save badge state and timestamps locally. No cloud sync, no remote storage.host_permissions: https://*/.well-known/ucp*— the extension can only make requests to this specific path. It cannot read page content, access cookies, or interact with any other endpoint on the domain.
What we don't request: tabs (would give access to all tab URLs), cookies, history, <all_urls>, content script injection, or any DOM access permissions. The extension literally cannot read what's on the page you're viewing. It can only check whether a specific well-known URL exists.
This is the narrowest permission surface of any ecommerce developer extension we're aware of. It's auditable in Chrome's extension management page in seconds. For agencies and platform teams running this in their work browsers, that matters.
Manifest V3 and the security baseline
The extension ships on Manifest V3 — Chrome's current extension platform, which enforces a stricter security model than V2. Service workers replace persistent background pages, host_permissions are declared explicitly rather than inferred, and the content security policy blocks inline script execution.
This matters because the December 2024 Chrome extension supply chain attack — which compromised extensions affecting 2.6 million users — exploited V2-era permission patterns that V3 structurally prevents. Our V3 architecture, combined with path-scoped host permissions, means even a compromised build couldn't read page content or access arbitrary URLs. The worst case is a bad probe to /.well-known/ucp — a public endpoint that returns public data.
What the extension discovered
Here's where the modest debugging tool turned into something bigger than we expected.
As of today, the extension has fed 1,480 unique domains into our monitoring pool — making it the single largest discovery channel, ahead of our proprietary crawler (407 domains), web submissions (120), and bulk checks (1 unique).
Discovery source Domains % of pool Verified rate
─────────────────────────────────────────────────────────────
Browser extension 1,480 73.7% 98.4%
Crawler 407 20.3% 87.2%
Web submissions 120 6.0% 64.2%
─────────────────────────────────────────────────────────────
Total 2,007 100.0% 83.1%
The verified rate tells the story: 98.4% of domains discovered by the extension have valid UCP manifests. Compare that to web submissions, where people are often testing domains that don't have UCP yet. The extension finds real merchants with live manifests because it only fires on storefronts people are actually visiting.
What kinds of stores? We can't share specific domains from extension discovery (more on that in the privacy section), but the profile is distinctive:
- Niche DTC brands that don't appear in any Shopify directory or public store list. A ceramics studio in Portland. A specialty dog food company. A Japanese stationery importer. These stores have UCP manifests because Shopify deployed them platform-wide — but they'd never show up in a targeted crawl.
- Regional retailers operating in markets our crawler doesn't cover well. Stores in Southeast Asia, Scandinavia, South America — the extension's geographic reach follows wherever our users browse.
The extension isn't a crawler. It doesn't systematically scan the internet. It discovers stores through the natural browsing patterns of the people who install it — which means it reflects real developer and e-commerce professional behaviour, not a bot's idea of where to look.
This is a pattern Wappalyzer pioneered — crowdsourced technology detection at scale. But where Wappalyzer's telemetry feeds a commercial technology intelligence database (with API pricing starting at $250/month for 5,000 lookups), ours feeds a public monitoring pool. The domain data powers our free benchmarks at ucpchecker.com, the alerts system, and the weekly adoption stats newsletter. The extension users are building the map, and the map is open.
The privacy architecture
We made a deliberate choice early on: extension-discovered domains are attributed only as "browser extension" in our data. We don't track which user discovered which domain, we don't store browsing sessions, and we don't build user profiles from extension activity.
The telemetry payload for a single probe looks like this:
{
"domain": "example-store.com",
"status": "verified",
"http_status": 200,
"response_time_ms": 142,
"manifest_version": "2026-01-23",
"transports": ["mcp", "embedded"],
"timestamp": "2026-03-02T14:23:01Z"
}
No user ID. No session ID. No IP forwarding. No referrer. The credentials: "omit" flag on the fetch ensures no cookies leave the browser. The request goes to our API, gets validated, and the domain enters the monitoring pool. The connection to the individual browse event is not retained.
This is a fundamentally different approach to extension telemetry than the competitive intelligence tools in this space. Koala Inspector and Commerce Inspector are designed to extract data from stores you visit — product listings, pricing, sales estimates. Our extension extracts nothing from the store's page. It checks a single public endpoint and reports the result.
The Hacker News thread: runtime validation and where we're heading
When we posted the extension to Hacker News, the most substantive feedback wasn't about the extension itself. It was about what happens after validation.
The argument: a static manifest check tells you whether the store's UCP endpoint exists and conforms to the spec. But it doesn't tell you what happens when an agent actually fetches content from that endpoint. A valid manifest can serve tool responses containing prompt injection attempts, credential exfiltration patterns, or behavioural steering embedded in product descriptions.
The commenter framed it as pairing manifest validation with runtime guardrails — classify and strip instructions in fetched content, detect exfiltration patterns, enforce policies before tool responses reach the LLM.
What's interesting is the timing. When we read that feedback, we were already deep into building UCP Playground — a tool that does exactly what the commenter was describing from the observation side. Playground connects to a store's MCP server, runs live agent sessions, and shows you every JSON-RPC message flowing between the agent and the store. You can see the tool responses, the injected instructions, the schema quality — everything that happens at runtime.
The HN feedback didn't change our direction. It confirmed we were on the right track.
But it also sharpened a distinction we've been thinking about:
Static layer — what UCP Checker and the extension do today. Schema validation, capability declarations, reachability, access policies. The question: "Is this a valid, accessible UCP endpoint?"
Runtime layer — what Playground observes but doesn't enforce. The actual content of tool responses, instruction injection patterns, checkout flow completeness. The question: "What happens when an agent shops here?"
The open question is whether the runtime layer needs to move from observation to enforcement — and who should own that. Should merchants sanitise their own MCP responses? Should model providers extend their safety layers to cover tool responses? Or should the UCP spec itself define content security policies, similar to CSP headers in browsers?
We don't have a definitive answer. We think observability comes first (which is why we built Playground), and enforcement will follow as the ecosystem matures. If you're building in this space — agent frameworks, MCP servers, security tooling — we'd love to hear how you're thinking about this split. Reach out at ucpchecker.com/contact.
What we're building next
The current extension does one thing: probe /.well-known/ucp and show you the result. That constraint was intentional. We wanted something a developer could understand completely in seconds, trust immediately based on the permission model, and leave running permanently without performance or privacy concerns.
Here's what's on the table:
Richer popup panel with grading
Right now the popup gives you the badge and a link to the full report. We're considering surfacing more of the probe data directly: response time, manifest version, transport declarations, bot access status.
We already grade tool schemas A through F in UCP Playground. Surfacing that grade in the extension popup would tell developers "this store's MCP server has well-structured schemas" without leaving the tab. One glance: green dot, B+ grade, 142ms response time, MCP + Embedded transports. That's a useful density of information for an agency evaluating a store's agent readiness.
The trade-off is an additional API call per domain to fetch the grade from our scoring system. We'd need to handle domains we haven't benchmarked yet — probably showing "not yet scored" rather than guessing.
One-click Playground link
The natural flow from "this store has UCP" to "let me see how an agent shops there" should be one click. We're planning a direct link from the extension popup to UCP Playground, pre-loaded with the current domain. Visit allbirds.com, see the green dot, click "Open in Playground," and you're watching Claude shop for running shoes.
One-click alert setup
See a domain's badge, click through and subscribe to alerts from the same flow. Right now there's a gap between "I noticed this store has UCP" and "I want to know if it breaks." A deeper integration from the extension popup to the alerts page closes that gap. This one requires a logged-in account on ucpchecker.com — so it's not purely client-side — but the extension itself doesn't need to handle auth. It just deep-links to the alerts page with the domain pre-filled.
Quick audit run
A one-click "audit this domain" that runs a comprehensive check — not just the manifest probe, but the full scoring pipeline: schema quality, capability coverage, response times, bot access policies. The extension would trigger it; the results would appear on ucpchecker.com. Think of it as Lighthouse for UCP: right-click, audit, see the score.
What we're deliberately not building
DOM inspection or content analysis. Reading page content to extract product data, detect UCP tools, or analyse the storefront. This would require content script injection and broader permissions — a fundamentally different trust model from what we've built. The extension stays manifest-only.
Automated testing or agent execution. Running agent interactions from the extension context. That's what Playground is for. The extension is a detection and monitoring tool, not an execution environment.
The extension icon story
When we shipped the browser extension, we didn't have a logo. We needed something in the toolbar icon space and "UCP" — three letters, high contrast, instantly readable at 16x16 — just worked. So we shipped it.
It wasn't a branding decision. It was a pragmatic one. But it stuck. Developers recognise it in their toolbar. It's become shorthand for "this tool checks UCP manifests."
Since then, UCP Checker has grown into more than a checker. We've shipped the playground, alerts, a directory, stats, and now the extension. The brand has evolved and we've developed a proper logo and visual identity to match.
So the extension icon is on the roadmap for a reskin. We want to bring it in line with the rest of the UCP Checker identity — same logo, same look, consistent across the site, the extension, and everywhere else we show up. It's a small change but it matters: when you see the icon in your toolbar, it should feel like the same product you use on the web.
No timeline yet, but it's coming.
Where the extension fits in the stack
We started with the crawler and the website. The extension came right after — and became our biggest discovery engine, helping us scan thousands of stores through crowdsourced browsing data. UCP Playground came later, when we started exploring what happens at runtime when agents actually try to shop. Then Alerts, once we noticed the volatility in store manifests — stores breaking, recovering, new ones appearing daily. Each product answers a different question:
- Extension: "Is this store agent-ready?" — answered while you browse, zero effort.
- UCP Checker: "How agent-ready is this store?" — detailed scoring, benchmarks, bot access policies.
- Playground: "What happens when an agent actually shops here?" — live agent sessions, multi-model comparison, session replay.
- Alerts: "Did something change?" — email notifications when a domain's UCP status shifts.
The extension sits at the lowest friction point. It's the lightest-touch interaction — a passive signal in your toolbar that occasionally becomes a starting point for deeper investigation. A green dot that says "yes, this store speaks the protocol." A gray dot that says "not yet."
Compare this to how Wappalyzer evolved: the extension was the entry point, but the value migrated to the API and the technology intelligence platform. The extension remained free and lightweight; the business built on top of the data it generated. We're seeing a similar pattern. The extension generates the discovery data. The platform — checker, playground, alerts — turns that data into tools developers actually build on.
1,480 domains later, that passive signal has become the largest discovery engine in our stack. The community is building the map by browsing.
For deeper dives into what the extension is discovering across platforms, see our platform-specific guides: Shopify, WooCommerce, Magento, and BigCommerce. And for the broader ecosystem trends this data feeds into, the State of Agentic Commerce reports track adoption month over month.
What we'd love to hear
We're at a decision point with the extension. The current version is stable, lightweight, and trusted by its install base. The question is what to add — and what to deliberately leave out.
If you're using the extension, or if you're building on UCP and thinking about the tooling layer:
- What would make you open the extension popup more often? Right now most users glance at the badge and move on. Would a grade, response time, or transport info in the popup change that?
- Quick audit: useful? A one-click "run full audit" from the toolbar — would you use it, or do you just go to ucpchecker.com directly?
- Runtime enforcement: who should own it? Merchant-side gateway, agent-provider responsibility, or protocol-level spec?
Drop us a line at ucpchecker.com/contact or find us on the channels where you first heard about this. We read everything.
Technical notes: The extension is available for Chrome, Edge, and Brave (any Chromium-based browser). Manifest V3. Requires zero configuration and no account. The telemetry toggle is visible in the extension popup and defaults to on. All probe data is public — the extension only requests information that any HTTP client can retrieve from /.well-known/ucp. Permission manifest is auditable in chrome://extensions.
Tools:
- Install the extension — free, no account required
- UCP Checker — full domain analysis and benchmarking
- UCP Playground — watch agents shop in real time
- UCP Alerts — get notified when manifests change