UCP Score
UCP Score for giddy-store.com
94 out of 100, grade A: ready for UCP agents. The missing 6 points are spread across Conformance and Capabilities. 3 spec breaks on the status page aren't counted in the score.
Discovery 100Conformance 88Capabilities 95release 2026-04-08
UCP Score
94/100
grade A · ready for UCP agents
Points missing→
6
Conformance, Capabilities
Fixes→
6
raise the score
Spec breaks→
3
not in the score
Discovery 30%
Can a UCP agent find and read the profile: HTTPS, an answer at /.well-known/ucp, robots.txt allowing it, and five files outside UCP (llms.txt, sitemap, Open Graph, Organization schema, viewport).
100full marks
Conformance 40%
Does the profile follow the spec: valid against its release (counted three times), a dated release, keys published, few warnings, spec and schema links that resolve.
88−4.8 pts
Capabilities 30%
What an agent can do here: how many capabilities, checkout, at least one service, payment handlers, and services that answer our check.
95−1.5 pts
A85–100Ready for UCP agents
B70–84Nearly there
C50–69Partly ready
D30–49Hard for UCP agents
F0–29Not ready
part of +5
Conformance · effort low
1Use YYYY-MM-DD for service version
A service version is not in YYYY-MM-DD format.
Service versions follow the same date-based format as the profile version.
"version": "2026-08-25"
part of +5
Conformance · effort low
2Name capabilities the way the spec does
A capability is not named in the spec's dotted form (e.g. dev.ucp.shopping.checkout).
Capabilities are named like reversed web addresses so that names never collide: "checkout" is ambiguous; "dev.ucp.shopping.checkout" is not.
"capabilities": {
"dev.ucp.shopping.checkout": [...]
}
part of +5
Conformance · effort low
3Use YYYY-MM-DD for capability version
A capability version is not in YYYY-MM-DD format.
Capability versions follow the same date-based format as the profile version itself.
"version": "2026-08-25"
part of +5
Conformance · effort low
4Name payment handlers the way the spec does
A payment handler is not named in the spec's dotted form (e.g. com.google.pay).
Handlers are named like reversed web addresses (com.google.pay, com.stripe.terminal) so every store declaring the same payment method names it the same way, and an agent can recognise it.
"payment_handlers": {
"com.google.pay": [...]
}
part of +5
Conformance · effort low
5Use YYYY-MM-DD for handler version
A payment handler version is not in YYYY-MM-DD format.
Handler versions follow the same date-based format as everything else in UCP.
"version": "2026-08-25"
part of +5
Conformance · effort low
6Move to the latest UCP protocol version
Your profile declares a valid but older protocol version. A newer one is published.
Older versions stay valid (agents use the version you declare), but newer abilities (embedded checkout, agent payment mandates, linked customer accounts, card authentication, payment terms and store location lookup) only work against the latest version. The profile itself barely changes: the signing keys move to a root-level "keys" list, and the rest of the update is in what capabilities can say.
"ucp": {
"version": "2026-08-25",
...
},
"keys": [ ... ] // beside "ucp", not inside it
Set the version to 2026-08-25 and publish your public keys as a root-level "keys" list. The older "signing_keys" field is still accepted, but "keys" is the one every verifier reads.
Agent Discovery · 8 of 8
8 OK
HTTPS, UCP profile reachable, AI bot access, llms.txt, sitemap.xml, Open Graph tags, Organization schema (JSON-LD), Mobile viewport metaShow
- HTTPS · Profile URL uses https://
- UCP profile reachable · HTTP 200
- AI bot access · robots.txt allows /.well-known/ucp
- llms.txt · Found at /llms.txt
- sitemap.xml · Found at /sitemap.xml
- Open Graph tags · og:title and og:type/url present
- Organization schema (JSON-LD) · Organization-typed JSON-LD detected
- Mobile viewport meta · <meta name="viewport"> present
UCP Conformance · 3 of 4
3 OK
Profile passes schema validation, Protocol version present and well-formed, Public keys publishedShow
- Profile passes schema validation · No structural errors
- Protocol version present and well-formed · Version: 2026-04-08
- Public keys published · Keys published at the top level
Problem
Conformance
No validation warnings
9 warnings.
Capability Coverage · 4 of 5
4 OK
Capabilities declared, Checkout capability, Transports declared, REST transport reachableShow
- Capabilities declared · 3 of 6 capability families detected: Checkout, Cart Management, Catalog. A family counts once however many namespaces or extensions declare it.
- Checkout capability · dev.ucp.shopping.checkout detected
- Transports declared · REST
- REST transport reachable · Reachable in 637ms (HTTP 200)
To fix
Capabilities
Payment handlers
Handlers declared, but none in a shape agents can read.
Problem
on the status page
The profile sits behind a redirect
giddy-store.com/.well-known/ucp answers 301 redirect. The spec forbids redirects on the profile, so an agent that asks giddy-store.com stops there. Serve it directly on every host agents use.
Problem
on the status page
The profile isn't served with the caching the spec requires
Served without a Cache-Control header. Spec level: MUST. Not part of the UCP Score.
To fix
on the status page
The profile has no ETag or Last-Modified header
Spec level: SHOULD. Not part of the UCP Score.
The score measures what the profile declares across the three areas above. These break a rule in the spec that agents follow, so they can stop an agent before the score matters.
Speed among Woocommerce stores
The profile answered in 1,185 ms, faster than 39% of the Woocommerce stores we check.