One week of real agent traffic on a federated catalog

TL;DR — For eight days an anonymous external agent worked the public KaliCart Global MCP endpoint: 500+ completed searches, navigation by canonical taxonomy leaf, structured fallback when strict matching returned nothing, roughly nine in ten searches ending with results. No per-product fixes, no manual help, no contact with its builder. Then it finished and left. One consumer proves the contract works when demand shows up — it does not prove demand at scale. We publish the numbers anyway, because real agent behavior on real commerce infrastructure is rarer than opinions about it.

What the telemetry recorded

KaliCart Global's public MCP server is keyless by design, so anyone — human or agent — can call it without telling us who they are. Since publication on the official MCP Registry in June, most traffic has been exactly what you would expect: registry health probes performing the MCP handshake (initialize, tools/list) and leaving. Thousands of them, from a dozen monitoring services. Handshakes are presence, not demand.

Between July 28 and August 4 something different appeared. Three request sources, active in the same window with the same behavior, ran just over five hundred global_search calls that returned results — real queries against the federated catalog, not empty pings. The client identified itself with no name. We log a salted hash of the caller address and the query text, nothing more, so what follows is everything we know.

How it searched

The interesting part is not the volume. It is the shape.

It navigated by taxonomy, not by keyword soup. Long runs of queries target canonical leaves exactly as the catalog publishes them: jewellery.rings, jewellery.watches_luxury, health.supplements.creatine, health.supplements.whey_protein. The agent read the category surface first, then walked it systematically — parent category as a broad probe, leaves for precision.
It mixed structure with free text where free text is the right tool. Between taxonomy walks: queries like leather strap dress watch. Fifteen results. The catalog's tokenized multi-term matching did what it is there for.
It used the fallback ladder as designed. Most successful searches matched in strict all_terms mode; a consistent minority landed in any_term_relaxed, the declared relaxation the server applies when strict matching is empty. The agent kept going in both cases, which tells us the relaxation is legible from the outside — the match mode is part of the response, not a silent guess.
It finished with results almost every time. Across the thirty days around the window, searches with results outnumber zero-result searches roughly nine to one.

What we did while this happened

Nothing. That is the point worth underlining. The catalog this agent navigated is governed by a rule we call NO-PRODUCT-PATCH: no fix may ever target a single product, brand or query. Every correction must be structural — taxonomy, matching, normalization — or it does not ship. So there was no dictionary entry waiting for leather strap dress watch, no special case for jewellery. The agent got the same surface every other caller gets, and the surface held.

Then it stopped

On August 4 the searches ended, all three sources at once. Since then the endpoint is back to registry probes. We do not know who built the agent, what it was for, or whether it found what it needed. A keyless public surface buys reach at the price of attribution, and we knew that trade when we made it.

Honesty about the sample: this is one consumer, over one week, on a catalog of a few thousand federated products. It demonstrates that when an agent arrives, the contract — discovery, canonical taxonomy, bounded search, declared match modes — carries it end to end without human intervention. It does not demonstrate that agents will arrive in numbers. Those are different claims, and the second one is the one distribution has to earn.

Why we publish operator telemetry at all

Most writing about agentic commerce is projection: what agents will want, how they will shop, which protocol they will prefer. Operator data — what an actual agent actually did against an actual catalog — is scarce, partly because few public commerce surfaces exist to measure, and partly because those that exist rarely show their numbers. We think the numbers are the argument. A federated catalog is a bet that agents prefer structured, governed, verifiable data over scraping; each real consumer that navigates it cleanly is evidence for the bet, published here as such.

Sources

KaliCart Global MCP — the public endpoint the agent used (keyless, read-only)
Official MCP Registry — where the server is listed as io.github.giuseppesocci-bot/kalicart-global
Related: What an agent actually pays to read your catalog · Authority, freshness, consent