KaliCart Bridge – Agentic Commerce Catalog, ChatGPT Product Feed & MCP

Make your WooCommerce catalog ready to be read and verified by AI shopping systems.

KaliCart Bridge gives you an immediate catalog-readiness report inside WooCommerce: it identifies products with missing images, brand, usable description, category, price or SKU, and links you directly to the native Products screen to fix them. It then exposes your live catalog in a structured form for AI agents and can generate a validated product feed ready for ChatGPT merchant submission.

No LLM runs on your site. No cloud service or customer data is sent anywhere by default. Prices, availability and product changes remain live on your WooCommerce store.

The plugin does not promise traffic, ChatGPT placement or merchant approval. It prepares and exposes your catalog; OpenAI controls access to its own shopping surfaces and delivery channel.

What you get after installation

• A catalog-readiness report with actionable product fixes.
• A current, structured catalog API for agents that reach your store.
• An optional ChatGPT feed, validated before export.
• Optional inclusion in KaliCart’s federated catalog, only with explicit consent.

Documentation: https://bridge.kalicart.com/docs/

For developers and AI integrations

What it does:

• Exposes a /discovery endpoint — the single entry point any agent needs to understand your catalog
• Provides /catalog/search, /catalog/products, /catalog/product/{id}, /catalog/categories endpoints
• Exposes a Model Context Protocol (MCP) server at /wp-json/kalicart/v1/mcp (JSON-RPC 2.0) so MCP-capable agents can call the catalog as tools — same data as the REST endpoints, no API key
• Gives AI chatbot and assistant builders a structured catalog source to ingest or call, instead of scraping product pages
• Computationally normalizes product data: prices (min/max for variables, sale %, discount), stock, gender inference, color family mapping, size type detection
• Exposes WooCommerce shipping-zone policy for agent reasoning; checkout remains the final authority for exact destination/cart shipping cost
• Exposes active product/category-compatible coupons as conditional checkout savings; coupons never replace the catalog price
• Category tree nodes include direct products_url and search_url_template fields so agents can navigate without constructing URLs manually
• Dashboard issue cards and suggestions link to filtered product lists for direct remediation
• Uses your merchant taxonomy — no global remapping, products stay in your WooCommerce categories
• Injects a <link rel="kalicart-agent"> in your site <head> for agent auto-discovery
• Adds an “agent ready” badge in the footer
• Injects Allow: /wp-json/kalicart/ in robots.txt
• Generates /kalicart-sitemap.xml linked from the WP sitemap index
• Shows a catalog health dashboard in wp-admin with quarantine tracking and improvement suggestions

What it does NOT do:

• No LLM calls
• No cloud dependency for core functionality
• No data sent anywhere outside your server by default — the optional Federated Catalog and provider-specific distribution channels require separate explicit actions (see “External services” below)
• No API key required for public endpoints

Normalization engine:

• Price: regular, sale, current, discount %, currency — variable products get min/max ranges
• Stock: status, in_stock bool, quantity if managed, backorder policy
• Gender: inferred from pa_gender attribute, category paths, tags, product name (multilingual keywords: IT/EN/FR/DE/ES)
• Color: mapped to 13 color families via keyword matching on pa_color/pa_colore and product metadata
• Size: detected from pa_size/pa_taglia, type auto-detected (clothing S/M/L, numeric EU, shoes EU half-sizes)

Catalog health / quarantine:

Products are scored 0–100 based on: title quality, description length, category assignment, price validity, image presence and SKU presence. Quarantine is reserved for blocking computability issues: ambiguous/too-short titles, missing or very short descriptions, missing real categories, and missing or zero prices. Missing images and SKUs remain clickable improvement suggestions but do not quarantine products.

Checkout sessions (optional):

When enabled in WP Admin → KaliCart → Settings, agents can create checkout sessions containing one or more products. Each session returns cart_url (lands on WooCommerce cart for review) and checkout_url (goes directly to checkout). Sessions expire after 30 minutes. No OAuth, no PII, no payment on the agent side.

Model Context Protocol (MCP) endpoint:

The same read-only catalog is also exposed as an MCP server at /wp-json/kalicart/v1/mcp (JSON-RPC 2.0 over HTTP POST). MCP-capable agents and assistants connect to it and call the catalog as tools: search_products, list_products, get_product, list_categories, get_meta. It is read-only and needs no authentication, exactly like the public REST endpoints — it adds a second transport, not new data. No LLM, no external calls. Checkout and payment are never exposed over MCP.

ChatGPT Product Discovery Feed

1. Configure and generate. Optionally set your return policy URL and target countries (derived from your WooCommerce selling locations) and, for own-label stores, a brand fallback. The plugin validates every row against the current OpenAI Product Feed specification – neither looser nor stricter: required fields are required, optional fields are included only when known and valid, products without image or brand are excluded and counted, and a failed run never destroys the last valid feed.
2. Apply at chatgpt.com/merchants. Application and approval are required and decided by OpenAI.
3. Deliver after approval. Upload the generated file (stable filename, jsonl.gz supported) on the delivery channel OpenAI assigns. The plugin regenerates a full daily snapshot via WP-Cron.

No acceptance or visibility is guaranteed by the plugin: approval, delivery access and final ranking are determined by OpenAI.

External services

This plugin works fully standalone. It connects to one external service only after an explicit administrator action in WP Admin → KaliCart Bridge. Federated Catalog participation and each provider-specific distribution authorization are separate choices; a provider channel cannot be authorized until the Federated Catalog is active.

Service: KaliCart Global (https://dashboard.kalicart.com)

When data is sent: When an administrator activates or revokes the Federated Catalog, requests its external-visibility status, or explicitly grants or revokes a named federated distribution channel. After a provider receipt exists, opening the plugin page requests its processing status using the public site URL and consent ID. A provider receipt that could not be delivered is sent again after about 1 minute, 5 minutes, 30 minutes, 2 hours and 12 hours, then once a day until KaliCart Global has received or rejected it (retries use WP-Cron). When this installation already has a verified identity, provider receipts are signed with that identity; the compatibility path for an older KaliCart Global or an unavailable local identity verifies them against the public discovery document. While the Federated Catalog is active, the plugin also proves this installation’s identity once and then sends a signed status signal about once a day; it sends a signed consent-off signal when federation is revoked. Deactivating or deleting the plugin performs local cleanup only and sends no request. Nothing is sent merely because the plugin is installed or activated.

What is sent: Federated Catalog activation, revocation and visibility checks send the site’s public URL (e.g. https://yourstore.com). A provider authorization receipt additionally sends its consent ID, provider, purpose, action, UTC timestamp, plugin and terms versions, consent locale, and SHA-256 evidence-chain hashes. A signed receipt also carries a random one-time request ID, the site’s host and the existing random installation ID. The administrator’s WordPress user ID and localized consent text remain only in the store’s local evidence log. The identity signals send the site’s host, a random installation ID, this installation’s public key, a one-time verification code, the consent state and the consent text version, the plugin, WordPress and PHP versions, the status of the public catalog files (sequence number, file address and hashes, product count, whether complete, generation time) and whether the store is in WooCommerce “coming soon” or WordPress maintenance mode; when the plugin itself hit a fatal error, a normalized error code, the time and a short non-reversible hash – never the error message, file paths or stack traces. The private key never leaves the site. No customer, order, payment, credential or API-key data is transmitted.

What the service does: The URL tells KaliCart Global your store wishes to be discovered. KaliCart Global periodically reads your already-public catalog and includes it in federated agent search. For a separately authorized provider channel, KaliCart Global stores the minimal receipt and, when it is signed, verifies it with the public key already bound to that installation; the compatibility path verifies the matching authorization against the store’s public discovery document. It only reads public catalog data; it never writes to your store. Since 1.0.139 it can also read the catalog from public files this plugin writes on your site, in /.well-known/kalicart/ (or in wp-content/uploads/kalicart/ when that folder cannot be written): the same public catalog data as the catalog API, without exact stock quantities. The files are updated when products are edited and deleted when the Federated Catalog is revoked or the plugin is deactivated or deleted. In its answer to the status signal, KaliCart Global reports how it reads the catalog; the plugin stores that report locally and shows it only in the plugin page and in Site Health. If the plugin folder is removed outside WordPress, the catalog files remain on the site, and KaliCart Global does not use them without a current signed status.

Retention: KaliCart Global keeps the current state while the store takes part; events and reading reports for 90 days, then only anonymous daily totals without site address, URL or IP address; server logs containing IP addresses for 30 days. 30 days after revocation or removal, the catalog, its copies, the events and the current identity state are deleted. Only a minimal revocation record (site address and revocation date, so that the store is not listed again by mistake) and the history of the installation’s signing keys (public keys and verification dates, kept as a security record) remain. The Federated Catalog consent receipt stays in the store’s WordPress database until the plugin is deleted and is not sent to KaliCart Global.

Privacy notice: https://bridge.kalicart.com/privacy/
Terms / documentation: https://bridge.kalicart.com/docs/