MCP product search for retailers: an implementation checklist

An assistant-facing product tool needs a clear contract for what it can read, which retailer it represents and how current its answers are. Use this checklist to scope a product-discovery integration and test its boundaries. Keep public product-information connectors separate from tools authorised to access a retailer’s live catalogue.

Establish the access boundary first

Decide whether the tool serves public product information, an authenticated business workspace or a retailer-authorised shopping experience. These are different access scopes. PA's public discovery card says its public server exposes product, proof, planning and sample content rather than a production retailer catalogue or checkout. The connection guide separately describes authenticated RevenueOS access and a planned DiscoveryOS connector.

For your own proposed integration, name the retailer, permitted stores and allowed action class. Search results should not become implicit authority to edit prices, reserve stock or place orders. Decide where an assistant must hand the shopper back to a retailer-controlled experience.

Define the smallest useful product contract

A search request might carry a query, permitted store, currency, language, explicit filters and result limit. The response should provide stable product and variant identifiers, a retailer product URL, a clear price basis, availability status and the time each changing value was checked. The sample tool in this checklist is a proposed design, not an existing PA endpoint.

Separate catalogue knowledge from current commercial facts. A description may remain useful longer than stock or a promotional price. When live values cannot be verified, return a clear status or a safe retailer link rather than presenting stale data as current. If results include paid placement, preserve the relevant disclosure in the response contract and shopper presentation.

Apply identity and permissions at the server

Do not let caller-supplied store identifiers expand access beyond the authenticated scope. For protected MCP services, the official authorization guidance requires tokens intended for the receiving service and prohibits passing incoming tokens through to upstream systems. Implement the current protocol requirements with the security team rather than inventing a shared-token shortcut.

Treat product descriptions and retrieved text as data, not instructions that can alter tool permissions. Exclude secrets and unnecessary customer information from responses and logs. Keep audit identifiers useful for support without turning search logs into an uncontrolled copy of sensitive business data.

Test failures as carefully as successful searches

Use fixtures for an exact product code, an ambiguous query, a constrained variant and no eligible result. Add permission failures, stale stock, a price-service timeout and malformed tool arguments. Agree a latency budget for the actual shopper journey, then measure the complete path rather than only the search engine.

Review the assistant's final answer as well as the raw response. It should preserve eligibility, price basis, disclosure and uncertainty. A technically valid tool response is insufficient if the presentation turns it into an unsupported promise. Finish with an owned rollout plan, monitoring and a route back to the retailer when the integration cannot answer reliably.

Illustrative example

{"label":"Synthetic MCP-oriented contract; proposed tool, not a live PA API","tool":"demo_search_catalogue","permission":"read authorised catalogue only","example_price_minor":12900,"currency":"GBP","display_price":"£129.00","write_or_payment_permission":false}

Downloads

• pa-proposed-retail-search-tool.json (illustrative template)
• pa-retail-mcp-readiness.csv (illustrative template)

Sources

• Particular Audience Public Discovery Card, checked 2026-10-25
• Connect Particular Audience, checked 2026-10-25
• MCP Authorization Security Considerations, checked 2026-10-25

How Particular Audience does it

• Connection guide
• Agentic commerce

Frequently asked questions

Does PA’s public MCP server search a live retailer catalogue?

The public discovery card explicitly separates public product, proof, planning and sample content from production retailer endpoints. Do not treat a sample search or practice response as live stock, pricing or customer data. A retailer integration needs its own authorised scope and agreed technical contract.

Can a product-search tool change prices or place an order?

Only capabilities explicitly authorised and implemented for that environment can take actions. This checklist scopes discovery reads and a retailer-controlled handoff. A returned product or price does not grant write or payment authority, and a proposed request schema is not proof that an action exists.

Will an MCP integration make products appear in every assistant?

No such outcome is established here. Tool availability, authorisation, discovery and presentation depend on the specific client and deployment. Validate the intended assistant journey and its error handling; do not promise third-party inclusion, ranking or commercial results simply because a server implements MCP.

Templates and checklists · All guides