Every structured part of the Universal Commerce Protocol answers a question someone could predict in advance: what do you sell, what does this cost, can I buy it, where is my order. Buyers mostly don't ask predictable questions. They ask whether a sale item can be returned, whether a jacket is warm enough for a Scottish winter, whether the shop delivers on Saturdays.

ask is the proposal that gives those questions a home in UCP. It is not in any released version yet. It is an open pull request, #538, from Shopify's Ilya Grigorik, and it has become one of the Shopping Tech Council's priority items in September. This post explains what ask does, how the draft works, where it fits in UCP, and what the council is still deciding.

#What is the UCP ask capability?

ask is a proposed shopping capability, dev.ucp.shopping.ask, for natural-language questions and answers between an agent and a business. A platform, acting for the buyer, sends a free-form question. The business sends back a text answer, and optionally links to the pages and products the answer refers to.

The draft describes it as "the open-question complement to UCP's structured shopping capabilities." The rule for which questions belong to it is simple: a question that maps to a dedicated operation is owned by that capability; ask covers everything else. Stock and prices belong to catalog. "Can I return this if I bought it in the sale?" belongs to ask.

The use cases the draft lists are the ones every store's customer service team would recognise:

• Product questions: fit, materials, compatibility, comparisons.
• Policy questions: returns, shipping, warranty, refunds.
• FAQ and how-to: store hours, delivery timelines, accepted payment methods.
• Pre-purchase clarification about a specific item.

#Why UCP needs it

The gap is real, and it shows up in our own measurements. When Shopify moved its cart tools from the old Storefront MCP server to UCP at the end of August, one tool had no UCP successor: the one for searching a shop's policies and FAQs. Our look at that migration found it was the only tool still listed on the old endpoint, and that UCP had no capability for asking a store a free-form question. ask is the proposal that closes that gap.

The council minutes record the same origin. At the 11 September Shopping Tech Council meeting, Ilya Grigorik explained that the design "evolved from the limitations of Shopify's storefront MCP tools", and Amit Handa described ask as a high-priority feature that lets business agents communicate over UCP "without connecting entire ERP and CRM systems," with strong demand from retailers including Target and Walmart. ask is also first on the list of high-demand items Shopify brought to the council's Q4 planning.

#How ask works in the current draft

The draft keeps the contract small. One operation, one request, one response.

The request carries a query, which is the only required field. It can also carry:

• ids, to ground the question in specific resources: product and variant IDs as the recommended minimum, and optionally a SKU, handle, URL, cart or checkout the caller holds.
• conversation, to continue an earlier exchange.
• The same context, signals and attribution blocks other UCP capabilities use.

{
  "query": "Is this jacket warm enough for winter?",
  "ids": ["https://business.example.com/products/winter-jacket"]
}

The response (abridged below) carries an answer in plain text, Markdown or HTML, plus optional links, a conversation and messages:

{
  "answer": {
    "plain": "Yes — it's insulated for sub-zero conditions and rated for harsh winter use."
  },
  "conversation": { "id": "conv_9a3f2e7b" }
}

A few design choices stand out.

"Can't answer" is still an answer. Every successful response carries a populated answer. If the business can't answer the question, the answer says so in plain words, not through an error code or a non-2xx status. An agent never has to interpret a failure code to learn that a shop doesn't know something. (Business-level errors such as insufficient_scope, when a question needs a scope the caller's token lacks, still go in messages.)

Answers point at sources. A business SHOULD return a link for each resource the answer names. Links have a type, with well-known values for refund_policy, shipping_policy, privacy_policy, terms_of_service and faq. When a link points at a UCP resource such as a product, it SHOULD also carry that resource's id, so the agent can act on it through catalog or cart without having to pull the product back out of the prose.

Conversations are optional. A business MAY issue a conversation object with an opaque id and an optional expires_at. The platform replays it to continue, or leaves it out to start fresh. The draft says platforms MUST NOT parse or construct the id.

Access follows the caller's credential. With no credential, ask answers from public information. A cart or checkout ID the caller holds can act as a bearer reference, and a business may require more. With an authenticated user token (the dev.ucp.shopping.ask:read scope), a business MAY personalise, for example with member pricing.

Disclosures can't be hidden. A warning with presentation: "disclosure" is a notice the platform MUST NOT hide or dismiss, such as an allergen or safety notice.

In the draft, the capability binds to REST as POST /ask and to MCP as a tool called ask_business.

#What the council is still deciding

Amit Handa's review on the PR in mid-September is a thorough design review and worth reading in full. It frames six design questions around one tension: ask puts "a stateful, LLM-backed, natural-language channel" next to UCP's deterministic commerce primitives. The questions:

1. The side-effect boundary. Nothing in the schema stops a business wiring "add two of these to my cart" to a real cart change behind ask. If that ships, the review warns, platforms will come to depend on an "untyped shadow protocol" that skips idempotency, mandates and explicit buyer consent.
2. Rendering. A single text answer suits an agent reading it. It fits less well when a platform wants to show a size chart or product images to a person.
3. Retries. LLM-backed answers can take tens of seconds, so timeouts and retries will be common. In the current draft, the REST binding accepts no idempotency key, so a retry on a live conversation could run twice and log the question twice.
4. Conversation binding. A conversation started with a signed-in buyer's token could be continued without it, carrying personalised context across a boundary it shouldn't cross.
5. Prompt injection in both directions. Untrusted text flows from the buyer's agent into the merchant's model and back again.
6. Identifier types. The platform treats IDs as opaque, so how does it know whether a linked id is a product or a variant?

The 18 September meeting settled the direction on the biggest of these. Ilya Grigorik said ask "provides unstructured Q&A verbs and must not subsume other tools such as cart creation", which stay the responsibility of the calling agent, and Amit Handa agreed. On prompt injection, the group agreed all external content must be treated as untrusted data and sanitised before an agent acts on it, and that explicit guidance in the specification resolves the concern. Conversation IDs follow the same contract as carts: the merchant controls retention, or skips conversations entirely. The council's next step is a dedicated deep-dive session on the technical design.

That is how a protocol should treat its first natural-language channel: the author and the reviewer arguing about the boundary in public before anything ships.

#Where ask fits in UCP

ask informs; it doesn't do anything. It sits beside the structured capabilities rather than on top of them, and the hand-off between them is the id on a link. A typical journey might run:

1. The buyer asks whether a jacket is warm enough. ask answers and returns a link carrying the product's id.
2. The agent resolves that id through catalog and adds the item through cart.
3. The buyer completes the purchase through checkout.

The conversation happens in ask. Every change of state happens in catalog, cart and checkout, which are typed, signed and idempotent. The design depends on keeping that split, which is why the council's review spent so long on the boundary.

#What this means for merchants and agent builders

For merchants and platforms: there is nothing to implement yet. ask is a proposal under review, and the request and response shapes above may change. Of the 17,764 manifests our crawler currently verifies, none declares dev.ucp.shopping.ask, which is what you would expect for a capability that hasn't merged. If you run a policies or FAQ assistant today, the draft is still worth reading now. Its best-effort contract, source links and disclosure warnings describe what a good answer to an agent looks like, spec or no spec.

For agent builders: plan for two different kinds of input. Structured responses come with types and a defined owner. ask answers are prose from a system you don't control. Treat them as data to show or summarise, never as instructions to follow, and act through catalog, cart and checkout using the id on a link rather than anything the text says.

#What to watch

• The council's deep-dive session on ask, and whether the no-side-effects rule becomes normative text in the spec rather than a stated position.
• The security guidance the group agreed to add on untrusted content.
• Retry handling for multi-turn conversations, and whether both transports get the same idempotency story.
• The first manifest to declare dev.ucp.shopping.ask once it lands. You can check what any store declares with the UCP Checker.

The next UCP release is targeted for early December or January, according to the council's roadmap discussion. Whether ask makes it is still open. Our September State of Agentic Commerce covers the rest of that roadmap.

#Frequently asked questions

Is ask part of UCP today? No. dev.ucp.shopping.ask is proposed in pull request #538, which is open and under Technical Council review. It is not in v2026-08-25 or any earlier release.

Can ask add items to a cart or complete a purchase? Not by design. At the 18 September Shopping Tech Council meeting, the proposal's author stated that ask must not subsume cart creation or other tools, which stay with the calling agent. Making that rule normative is part of the open review.

How does ask relate to Shopify's policies and FAQ tool? Shopify's legacy Storefront MCP server offers a tool for searching shop policies and FAQs that has no UCP equivalent. The council minutes record that ask grew out of the limitations of those storefront MCP tools.

Will ask answers be personalised? They can be. With an authenticated user token and the dev.ucp.shopping.ask:read scope, the draft lets a business return personalised answers such as member pricing. Without one, answers draw on public information.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• UCP PR #538: ask capability for natural-language Q&A (open)
• Shopping Tech Council minutes, 11 September 2026
• Shopping Tech Council minutes, 18 September 2026

Related coverage: Shopify's Storefront MCP after August 31 · What's new in UCP v2026-08-25