Can an AI agent actually find the right part?
Buyers are increasingly starting their search inside an AI assistant, not a search bar. For parts, that query is always vehicle-specific — “roof rack for a 2026 Ford F-150”— not a generic keyword. Getting from that query to a buyable, fitment-verified kit is a two-step problem, and only one step is fully in the merchant's control.
Two halves — and we're honest about both
Discoverability splits cleanly into a part you can't fully own and a part you can build.
① Discovery — partly out of any vendor's hands
Whether ChatGPT findsRack Attack at all depends on the model's pre-training and its own web-search and ranking at query time. No platform vendor, no agency, no app fully controls it. Over-promising here is a red flag.
What can be done: make the store maximally legible via crawlable landing pages, structured data, and an agents.mdthat teaches agents how to use it — so when an agent does arrive, it knows what it's looking at.
② Instruction + resolution — this IS buildable
Once an agent reaches the store: can it identify the right system for the buyer's vehicle, disambiguate roof type, and complete the transaction? That is the agentic-readiness layer — and it is entirely within scope to build, ship, and measure.
This is where Teifi delivers. The two discovery channels below feed into it; the resolution stack closes it.
What happens when ChatGPT searches “roof rack for a 2026 F-150”
ChatGPT's shopping experience hits Shopify's Global Catalog via the search_catalog UCP action — a semantic + keyword search over product text and ML metadata, with filters for price, availability, shipping, condition, and category (taxonomy). It is a powerful general-purpose product search.
No vehicle-fitment filter exists in the Catalog API. The available filters are price, availability, shipping, condition, shop, and taxonomy category. There is no Year / Make / Model field, no “fits vehicle” parameter.
A generic product record doesn't contain the vehicle. A roof rack product titled “Thule Edge Flush Rail System” doesn't say “F-150 2026” anywhere in its text — because fitment lives in the fitment graph, not on the product record. A raw keyword search finds a roof rack, not the right one.
That is the gap. A catalog with no fitment signal in the agent-readable layer is effectively invisible for vehicle-specific queries — even if the merchant stocks exactly the right part.
Two discovery channels — you need both
“Roof rack for a 2026 F-150” can reach the merchant two distinct ways. They are separate systems with separate rules, and fitment has to be made legible to each independently. Neither one indexes the fitment graph for you automatically.
UCP / Catalog API — the agent-buyable channel
The catalog exposes products, variants, and collections. No metaobjects, no metafields, no fitment field. The catalog-native way to make a vehicle query resolve to buyable items is the Collection: a collection named Roof Racks — 2026 Ford F-150, generated from the fitment graph, means the agent's search_catalog call returns the right bundles. Products carry collections[] in the feed — so membership is queryable.
search_catalog action · no custom API neededMetaobject landing pages — the crawl / AEO channel
A metaobject definition with the renderable + onlineStore capabilities turns each entry into a crawlable page with SEO meta. Shopify lists them in the sitemap via SitemapResourceMetaobject — which is how Google and ChatGPT-browse find a vehicle-specific page. A vehicle metaobject definition means one landing page per vehicle, each telling the story of what fits it.
The limits that shape the strategy
- ·Up to 1,000,000 entries per metaobject definition — a page per YMM combination is technically feasible at scale.
- ·Sitemaps cap at 50,000 URLs per file; Shopify auto-paginates — not a real blocker.
- ·A URL-redirect cap (
canCreateRedirects) can gate publishing pages at volume — plan for it. - ·Crawl and index budgetis the true ceiling. A million thin pages won't rank — and a crawler that finds them all will deprioritize the ones that matter.
The winning play is demand-prioritized pages and collections — generated for the vehicles people actually search — not brute-forcing every Year/Make/Model combination. Quality and relevance signal, not volume.
Kits an agent can read — no Apps SDK required
Rack Attack sells complete kits: towers, fit kit, bars, and lock cylinder as one buyable unit. Each kit is modeled as a schema.org/Product — the sellable thing, not a pile of loose components — carrying image, brand, price, offer, and availability. That is what ChatGPT Shopping, Google AI Overviews, and Perplexity read to surface a product card with an image and a checkout link. The signal has to be on the page, in the right shape, before any AI feature can pick it up.
Per-product pages — /products/[handle]
Each kit page embeds a Product JSON-LD block — image, brand, offer, availability — plus an Open Graph image for rich previews. When an agent browses or cites a kit directly, it lands on a page that is fully machine-readable as a structured entity, not just text.
Vehicle landing pages — /fit/[year]-[make]-[model]
Each vehicle page (e.g. /fit/2024-ford-expedition) lists every fitting kit as its own ProductJSON-LD block and uses the vehicle render as the OG image. This is the “vehicle-selected metadata” layer — how a query like “roof rack for a 2024 Ford Expedition” resolves to a crawled page that names the right kits, with price and availability, tied to that vehicle.
Cross-agent, by default
Because this metadata lives on the store — not inside a platform-specific widget — it works across every AI that crawls or browses: ChatGPT Shopping, Google AI Overviews, Perplexity, Copilot. No ChatGPT Apps SDK integration required for discovery, image rendering, or linking to checkout.
The MCP layer complements, not replaces, this: its tools return productUrl, fitPageUrl, and compareUrl so an agent can link the shopper straight to a structured, checkout-ready page. MCP resolves fitment (which a product feed cannot express); the structured pages handle discovery and rendering. Both are needed.
Apps SDK is only needed if you want a custom interactive product card rendered inside the ChatGPT conversation UI. The metadata path gets you discovery, image, link, and checkout — without it, and across every AI at once.
The instruction + resolution layer
Discovery gets an agent to the door. Resolution gets it the right part. Three surfaces do the work once an agent arrives:
1 · agents.md / llms.txt — the instruction surface
Shopify auto-serves agents.md from the storefront; merchants customize it via templates/agents.md.liquid. For a fitment store, this file tells a visiting agent: what the catalog is, how to query fitment, what vehicle attributes are required, and what disambiguation looks like. Without it, an agent guesses. With it, it knows.
2 · Fitment MCP — precise resolution
The fitment MCP server exposes the vehicle-fitment graph as queryable tools with server-level instructions baked in. It resolves a Year/Make/Model + roof type to the exact system SKUs — and it knows to ask about roof type before guessing, because the disambiguation prompt is part of its system instructions. Any external agent (ChatGPT, Copilot, Claude) can connect and get the right answer.
3 · Bundles — one buyable kit
A rack system is a multi-part kit: towers, fit kit, bars, lock cylinder. Each system is a real Shopify bundle product — one buyable SKU, components expanding at checkout with individual inventory and fulfillment. The Catalog API and the Shop app see one product, not a pile of parts. The agent adds one thing to cart. This is the transaction that closes the loop.
Test it in ChatGPT
Two ways to see this working, depending on which half you're demoing:
A · Interactive — the MCP connector (recommended)
ChatGPT calls our live fitment tools. This is the reliable demo.
https://rackattack.teifi.dev/api/mcp- 1. ChatGPT → Settings → Apps & Connectors → enable Developer mode.
- 2. Create app → paste the URL above → Auth None, Streamable HTTP.
- 3. Scan tools → confirm → Create.
- 4. Ask: “Use Rack Attack to find a hitch for a 2024 Ford F-150.”
Claude.ai “Add custom connector” works with the same URL. Full install guide & configs →
B · Organic — structured-data discovery
No connector. ChatGPT's web/search reads the Product JSON-LD on our vehicle pages and surfaces a card + link.
- 1. In ChatGPT (web/search on), ask about a specific vehicle, e.g. “roof rack for a 2024 Ford Expedition”.
- 2. Or paste a landing page so it reads the structured data: /fit/2024-ford-expedition.
Less deterministic than the connector (depends on the model's index/crawl) — great for the “how it gets found” story, weaker as a guaranteed live demo.
What Teifi delivers — the readiness stack
Every piece of the discovery and resolution chain flows from a single source of truth: the fitment graph in Teifi Parts.
Holds the vehicle-fitment graph. Every collection, landing page, and MCP resolution derives from it. Update the graph — everything else updates.
Keeps Shopify in sync: creates and updates vehicle collections, metaobject landing pages, and bundle products as the fitment graph changes.
Exposes the graph as agent-callable tools with disambiguation built in. Any external agent can connect and get the verified answer.
One source of truth flows into both discovery channels and the resolution layer. The merchant doesn't maintain three systems — they maintain one fitment graph, and Teifi propagates it.
Explore the stack
See how the catalog is structured for agents, connect an external agent live, or walk a vehicle-specific landing page to see the AEO channel in action.