UCP Checker
UCP Score

UCP Score for berdsen.pl

Nearly there

81 out of 100, grade B: nearly there. The missing 19 points are spread across Conformance and Capabilities.

Discovery 100Conformance 79Capabilities 65release 2026-03-30

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.
79−8.4 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.
65−10.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
+11
1Declare ucp.capabilities
No capabilities are declared, so agents cannot tell what your store supports.
Agents read the capabilities map to know whether to attempt cart, checkout, payment tokenization, identity linking, etc. An empty list collapses the agent to "browse only" mode.
Capabilities · effort medium
"ucp": {
  "capabilities": {
    "dev.ucp.shopping.checkout": [
      {
        "version": "2026-08-25",
        "spec": "https://ucp.dev/2026-08-25/specification/checkout/",
        "schema": "https://yourstore.com/.well-known/ucp/schemas/checkout.json"
      }
    ]
  }
}

Name spec capabilities under dev.ucp.shopping.* (for example dev.ucp.shopping.checkout). Each entry needs a version, a spec URL and a schema URL.

part of +8
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 +8
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 +8
4Add id to each payment handler
A payment handler is missing the required "id" field.
The id field uniquely identifies the handler instance for token routing. Required by the spec.
Conformance · effort low
{
  "id": "my-google-pay-prod",
  "version": "2026-08-25"
}
part of +8
5Add 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 +8
6Update to a published UCP version
The declared version is not in the published spec list.
Agents fall back to the closest known version, but breaking changes between releases can silently corrupt requests. Pin to a published version your stack actually supports.
Conformance · effort medium
"version": "2026-08-25"

See https://ucpchecker.com/spec for the current published version list.

part of +8
7Cryptographic message signing is not yet enabled
Your UCP profile lists no public keys, so cryptographic message signing is not yet enabled for this store. HTTPS already confirms your store's identity; signing adds a further layer for checkout, payment and webhook messages.
The UCP spec recommends signing checkout completion and payment responses, and requires it for webhooks. A store that sends order updates by webhook needs keys; others can add them later.
Conformance · effort medium
{
  "keys": [
    {
      "kty": "EC",
      "crv": "P-256",
      "x": "<base64url x>",
      "y": "<base64url y>",
      "kid": "store-2026-10",
      "use": "sig",
      "alg": "ES256"
    }
  ],
  "ucp": { ... }
}

Create a P-256 (ES256) key pair: ES256 is the one algorithm every UCP agent must be able to check. Add the public key to a "keys" list at the top level of your UCP profile, as in the example, with its own "kid", and keep the private key on your server. The spec recommends a new key every 90 days: publish the new one next to the old, sign with it, and remove the old key a week later.

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 for UCPCheckerBot, but blocks GPTBot
  • 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 · 2 of 4
2 OK
Profile passes schema validation, Protocol version present and well-formedShow
  • Profile passes schema validation · No structural errors
  • Protocol version present and well-formed · Version: 2026-03-30
To fix
Public keys published
No keys list at the top level of the profile. Fix 7 above.
Conformance
Problem
No validation warnings
7 warnings.
Conformance
Capability Coverage · 1 of 4
1 OK
Checkout capabilityShow
  • Checkout capability · dev.ucp.shopping.checkout detected
To fix
Capabilities declared
2 of 6 capability families detected: Checkout, Catalog. A family counts once however many namespaces or extensions declare it.
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
Speed among Custom stores
The profile answered in 503 ms, faster than 27% of the Custom stores we check.