UCP Profile and Capability Negotiation Basics
> A UCP profile is a structured declaration of a merchant's business identity, supported services, and capability configuration; capability negotiation is the process by which an agent computes the intersection of what it can invoke and what the merchant has declared, using the "server-selects" algorithm defined in the UCP specification.
---
What Is a UCP Profile?
A UCP profile is the merchant's formal self-declaration within the Universal Commerce Protocol. It is a structured data document — referenced from the `/.well-known/ucp` manifest — that describes the business, defines which UCP services are available, declares the capabilities each service supports, and specifies the configuration details agents need to interact with those services correctly.
The Google UCP profile documentation describes the profile as containing the merchant's UCP configuration including business information, service definitions, and capability declarations. Where the manifest is the lightweight discovery entry point — telling agents that a UCP implementation exists and pointing to the business server — the profile is the complete specification of what that implementation offers.
Profiles serve a second function beyond capability advertisement: they create a stable, versioned record of the merchant's UCP configuration that can be validated, audited, and referenced by agent platforms when onboarding the merchant to specific surfaces like Google AI Mode. A merchant's profile is submitted to Google during Merchant Center UCP onboarding and forms the basis for Google's capability verification checks.
---
What a UCP Profile Contains
A UCP profile is a JSON document with the following key structural sections:
Business information: The profile includes the merchant's business name, domain, country of operation, and contact information. This metadata helps agent platforms verify merchant identity and display accurate merchant information to buyers during a shopping interaction.
Service definitions: The profile's most important section is the `services` object, which maps each declared UCP capability to its implementation details. For each capability service, the profile specifies:
- The endpoint URL (HTTPS base URL for the service)
- The UCP capability version the endpoint implements
- Supported request methods
- Any service-specific configuration (e.g., supported currency codes, supported fulfillment regions)
Public key: The profile includes the merchant's public key for signature verification, confirming the key declared in the `/.well-known/ucp` manifest. This redundancy ensures that agents who have cached a manifest can still verify signatures using the profile's authoritative key reference.
---
How Capability Negotiation Works
Capability negotiation is the process by which an agent determines what it can actually do with a given merchant. It is not a network call — it is a computation the agent performs locally after fetching the manifest and optionally the profile.
The UCP specification defines this as the "server-selects" algorithm. The name reflects the principle: it is the merchant (server) who selects — by declaring — which capabilities are available. The agent computes the intersection of two sets:
1. What the agent can invoke: The set of UCP capabilities the agent platform has implemented support for 2. What the merchant has declared: The set of capabilities listed in the merchant's manifest (and profile)
The intersection of these two sets is the effective capability set for the session — what the agent can actually do with this merchant. If the agent supports search, cart, and checkout but the merchant only declares search and redirect_checkout, the effective set is search and redirect_checkout. The agent will not attempt to create a cart session because `cart` is not in the intersection.
This design has three important properties:
Progressive degradation. If a merchant removes a capability from their manifest (for example, disabling cart during a system update), agents automatically stop attempting that capability — they do not fail hard, they simply work within the reduced capability set.
Forward compatibility. If a new UCP capability is defined in a future version of the specification, agents that implement the new capability can invoke it on merchants that declare it, without any protocol-level change to how negotiation works. Old agents simply do not include the new capability in their invocation set.
No hard dependencies. Merchants do not need to implement all capabilities to participate. A merchant with only `catalog_search` declared is still a valid UCP participant — discoverable and searchable, just not yet cart-capable or purchasable.
---
Service Capability Declarations in Detail
Within the `services` section of the profile, each capability service is declared with version and endpoint information. Key service types in the current UCP specification include:
| Service | Capability | Description | |---|---|---| | `catalog_search` | Product search | Free-text search with filters, returns paginated results | | `catalog_lookup` | Product lookup | Exact product retrieval by item_id or barcode | | `cart` | Cart management | Create, update, get, and checkout multi-item sessions | | `checkout` | Native checkout | Three-endpoint checkout session lifecycle | | `redirect_checkout` | Redirect-based checkout | URL template for redirecting buyer to merchant checkout | | `identity_linking` | Buyer identity | OAuth 2.0 account linking and JWT intent flow |
Each service declaration in the profile specifies the exact endpoint URL and UCP version. Version declarations are important because they allow agent platforms to identify which protocol version they are interacting with and apply the correct request/response schema for that version. As the UCP specification evolves, version declarations ensure backward compatibility — an agent implementing UCP v1.0 will correctly parse a v1.0 service declaration and gracefully skip a v2.0 service it has not yet implemented support for.
---
Why It Matters for Merchants
Profiles and capability negotiation give merchants explicit control over their UCP surface. A merchant who is not yet ready to support native checkout can declare only search, lookup, and redirect checkout — and agents will work within that declared set, never attempting a checkout session the merchant cannot handle. There are no unexpected interactions or error storms from agents attempting capabilities that are not yet live.
The profile's payment handler declaration is also a practical safeguard. By declaring Google Pay as the payment handler before implementing native checkout, the merchant and Google can verify the configuration is correct before any live buyer transaction is attempted. This reduces the risk of payment failures during the initial live period.
Profile versioning is also an operational benefit. When a merchant upgrades their UCP implementation — for example, adding native checkout capability to an existing search-and-lookup implementation — they update the profile and manifest. Agent platforms reading the updated manifest will immediately include the new capability in their negotiation computation, making the upgrade instantaneous and automatic across all compatible agents.
---
FeedBridge Relevance
FeedBridge manages the UCP manifest and protocol endpoint configuration that underpins the capability declaration model. The UCP Dashboard Hub in FeedBridge provides a compliance scorecard and capability checklist that maps to the declared capabilities in the manifest — giving merchants a visual representation of which services are active and which have outstanding configuration steps. FeedBridge generates the `/.well-known/ucp` manifest with capability declarations that reflect the live status of each UCP endpoint on the platform.
For merchants who want to verify their capability declarations before submitting to Google's UCP onboarding, the API Playground in FeedBridge provides in-dashboard testing of the Catalog Search, Catalog Lookup, and Cart API responses — the three capability services most commonly invoked by agents after reading a manifest.
FeedBridge's Protocol Compliance scoring dimension (30% of the AI Readiness Score) validates the correctness of the protocol configuration, including capability declarations and endpoint responses, at the product and feed level.
---
Frequently Asked Questions
Q: Is the UCP profile the same as the `/.well-known/ucp` manifest? A: No, they are related but distinct. The manifest is the lightweight discovery file at the well-known URI — it declares that a UCP implementation exists and provides a minimal capability summary. The profile is a more detailed structured document, typically referenced from the manifest, that contains the full service definitions, payment handler configuration, and business information that agent platforms need for onboarding and capability verification.
Q: Can a merchant have different profiles for different brands or stores? A: Yes. In a multi-brand merchant architecture, each brand or store domain would have its own `/.well-known/ucp` manifest pointing to its own profile. Capability sets can differ between brands — one brand may support native checkout while another only supports redirect checkout — because each profile is a separate declaration.
Q: Does the "server-selects" algorithm favour the agent or the merchant? A: The name "server-selects" reflects that the merchant (the server) controls which capabilities are available by declaring them in the manifest. The agent cannot invoke a capability the merchant has not declared. The algorithm produces a conservative intersection — neither side can exceed the other's declared or implemented capabilities.
Q: How often should I update my profile? A: Update your profile whenever your capability set changes — when you add a new capability, deprecate an existing one, change endpoint URLs, rotate public keys, or modify payment handler configuration. Profile changes take effect immediately for agents who fetch the manifest and profile after the update.
Q: What happens if a capability in the profile points to a broken endpoint? A: If an agent successfully negotiates a capability and then receives errors on invocation because the endpoint is broken, the agent may flag the merchant's reliability to the platform. Consistently broken endpoints can affect the merchant's standing in AI platform evaluations. Profile declarations and working endpoints must remain in sync.
---
Related Topics
Parent hub: UCP Technical
Related concepts:
- What Is UCP?
- UCP Compatibility with A2A, AP2, and MCP
- UCP Capability Discovery Explained
- UCP Identity Linking Overview
Breadcrumb:
---
Source Documentation
| Claim | Source | Source Class | Reference | |---|---|---|---| | UCP profile contains business information, service definitions, capability declarations | Google UCP Profile Guide | T1 – Official UCP Docs | https://developers.google.com/merchant/ucp/guides/ucp-profile | | Server-selects negotiation algorithm | Google Developers Blog UCP | T1 – Official UCP Docs | https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/ | | Service capability types: catalog_search, catalog_lookup, cart, checkout, redirect_checkout, identity_linking | FeedBridge Platform Capabilities April 2026 v2.0 / ucp.dev | T1 – FeedBridge Internal / T1 – Official UCP Docs | FeedBridge-Platform-Capabilities-April2026.md | | FeedBridge UCP Dashboard Hub, API Playground, Protocol Compliance scoring | FeedBridge Platform Capabilities April 2026 v2.0 | T1 – FeedBridge Internal | FeedBridge-Platform-Capabilities-April2026.md |