How AI Shopping Agents Find Real Products: A Look at the Tool Calls

Ask an AI shopping assistant where to buy something and the answer arrives in a second or two. What happens in that second is less mysterious than it sounds. The assistant does not know what is in stock today, so it calls tools: it searches a product catalog, looks up the product it found and reads the result back to you. A AI shopping agent is only as good as those calls. This article follows one request through them, shows the two that matter and lets you replay the exchange on real data. The replay below uses results last pulled November 12, 2026.

What an agent does when you ask it to shop

A language model writes fluent answers, but it holds no live prices. Ask it for the best price on a pair of headphones and, with no tools, it can only describe what it remembers, which may be a year old. An agent fixes that by being allowed to call functions. Each call has a name, a few arguments and a result that goes back into the conversation, and the model decides what to call next.

For a product question the useful calls are few. The first is a search, which turns words such as a product name into candidate listings with prices and a barcode. The second is a lookup by that barcode, which turns one listing into everything known about the product: every store that sells it, today’s prices and how those prices have moved. The model then writes an answer from the results instead of from memory.

The two calls answer different questions. A search answers “what is out there?” A lookup by barcode answers “what is true of this exact product?” An agent that stops after the search recommends the first listing it saw. An agent that makes the second call can say whether that listing is the cheapest, and whether the price is high or low for the product.

Who builds with these calls

Teams building shopping assistants make these calls on every product question, so the search and the lookup have to be fast and the results small. Commerce apps put the same pair behind a button such as “is this a good price?” Publishers add the lookup to a product card so that a recommendation carries a fact. How shopping agents should handle out-of-stock and price-changed offers covers what happens when the result is not what the agent hoped for.

The calls can reach an agent in two ways. A model that supports MCP, the Model Context Protocol, sees the Affiliate.com search and price history as tools it can call by name. An application can also send the same requests over REST. The arguments are the same either way, and the replay lets you switch between the two views. MCP or REST API? explains how to choose.

Replay an agent on real data

This replay runs on results from the Products API and the Price History API. The page holds a rotating set of products that is rebuilt every night, and it offers three of them, a different three on most visits. Pick a request and the agent works through it step by step: its search, the result, its price history request, the result and the answer it writes. Switch between MCP tools and REST requests to see the same call both ways. The figures use the last 90 days.

Call one: find the product

The search takes the words a shopper would use and returns listings. The request below asks for in-stock listings in US dollars whose name matches, and requires a barcode, because the next call depends on it. Replace the name with whatever the shopper asked about.

POST https://api.affiliate.com/v1/products

{
  "search": [
    { "field": "name", "operator": "LIKE", "value": "Wacom Cintiq 16" },
    { "field": "availability", "operator": "=", "value": "InStock" },
    { "field": "currency", "operator": "=", "value": "USD" },
    { "field": "barcode", "operator": "NOT NULL" }
  ],
  "fields": ["name", "brand", "barcode", "final_price", "merchant.name"],
  "per_page": 10
}

A name search returns more than the product itself. Accessories, cases and look-alikes share words with it, which is why the agent should not trust the first row blindly. It keeps the listing whose name and barcode match what the shopper asked about, and it passes that barcode on. Barcode search explains why the barcode, and not the title, identifies a product.

Call two: check the product, not just the listing

The second call takes the barcode and asks the Price History API about every store that sells it. This is the call that separates an answer from a guess, and the replay shows why. The first listing a search returns is one store’s price. The history covers all of them.

POST https://api.affiliate.com/v1/products/price-history

{
  "target_type": "barcode",
  "target_ids": ["753218984081"],
  "currency": "USD",
  "include_series": true,
  "include_stats": true,
  "include_product": true,
  "per_page": 25
}

The response has one entry for every store that carries the barcode, up to 25 per page. Each has a daily series with the price and availability for every observed day, and a summary with the current, lowest, highest and average price. One call covers up to 90 calendar days. A missing day means the price was not observed, so an agent should skip it, not read it as zero.

Through MCP the same request is a call to get-price-history. The tool description tells the model what the response contains, so it knows to send include_series as false when a summary is enough. This agent asks for the series because it wants the lowest in-stock price per day, which a per-store summary cannot give.

Turning two results into an answer

The last step is arithmetic, and it is worth writing as code even when a model will phrase the result, because the numbers should not depend on how the model feels about them. This function reads the two results and returns the facts the answer needs. The replay applies the same rules.

// listing: the matching row from the search. listings: the data array of the price history response.
function answer(listing, listings) {
  const prices = {};               // lowest in-stock price for each day, across stores
  for (const l of listings)
    for (const d of l.series)
      if (d.availability === "InStock" && (prices[d.date] === undefined || d.final_price < prices[d.date]))
        prices[d.date] = d.final_price;
  const days = Object.keys(prices).sort();
  const today = prices[days[days.length - 1]];
  const low = Math.min(...Object.values(prices));
  return {
    today,
    low,                           // lowest in-stock price in the window
    aboveLow: today - low,         // 0 means it is at its lowest
    searchGap: listing.final_price - today   // how much the first listing overpaid
  };
}

The model can turn that object into a sentence. It cannot change the numbers in it, and that is the point. A recommendation built this way can be checked, because every figure in it traces to a call.

What the November 11, 2026 pull shows

We ran the same two calls on November 11, 2026 for the six products in that day’s set. Four of the six had a cheaper in-stock price than the first listing the search returned, the largest difference being $47.92 on the Wacom Intuos Pro pen tablet. Three were priced at their 90-day low that day.

This table is fixed to November 11, 2026. The replay above is rebuilt every night with a different set of products, so its products and numbers will change. Treat the table as a record of one day.

A handful of products is a small sample and not a market study. Each figure describes one product in US dollars across the stores that reported it, and a price counts only on days the product was in stock.

What to check before trusting an agent’s answer

An agent’s answer is only as reliable as the calls behind it, so a few habits matter when you build one.

Match on the barcode. Two colors or two bundles of one model are different products with different barcodes, and mixing them makes a price look wrong. How LLMs fail on product identity shows how it goes wrong.

Look at the whole result, not the first row. The replay shows the first listing costing more than the cheapest one. How agents choose a merchant when ten offer the same product covers the choice in detail.

Name the window. “Lowest price” is meaningless without a period. Say the last 90 days, and say whether out-of-stock days were left out. Showing readers a product’s lowest recent price walks through the label.

Check again at the last step. Prices and stock move during the day. If an agent is about to send a shopper to a store, one more request confirms what it is about to promise. For a first look at prompts and results, asking an AI assistant to search products through MCP lists sample prompts.

Getting started in three steps

Moving from the replay to an agent of your own takes three steps.

{
  "target_type": "barcode",
  "target_ids": [
    "753218984081"
  ],
  "currency": "USD",
  "include_series": true,
  "include_stats": true,
  "include_product": true,
  "per_page": 25
}