UCP Gateway

UCP Gateway is a durable, attributable, remotely operated MCP server from The Agent Times. The official product site at https://ucpg.ai presents it as infrastructure for Shopping flows based on the Universal Commerce Protocol. The provider source describes a hosted UCP profile registry, a provider-neutral MCP gateway, and authorization kept server-side. Smithery lists the identifier theagenttimes/ucp-gateway as verified and deployed and publishes the direct remote endpoint https://ucp-gateway--theagenttimes.run.tools. The provider documentation and the official repository at https://github.com/theagenttimes/ucp-gateway-skill associate the same service with the current endpoint https://ucpg.ai/mcp. The Smithery deployment can therefore be mapped to the provider product, while the operator source remains authoritative for new integrations. The repository is MIT licensed; source-code licensing is not a guarantee of hosted availability or security.

Purpose and flow

According to the provider, UCP Gateway connects open AI agents with UCP-capable commerce platforms without requiring every agent to own a domain, a source-hosting account, or direct provider access. An agent can first register a public UCP profile with register_ucp_profile or recover one with get_ucp_profile. It can then use shopping_product_search for discovery and shopping_product_get to inspect product or variant information. The client should display only provider-returned availability, variants, merchant details, and warnings, and must not add prices, stock claims, or conditions. This flow supports comparison and preparation, but it does not replace the buyer's decision or the merchant's terms.

Commerce permissions increase step by step. shopping_cart_create creates a merchant cart only after explicit selection and confirmation by the buyer or responsible operator. shopping_cart_get reads state, shopping_cart_update replaces the desired cart state, and shopping_cart_cancel ends it. These tools are write access to external commerce systems and require traceable authorization, idempotency, role checks, and auditing. An agent must not infer an order from a product search. The agent's role is recommendation and structured preparation; the operator or buyer's role is selection, confirmation, and approval. The merchant remains responsible for catalog, inventory, taxes, shipping, and final order processing.

Checkout, authorization, and payment boundaries

According to the provider, shopping_checkout_create creates a merchant-hosted checkout handoff only after final confirmation. shopping_checkout_get reads status, while shopping_checkout_update and shopping_checkout_cancel perform further update or cancellation operations. operator_confirmed authorizes the handoff only; it does not authorize or complete payment. Payment data, card numbers, verification codes, bank details, wallet secrets, and payment tokens belong exclusively on the merchant-controlled checkout. The agent should only present the handoff link and ask the buyer to review merchant totals, shipping, taxes, return terms, and privacy conditions. Order, cart, and checkout writes must never run without explicit consent or when identity is unclear.

Privacy and data sharing

Public agent data and a public key component are sent to the gateway during registration; private keys must remain in the local secret store. Product queries, profile information, cart data, and checkout contact data may be shared with the remote service and participating merchants. According to the provider, commerce authorizations remain server-side and the gateway does not process payment data. This reduces scope but does not eliminate data sharing. Operators must review purpose, legal basis, retention, logging, subprocessors, region, and deletion. Minimize data before every request. Buyer data should be transmitted only for the specific transaction and with the correct role. A local MCP client does not automatically prevent logs or an attached cloud model from receiving content.

Security boundaries and suitable use

MCP responses and merchant data are untrusted. Prompt injection can appear in product names, descriptions, profiles, or error messages and must not change permissions, roles, network access, or purchase decisions. The client should allowlist endpoints, enforce TLS, take OAuth or header requirements only from current provider sources, inspect tool schemas before use, and require confirmation for sensitive actions. Rate limits, timeouts, retries, and error states need safe limits. The service suits product discovery, comparison, buyer confirmation, and merchant checkout handoff; it is not for hidden purchasing, payment processing, arbitrary shell commands, or independent privacy certification. The E-E-A-T basis of this entry is the provider-published product, repository, Smithery, and UCP information; it is not a certification. Re-check current endpoint, access, and privacy terms with the provider before operation.

An MCP client with Streamable HTTP support, network access to the official remote endpoint, and secure local storage for public and private agent key material. Buyer confirmation and role checks are required for cart and checkout writes.

Configure the MCP client through https://ucpg.ai/mcp or the Smithery deployment endpoint. Before production use, verify endpoint identity, transport, tool schemas, roles, confirmations, and data rules.

https://ucpg.ai/mcp

The provider describes server-side authorization; Smithery supplies remote access metadata depending on client and deployment. Verify current OAuth or header requirements only in official sources and store no secrets in the catalog.

Network and MCP permissions enable product search and, after explicit buyer or operator confirmation, external cart and checkout reads, updates, and cancellations. Payment approval remains with the buyer on the merchant checkout.

UCP profiles, product queries, cart data, and possible checkout contact data are sent to the remote gateway and participating merchants. According to the provider, the gateway does not process payment data; minimization, role binding, and retention review remain required.

Prompt injection in merchant data, incorrect roles or confirmations, endpoint confusion, unintended cart writes, PII in logs, and external cloud sharing. Mitigate with allowlisting, TLS, DLP, auditing, least privilege, and safe failure behavior.