How to Connect Your Joomla Store to an AI Assistant with MCP

“Find me a gooseneck kettle under €50” used to be a search query. Increasingly it is a sentence typed into an AI assistant — and the assistant answers from whatever it can actually reach at that moment. If it cannot reach your catalogue, it answers with someone else’s.

Solidshop Core 1.3.0 shipped a read-only catalog API with a built-in MCP server so that assistants can reach yours. This post is the practical walkthrough: what MCP is, where your store’s endpoint lives, how to connect it to Claude in one command, what a real conversation looks like, and what the assistant is never allowed to see. If you just want the release summary, that is in the Core 1.3.0 notes; if you want the terse reference, it is on the Catalog API & MCP documentation page.

Why catalogue discovery moved

For twenty years the discovery path into an online shop was: shopper types a query, search engine returns links, shopper clicks one. AI assistants insert a step. The shopper describes a need — a gift, a budget, a constraint — and the assistant does the comparing, then hands back a short list with links.

That changes what a store has to be good at. Ranking for a keyword matters less; being machine-readable at answer time matters more. And the referral is worth having: a shopper who arrives from an assistant has already been told what the product is, what it costs, and why it fits — they land on your product page pre-qualified.

The important detail is where they land. Solidshop’s catalog surface has one design rule that everything else follows from: every response carries the canonical URL of the page it describes. There is no Solidshop-hosted marketplace, no intermediary basket, no revenue share. The assistant is a recommendation engine; the transaction happens on your storefront, in your cart, through your checkout, under your terms.

What MCP actually is

MCP — the Model Context Protocol — is the standard AI assistants use to call external tools. A server advertises a list of tools, each with a name, a description, and a JSON Schema for its arguments; the assistant reads that list, decides which tool answers the question in front of it, calls it, and uses what comes back.

The distinction worth internalising is that MCP is a conversation, not a feed. A product feed is a file you generate on a schedule and hope somebody ingests. An MCP server answers the question that was actually asked, at the moment it is asked, at whatever depth the assistant needs — a broad search first, then one product in full detail, then the store’s returns policy, all inside one exchange. Prices and availability are read live, so an assistant cannot quote yesterday’s price.

Under the hood it is unglamorous: JSON-RPC 2.0 over HTTP POST. Solidshop implements the Streamable HTTP transport in stateless form — one request per POST, one JSON response, no session to establish, nothing to keep alive. The server speaks protocol revision 2025-06-18 and also answers clients that ask for 2025-03-26. A GET or DELETE on the endpoint gets a 405, because there is no event stream to open and no session to tear down.

Where your store’s endpoint lives

You do not install or configure anything. The catalog API and its MCP endpoint are part of free core, routed by the Web Services – Solidshop plugin, enabled on install. The endpoint is:

https://www.example.com/api/index.php/v1/solidshop/mcp

That is Joomla’s own API application — the same /api path Joomla core serves its web services from, with the same routing, content negotiation and authentication machinery. Solidshop registers routes into it; it does not hijack site routing or claim a vanity path.

Connecting a store, step by step

Any MCP-capable client connects the same way, because the transport is standard. With Claude Code it is one command:

claude mcp add --transport http my-store \
    https://www.example.com/api/index.php/v1/solidshop/mcp

my-store is just the local label you will see the tools grouped under. There is no key to paste, no OAuth dance, no merchant account to register — the catalogue is public data, so the connection is a URL and nothing else.

Confirm it landed with claude mcp list, then start a conversation and ask something your catalogue can answer. The assistant reads the tool list on connect and works out the rest.

Prefer to look at the wire before pointing an AI at it? The official inspector gives you a UI over the same endpoint — a tool list, argument forms, and the raw JSON of every response:

npx @modelcontextprotocol/inspector@latest

Paste the endpoint URL, choose the Streamable HTTP transport, connect, and click through Tools. This is the fastest way to sanity-check a live store, and it is exactly the smoke test we run against a built package before each release. Note the @latest: the bare package name still resolves to a deprecated v1.

What a real conversation looks like

Here is an unremarkable exchange against a store selling coffee equipment. The shopper says:

“I’m buying a gift for someone just getting into pour-over coffee, budget around €60. What does my-store have that would work?”

The assistant reaches for search first, translating the budget into a filter and the currency into a display request:

→ solidshop_search_products
  { "query": "pour over", "max_price": 60, "currency": "EUR" }

…and gets back a readable summary alongside the structured data (more on that pairing in a moment):

Found 3 products (page 1 of 1):

- Ceramic Dripper 02 — €24.00
  https://kettleandbean.example/shop/brewing/ceramic-dripper-02
- Gooseneck Kettle 1L — €48.00
  https://kettleandbean.example/shop/brewing/gooseneck-kettle-1l
- Pour-Over Starter Set — €59.00 (out of stock)
  https://kettleandbean.example/shop/bundles/pour-over-starter-set

The obvious recommendation is out of stock, so the assistant checks the next best candidate in detail rather than guessing:

→ solidshop_get_product
  { "slug": "gooseneck-kettle-1l", "currency": "EUR" }

Gooseneck Kettle 1L
==================

Price: €48.00 (€48.00 – €54.00)
Availability: in stock
SKU: KB-GN-1000
Brand: Kettle & Bean
Category: Brewing

A 1 litre stainless-steel pouring kettle with a counterweighted
gooseneck spout for slow, controlled pours…

Variants:
- Matte Black — €48.00
- Brushed Steel — €54.00
- Copper — €54.00 (out of stock)

Specifications:
- Capacity: 1.0 L
- Material: Stainless steel
- Stovetop safe: Yes

https://kettleandbean.example/shop/brewing/gooseneck-kettle-1l

One more call, because “it’s a gift” implies a deadline and a returns question:

→ solidshop_get_store_info
  {}

…which returns the store name, storefront URL, contact email and phone, country, default and available display currencies, content languages, and links to the shipping, returns, terms and privacy pages. The assistant then answers in prose — the kettle in matte black at €48, in stock, with the dripper as a €24 add-on to stay under budget, the returns window quoted from the policy page, and a link straight to the product page.

Three calls, no scraping, no stale cache, and the shopper’s next click lands on your storefront.

The five tools

A deliberately small surface. Read-only, store-scoped, no cart, no orders, no writes of any kind:

Tool	What it answers	Arguments
solidshop_search_products	“What do you sell that matches this?” Returns product summaries — name, slug, canonical URL, display price, thumbnail, brand, category, in-stock flag, short description — plus a total/page/pages block.	query, category_id, brand_id, min_price, max_price, in_stock, sort, page, limit
solidshop_get_product	“Tell me everything about this one.” Full description, image URLs, options and variant combinations with per-variant price and availability, specifications from your custom fields, a price range when variants differ, and the canonical URL.	id or slug
solidshop_list_categories	“How is this shop organised?” The category tree with product counts and canonical listing URLs, for narrowing a search.	parent_id
solidshop_list_brands	Brands with product counts and listing URLs.	—
solidshop_get_store_info	Store name and description, storefront URL, country, contact email and phone, default and available currencies, content languages, and policy page links.	—

Three conventions run through all of them. Every product-facing tool takes a language tag, so a multilingual store answers in the shopper’s language from your existing translations. Every price-bearing tool takes a currency code and converts through the same exchange-rate machinery as your storefront’s currency switcher — unknown codes fall back to the store currency rather than failing. And every price arrives as an object (amount, currency, formatted, and a tax_display flag saying whether tax is included), so an assistant never has to parse “€48.00” out of a string or guess your tax convention.

Search sorts by popular, newest, price_asc, price_desc, rating_desc, name_asc or name_desc, returns 20 results per page by default and caps at 50. Over-ask and the request is clamped rather than rejected — agents routinely ask for a thousand.

What an assistant can never see

This is the part merchants actually want to know, so it is worth being precise. The catalog API is a guest. It serves exactly what an anonymous visitor sees in your storefront HTML — published products, categories and brands on public access levels — and the boundary is enforced in shared code that both the REST endpoints and the MCP tools render through, so the two surfaces cannot drift apart.

• Stock is a yes/no answer. Tools return an in_stock boolean, per product and per variant. Never a quantity, never a low-stock band. Your inventory position is competitive information and stays yours.
• No cost prices. Only the display price a shopper would see. Margins are not in the payload in any form.
• No customer or order data. There are no order, cart or account tools, and no route to them — the whole surface is GET-shaped catalogue reads. There is nothing to write, either: no tool in the set can change a single row.
• Hidden stays hidden. Ask for an unpublished or access-restricted product by id or slug and you get the identical “not found” you get for a product that never existed — no existence leak, no accidental confirmation that a draft is sitting there.

And if you want it shut anyway, one switch does it. Under System → Plugins → Web Services - Solidshop there is a single Public catalog access option. Set it to No and the same routes register without the public flag: every endpoint, the MCP one included, then requires a Joomla API token and anonymous requests get a 401. Disable the plugin entirely and the routes stop existing. No custom permission system, no bespoke key format — just Joomla’s own authentication doing its job.

Why open by default is the right call

Shipping this switched on was the deliberate decision, and the reasoning is worth stating plainly: discovery only works if it is open. An assistant browsing on a shopper’s behalf has no account with you and no key to present. If it has to authenticate to see your catalogue, it does not authenticate — it moves on to a store that answers.

The data supports the choice too. Everything the API exposes is already public: it is the same information in your product pages, your XML sitemap and the Product JSON-LD Solidshop already emits on every product page. Structuring it for machines is not a new disclosure, it is the same disclosure in a format that answers questions.

Here is how the field looked when we surveyed it in August 2026, which is the reason this shape exists:

• Shopify exposes an unauthenticated MCP server on every storefront, catalogue-first (search_catalog, lookup_catalog, get_product), with checkout handled as a URL handoff back to the merchant’s own site. That is the reference implementation for buyer-facing discovery, and it validates every bet here: public, catalogue-first, canonical-URL handoff.
• WooCommerce 10.9 (June 2026) ships MCP in developer preview behind a feature flag, at /wp-json/woocommerce/mcp, authenticated with a REST consumer key in an X-MCP-API-Key header. Its seven abilities are read-write merchant operations — query, create, update and delete products, query orders, update statuses, add notes. That is a genuinely useful surface, but it is the merchant’s admin console spoken to an assistant, not a shopper discovery layer. Different quadrant.
• HikaShop ships a UCP plugin (6.4.0) with an optional MCP endpoint, and its six MCP tools are all checkout operations — create, get, update, complete, cancel a checkout, list payment methods. There is no catalogue search over MCP at all; search is REST-only. Every endpoint except discovery requires a merchant-issued X-API-KEY, and the checkout leg additionally needs Stripe Checkout or Worldline Direct plus admission to Google’s UCP approval program.

Read those together and the gap is specific: the half that is key-gated and MCP-absent in the Joomla space is catalogue discovery — which is where the measurable AI traffic actually is. A passing assistant cannot discover a key-gated catalogue at all, because it has no key and no way to ask for one. As far as we can establish, Solidshop is currently the only Joomla shopping cart exposing an open, unauthenticated catalogue over MCP. We would genuinely rather that were not true for long — a standard only pays off when several implementations honour it.

The honest caveat: agents still need your URL

One limitation to be straight about. MCP servers are configured by URL. There is no global registry an assistant consults to discover that your shop exists; someone has to point a client at your endpoint, or an agent has to arrive at your site by some other route and find it. Switching this on does not, by itself, put you in answers.

So treat MCP as the deep layer of a wider AI-visibility posture, not a replacement for it:

• Publish the endpoint. Put the URL somewhere machine-readable and somewhere human-readable — your developer or API page, your llms.txt if you keep one. Anyone who integrates with your shop needs to be able to find it.
• Keep the crawlable layer healthy. Submit the XML sitemap, let the AI crawlers in via robots.txt, and keep the Product JSON-LD on your product pages intact. That is how assistants find you in the first place; MCP is how they answer well once they have.
• Standards are still moving. Tool names carry a solidshop_ prefix in v1 because assistants see tools from many servers side by side, and because the emerging Universal Commerce Protocol catalogue binding was renamed twice inside four months during H1 2026. The field semantics we return are already aligned with it, so adopting the strict binding — the well-known discovery document and the standard tool names — is a thin follow-up rather than a redesign, once the spec settles.

Try it against your own store

If you are on Core 1.3.0, the endpoint is already live. Point an MCP client at it, ask it something a shopper would ask, and watch which of your products it picks — that alone is a surprisingly good audit of your product descriptions and category structure. Thin copy reads as thin copy to an assistant too.

The full reference — REST endpoints, filters, the access switch, and notes on crawl load and rate limiting — is on the Catalog API & MCP documentation page. It arrived alongside custom fields, related products and the currency switcher in Solidshop Core 1.3.0, and like the rest of core it is free.

If you connect a store and an assistant gets something wrong about your catalogue, we would like to see the exchange. Real conversations against real catalogues are how the tool descriptions and payload shapes get better — that part improves with exposure, not with more sample data.