UCP Checker
Check a store
UCP Score

UCP Score for biznas.sa

Nearly there

77 out of 100, grade B: nearly there. The missing 23 points are spread across Conformance and Capabilities. 3 spec breaks on the status page aren't counted in the score.

Discovery 100Conformance 92Capabilities 35release 2026-04-08

UCP Score 77/100 grade B · nearly there
Points missing 23 Conformance, Capabilities Fixes 5 raise the score Spec breaks 3 not in the score

How the score is made

three areas, weighted
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.
92−3.2 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.
35−19.5 pts
A85–100Ready for UCP agents
B70–84Nearly there
C50–69Partly ready
D30–49Hard for UCP agents
F0–29Not ready

Raise the score

fixes that move the number
part of +3
1Declare a transport on the service
Service entry has no "transport" field and no legacy nested transport.
Without a transport, agents do not know whether to speak REST, MCP, or A2A to your endpoint.
Conformance · effort low 
{
  "version": "2026-08-25",
  "transport": "mcp",
  "endpoint": "https://yourstore.com/api/ucp/mcp"
}

Allowed transport values per spec: rest, mcp, a2a, embedded.

part of +3
2Name services the way the spec does
A service is not named in the spec's dotted form (e.g. dev.ucp.shopping).
Like capabilities, services are named like reversed web addresses so names never collide.
Conformance · effort low 
"services": {
  "dev.ucp.shopping": [...]
}
part of +3
3Name 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.
Conformance · effort low 
"payment_handlers": {
  "com.google.pay": [...]
}
part of +3
4Add version to each payment handler
A payment handler is missing the required "version" field.
Handler versions evolve independently of the profile. Agents pin their token request format to a specific handler version.
Conformance · effort low 
"version": "2026-08-25"
part of +3
5Move 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.
Conformance · effort low 
"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.

Every check

11 passed · 5 to fix
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
No validation warnings
4 warnings.
Conformance
Capability Coverage · 0 of 4
To fix
Capabilities declared
1 of 6 capability families detected: Catalog. A family counts once however many namespaces or extensions declare it.
Capabilities
Problem
Checkout capability
No checkout capability.
Capabilities
Problem
Transports declared
No transports declared.
Capabilities
To fix
Payment handlers
1 handler declared, not named the way the spec expects (e.g. com.google.pay), so agents cannot look it up.
Capabilities

Not in the score, but worth fixing first

spec breaks
Problem
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.
on the status page
To fix
supported_versions isn't laid out the way the spec says
Spec level: SHOULD. Not part of the UCP Score.
on the status page
To fix
The profile has no ETag or Last-Modified header
Spec level: SHOULD. Not part of the UCP Score.
on the status page

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 Zid stores
The profile answered in 350 ms, faster than 69% of the Zid stores we check.