Extensions: Enabling Dynamic Agent-to-Extension Communication

[adamkitain]

The Problem

From what I can tell, UCP extensions currently add fields to checkout data but not net-new functionality. They don't seem to have a way to instruct agents to call an endpoint or MCP server to enable additional functionality.

This feels limiting for use cases like:

• Personalized offers — test discounts that depend on the visitor, not just the product
• Loyalty points — need to fetch the user's current balance
• Fraud checks — need to happen before completing checkout

In these cases, the data is dynamic and user-specific. It seems like you can't just bake it into the checkout response server-side without some kind of call.

What Extensions Look Like Today

"io.example.loyalty": [{
  "version": "2026-01-01",
  "extends": "dev.ucp.shopping.checkout",
  "spec": "https://example.com/ucp/spec",
  "schema": "https://example.com/ucp/schema.json"
}]

The spec is docs. The schema defines data structure. But as far as I can tell, neither one says "call this endpoint to get data."

If I'm understanding correctly, this means the merchant's UCP server has to integrate every extension internally. For Shopify merchants, that would mean Shopify has to build integrations with every extension provider — which doesn't seem like it would scale well.

Proposal: Let Extensions Declare Service Endpoints

What if extensions could optionally declare an endpoint that agents should call?

"io.example.loyalty": [{
  "version": "2026-01-01",
  "extends": "dev.ucp.shopping.checkout",
  "spec": "https://example.com/ucp/spec",
  "schema": "https://example.com/ucp/schema.json",
  "service": {
    "type": "mcp",
    "endpoint": "https://mcp.example.com/loyalty",
    "trigger": "before_checkout_create",
    "tools": ["get_loyalty_balance", "redeem_points"]
  }
}]

Or for REST:

"service": {
  "type": "rest",
  "endpoint": "https://api.example.com/v1/enrich",
  "trigger": "before_checkout_create"
}

How It Might Work

1. Agent fetches /.well-known/ucp from merchant
2. Agent sees extension with a service field
3. Before creating checkout, agent calls that service with cart/session context
4. Service returns personalized data
5. Agent includes that data in the checkout request

Agent                    Extension Service              Merchant
  │                            │                           │
  │  GET /.well-known/ucp      │                           │
  │ ────────────────────────────────────────────────────────>
  │                            │                           │
  │  { extensions with service endpoints }                 │
  │ <────────────────────────────────────────────────────────
  │                            │                           │
  │  Call extension service    │                           │
  │ ──────────────────────────>│                           │
  │                            │                           │
  │  { personalized data }     │                           │
  │ <──────────────────────────│                           │
  │                            │                           │
  │  POST /checkout-sessions (with extension data)         │
  │ ────────────────────────────────────────────────────────>

Possible Triggers

Extensions could maybe declare when agents should call them:

Trigger	When	Example
on_discovery	When agent first sees the extension	Fetch user's loyalty tier
before_checkout_create	Before POST /checkout-sessions	Get personalized pricing
before_checkout_complete	Before payment	Final fraud check
after_order_created	After order confirmation	Attribution tracking

Why This Might Be Useful

This seems similar to how Shopify checkout extensibility works:

1. Developers build extensions with defined capabilities
2. Merchants install them
3. Checkout calls extension logic at the right points

The difference here: instead of the merchant's server calling extensions, the agent calls them directly. If I'm thinking about this correctly, that would mean:

• Extension providers could operate independently
• Agents could get real-time, personalized data
• No need for every merchant platform to integrate every extension

Example: Targeted Offers

"io.intelligems.shopping.targeted_offers": [{
  "version": "2026-02-01",
  "extends": "dev.ucp.shopping.checkout",
  "spec": "https://intelligems.io/ucp/spec",
  "schema": "https://intelligems.io/ucp/schema.json",
  "service": {
    "type": "mcp",
    "endpoint": "https://mcp.intelligems.io/offer",
    "trigger": "before_checkout_create",
    "tools": ["get_offer"]
  }
}]

Agent calls the service:

// Request
{
  "tool": "get_offer",
  "arguments": {
    "merchant_id": "example-store",
    "product_ids": ["gid://shopify/Product/123"],
    "visitor_id": "anon_abc123"
  }
}

// Response
{
  "session_id": "ig_sess_xyz",
  "assignments": [{
    "product_id": "gid://shopify/Product/123",
    "test_id": "holiday_2026",
    "variant": "10pct_off",
    "price": 8999,
    "original_price": 9999
  }]
}

Prior Art

I noticed Discussion #127 (Product Safety Extension) seems to describe something like this — an MCP endpoint that agents can query for recall data before checkout. Not sure if I'm reading that correctly, but if so, this proposal would basically formalize that pattern.

Open Questions

1. Am I misunderstanding how extensions currently work?
2. Should calling these services be required or optional for agents?
3. How would auth credentials flow from merchant → agent → extension?
4. Should there be a registry of extension services?
5. How should we handle it when a service is down?

---

Would love to hear if I'm on the right track here, or if I'm missing something about how this is supposed to work. Are there concerns about agents calling external services directly?