Your Metafields Are Invisible to the Agent

The standard advice for getting your catalog ready for AI is some version of "enrich your product data." Fill in materials. Add fit notes. Put it in metafields. It is good advice in the way that "write better copy" is good advice, and it skips the same step: nobody tells you where the data has to land to be readable.

So we went and read the specs. Shopify's agent-facing catalog, and the Agentic Commerce Protocol feed that ChatGPT ingests. Two different surfaces, built by two different companies, and they made the same structural decision. Both filter on taxonomy-normalized values. Neither one can see a custom metafield.

If you have been writing enrichment into custom.material, an agent filtering for cotton cannot reach it. Not because your data is bad. Because it is in the wrong shape.

What Shopify's catalog MCP actually exposes to agents

Shopify ships a Global Catalog MCP endpoint on the storefront at /api/ucp/mcp. It exposes three tools to any agent that finds it: search_catalog, lookup_catalog, and get_product. There is also an agents.md.liquid theme template with an auto-populated agents object carrying the store name, the UCP discovery URL, the MCP endpoint, and the sitemap.

Worth sitting with for a second: on Shopify, this is provisioned for you. You did not build it. Your competitor did not build it either. Protocol conformance is the floor, not an edge, which is the whole reason we score it the way we do in our UCP test: plumbing is worth 30 points and the data flowing through it is worth 70.

The interesting part is search_catalog, because it draws a hard line between two kinds of input. filters are hard exclusions. Fail one and the product is dropped from the result set entirely. context holds soft signals like shopper intent, country, currency, and language, which influence ranking but never remove anything.

Here is what an agent can pass as a hard filter.

Look at attributes[]. That is the entire structured attribute surface an agent gets to filter on, and it is narrow. Color, Size, Target gender. Everything else you know about your product has to survive as prose in the description and hope the model reads it.

Where those attribute values come from

This is the part that matters, and it is why custom metafields do not work here.

Shopify's Standard Product Taxonomy is an open-source, MIT-licensed category tree with attributes attached to each category. The May 2026 release alone added over 2,000 categories and over 4,000 attributes. Categories carry human-readable handles that resolve to IDs like gid://shopify/TaxonomyCategory/aa-8. Attribute values resolve to gid://shopify/TaxonomyValue/N.

Those taxonomy attributes surface on your products as metafields in the Shopify-reserved shopify namespace, scoped by a category constraint. Real ones you can go look at right now: shopify.color-pattern, shopify.target-gender, shopify.age-group, shopify.fabric, shopify.jewelry-material.

The type is what makes them work. They are product_taxonomy_value_reference fields, which means the value is not a string you typed. It is a pointer into a closed vocabulary. Shopify owns the schema, you own the values, and "Navy" means the same thing on your store as it does on every other store.

That normalization is the whole point. An agent filtering attributes[{name: "Color", value: "Blue"}] is doing a lookup against enum IDs. It is not doing string matching, and it is certainly not reading your description.

A product missing shopify.color-pattern cannot be reached by a color filter, no matter how clearly the first sentence of the description says navy.

So custom.material is not a worse version of shopify.fabric. It is a different kind of object. One is free text in a namespace the filter path does not consult. The other is a constrained reference the filter path is built on. They are not interchangeable and no amount of enrichment quality closes the gap.

One more detail worth knowing, because it catches people: metafield definitions carry an access object, and for app-owned definitions the storefront access defaults to hidden. Enrichment written by an integration is invisible to the Storefront API unless somebody explicitly set access.storefront to PUBLIC_READ. Two different ways to write perfectly good data into a place nothing can read it.

The feed side makes the same call

The Agentic Commerce Protocol is the OpenAI and Stripe spec behind ChatGPT's product surface. Its feed is not the flat CSV people still describe in blog posts. Offline ingestion is a metadata.json file plus a products.jsonl file with one product object per line, submitted as a full replacement.

The Product object itself is thin. It requires only id and variants[]. Almost everything interesting lives on the variant: price, list_price, unit_price, availability with a status enum, barcodes[] typed as GTIN or UPC or EAN, condition[], variant_options[], and seller with typed policy links.

And then categories[], where each entry carries a value plus a taxonomy discriminator. The allowed values are google_product_category, shopify, and merchant.

Read that field carefully, because it is doing something specific. The spec is asking you to declare which vocabulary you are speaking. merchant is the escape hatch for your own internal categories, and it is the one that tells the ingesting system your labels do not join to anything. The two options that do join are both taxonomies.

Same design decision, different company. Structured retrieval runs on shared vocabularies. Your private ones are accepted, stored, and ignored for anything that requires comparing you to somebody else.

The number that should change your plan

Profound published two pieces of observational research on ChatGPT Shopping this summer, and one number in them is more actionable than anything else in either article.

Across roughly one million sampled shopping product offers over a 30-day window, 88.29% of product offer instances were derived from crawled product pages rather than from an integrated feed. That alone is interesting. The number that matters is the next one: among the 150 merchants who had already integrated a feed, 75.81% of their offers were still derived from their web PDPs.

Integrating a feed does not replace your product pages. Three quarters of the time, on merchants who did the integration, ChatGPT was still reading the page.

The mechanism shows up in their field-presence data, and it is the most useful table in either article. Feeds and PDPs carry almost disjoint field sets.

Feeds carry identity and commercial framing. Pages carry delivery and availability. Neither surface carries the other's fields, so the shape of the problem is not "which one should I invest in." You need both, and they are doing different jobs.

Profound also reports that feed-derived citations land in the rank 1 offer position roughly 99.9% of the time across more than 100,000 instances, and that feed share of retrievals grew from 4.3% to about 20% since they began tracking in November 2025. Worth knowing. Worth also knowing that this is observational data, not a controlled test. Nobody changed a product page and measured what happened, including us. Treat rank correlations as a map of the terrain, not a lever you have pulled.

One of their own findings makes the point. Median product-name length on top-ranked cards versus bottom-ranked cards differed by exactly 0.0%, and the article still recommends improving product naming. Their two strongest correlations are machine-assigned tags and review count, which are respectively not yours to set and heavily confounded with how popular the product already is.

What to actually do

The work splits cleanly once you know which surface reads what.

• Set the product category first. Nothing else works without it. Taxonomy attributes are scoped by category constraint, so a product with no product.category does not even have the relevant shopify.* fields on it.
• Fill the taxonomy attributes for that category, especially the three that are filterable today: color, size, target gender. These are the only structured attributes an agent can exclude on.
• Keep custom metafields for what they are good at. Fit notes, care instructions, provenance stories. They are read by humans, by your theme, and by a model reading prose. They are not read by the filter path.
• Check storefront access on every definition an integration writes to. App-owned metafields default to hidden, so access.storefront has to be set to PUBLIC_READ deliberately.
• Do not let your PDPs rot because you shipped a feed. Availability and delivery reach ChatGPT through the page, and three quarters of feed-integrated merchants' offers still came from the page.
• Declare the right vocabulary in your ACP feed. If the taxonomy field on your categories says merchant, you are telling the ingesting system your categories join to nothing.

The uncomfortable version of all this: the ceiling on how well an agent can retrieve your catalog is set by a data model you do not control, and most of the enrichment being sold right now lands outside it. Good data in the wrong namespace scores zero.

If you want to see where your own store sits, Kinect's UCP test reads your public catalog records and scores the two layers separately: the plumbing Shopify gives you for free, and the data depth you actually control. It is read-only and it takes about a minute.