Systems · Merchant Center MCP

The Merchant Center MCP: catching what the Ads platform's product view misses

A Merchant Center MCP lets an AI assistant query your product feed and Shopping data live, from the system that Google Shopping actually reads. Google Ads' own product view is a downstream, cached picture of the same data, and the two disagree often enough that trusting the wrong one is a real cost.

What it answers, in practice

Three families of question, roughly:

Feed health. Which products are disapproved and for what reason, which are warned, how fresh the last successful fetch was, and where the recurring failures cluster. The report the Merchant Center UI shows one screen at a time, answered across the whole catalog at once.

Product-level truth. For any given product or set of products: what price, availability, GTIN, brand, and destination Google currently has, and whether that matches what the merchant expects. This is the query that catches "the site says $89, the feed says $99" before it costs a campaign.

Cross-checks against Google Ads. The ads platform maintains its own product view for reporting, and it does not match Merchant Center in a specific, documented way: it retains historical inactive products indefinitely. Asking both sides the same question at the same time exposes the drift, and it is usually larger than anyone expects.

That last family is where this layer earns its keep.

Three things it has caught

A catalog that was half ghost. One account's Google Ads product view claimed roughly 8,291 products. Merchant Center, queried directly, held 4,076 active. The ads view retains historical inactive products; every catalog decision reasoning from the bigger number was reasoning about inventory that no longer exists. Merchant Center is the source of truth for what is live; the ads view is the source of truth for what has spent. Treating them as the same number is where the arithmetic goes wrong.

Feed says approved, real world says disapproved. An account's dashboard read as green. A live pull surfaced a set of products showing approved at the item level but disapproved at the destination (Shopping ads specifically), which is a different field, in a different report, and does not roll up into the top-line status. The result was a small block of products that were serving no impressions in Shopping despite looking healthy from every UI view anyone had opened.

The catalog reads bigger than the store. Not the ghost-history version above; the opposite. Merchant Center held a set of products that had been deleted from the store weeks earlier, still active because the feed was not being trimmed on the sending side. The Ads platform was spending on ads pointing at 404 pages. This is a query that is trivial to write and almost never gets written until something breaks.

The rules that make it useful

The connection alone is not enough; the rules on top of it are:

Ask Merchant Center for what is live, and ask Google Ads for what has spent. Assigning one job per system, in writing, prevents the whole class of "which number do we mean" arguments.

Verify disapproval reasons against the actual product, not the summary. The top-line status hides destination-level failures; the query has to descend one level.

Reconcile against the store, not the export. An export was current when it was downloaded; the store is current now. If the feed and the store disagree, that is the version of the disagreement worth resolving.

The same three-part discipline runs on the Ads side too, with different specific rules. The pattern is the same: the connection retrieves, the rulebook decides what retrieval means.

What it does not do

It cannot edit the feed, adjust prices, or change availability. It does not replace the sending side of the feed (the platform or feed manager that assembles and pushes the data). And it does not fix a bad catalog; it makes the bad-catalog problem visible faster, which is not the same thing. The fix is still human, and often is not on the ads side at all.