Catalogue Visibility for AI Agents: Is Your Catalogue Findable When the Searcher Is an Agent?
Assistants acting for buyers and employees increasingly look things up by calling a search, not by reading pages. What being findable by an agent actually requires, the two risks that come with it, and a readiness checklist you can run against your own catalogue.
Your catalogue can rank well on Google and still come back empty when a buyer's assistant goes looking for it. The assistant did not read your category page. It called a search, got nothing for a slightly misspelt product name, and moved on to a competitor whose search answered. That lost request never reaches a sales report.
The short answer: catalogue visibility for AI agents is how reliably an agent acting for a person can find, retrieve and correctly read your items through an interface it can call. It rests on four things: a search the agent can call, tolerance of imperfect queries, results returned as structured fields, and permissions and consent that limit what the agent sees and does. Most catalogues fail on query tolerance and result structure long before the protocol matters.
If you are being asked whether AI agents are finding your products, this guide explains what that takes, where the risks sit, and ends with a checklist you can run this week.
Why is search becoming a channel for AI agents?
An AI agent, in this article, is an assistant that carries out a task for a person, such as finding a part or comparing suppliers. It does that by choosing and calling tools, not only by generating text.
The Model Context Protocol (MCP) describes itself as an open-source standard for connecting AI applications to external systems, and lists search engines among the tools an application can connect to (modelcontextprotocol.io).
That changes what "being found" means. When an assistant has a search tool for your catalogue, it does not browse your pages. It sends a query, reads what comes back, and decides. The distribution side is covered in MCP for business: can AI agents become a new software distribution channel?
There are two kinds of agent to plan for:
- Agents acting for buyers. A customer's assistant asked to find a replacement filter or a book by a half-remembered title.
- Agents acting for your own people. A sales rep's assistant checking whether you stock an item before replying to a customer, or an operations assistant refreshing the catalogue after a price change.
The second group is often the faster win, because the people involved already have accounts and the permissions question has an obvious owner.
What does "findable by agents" actually mean?
Four properties decide catalogue visibility for AI agents.
| Property | What it means | What failure looks like |
|---|---|---|
| A search the agent can call | A stable, documented way for a program to send a query and get results: a search URL, an API or an MCP tool | The only way in is a page built for people, with results rendered by scripts |
| Tolerance of imperfect queries | Misspellings, changed word order, partial names and abbreviations still find the item | Exact-match search returns nothing, and the agent reports that you do not stock it |
| Structured results | Each result carries a stable identifier, title, canonical URL and summary as separate fields | Results arrive as formatted text the agent has to guess its way through |
| Permissions and consent | The agent can see and do only what the person who authorised it allowed | One shared key that reads everything and changes anything |
A search the agent can call
The minimum is a predictable search address that returns results; better is an interface that returns data, such as an API or an MCP tool. Either way it must be documented and stable: an agent cannot work around a redesign the way a person can.
Tolerance of imperfect queries
Agents pass on the words people use, and people misspell, abbreviate and remember half a title. A search that only matches exact strings turns every one of those into a silent miss. The difference is that a person might try again; an agent is more likely to report "not found" and move on. Domain-tuned search can recover these near misses. On one live catalogue, the engine behind Tomorrow Central Search cut zero-result searches roughly tenfold (measured differently before and after; see the case study).
Structured results
An agent has to decide which result is the right one and then cite or link it. That is far more reliable when each result is a set of named fields than when it is a block of page text. For a catalogue, the useful minimum is an identifier, a title, a URL and a short summary.
Permissions and consent
An agent acts for someone. What it may see and do should be what that person may do, cut down to what they agreed to give the agent, not whatever an integration key allows, and the person should be able to withdraw it.
How is agent visibility different from SEO?
| SEO visibility | Catalogue visibility for AI agents | |
|---|---|---|
| Who searches | A person on a search engine | Software acting for a person |
| How they reach you | Crawled pages, ranked and clicked | A search they call directly, or pages they read as a fallback |
| What decides success | Ranking for a query on someone else's engine | Retrieval quality on your own search |
| What they read | Titles, snippets, page layout | Fields: identifier, title, URL, summary |
| Who is allowed in | Anyone | Anyone for public data; only authorised agents for anything else |
Use SEO for being discovered on the open web. Invest in agent visibility when your catalogue is large or specialist enough that people search inside it, because that inner search is what an agent will call.
What usually goes wrong when an agent searches a catalogue?
Most failures are not about agents at all. They are existing search problems that an agent exposes faster, because it never complains.
- Near misses return nothing. A misspelt or reordered query gets zero results, and the agent concludes the item does not exist.
- Results only exist as a rendered page. The search works for a person clicking around, but a program gets a shell of scripts and no results.
- Identifiers and URLs are unstable. The agent finds the item, but the link it hands back is a session URL or a filtered listing page, not the item.
- The index holds more than the website. Internal fields that pages never displayed come back in raw results.
- One key does everything. The key that searches can also upload or delete.
- Agent traffic is invisible. Calls made by agents are not distinguished from calls made by people, so nobody can say whether agents are finding anything. How to measure enterprise search success sets out what to count.
- Starting with the protocol. Publishing an MCP server over a search that fails on typos gives agents a faster way to get nothing.
- Reusing an admin key for the integration. It works in the pilot and becomes the widest permission in the estate.
- Waiting for discovery to settle. How agents find tools is still moving; the official MCP Registry is itself in preview (MCP Registry).
The two risks: private data and actions without consent
OWASP's 2025 Top 10 for LLM applications names excessive agency: damaging actions performed in response to unexpected or manipulated model output. It traces the cause to three things: excessive functionality, excessive permissions and excessive autonomy (OWASP, LLM06:2025 Excessive Agency). For a catalogue, those translate into two decisions.
Risk 1: exposing data that was never public
A public door for agents should search only what you would publish on your website. Treat the index behind it as public, because anything in it can come back in a result. Keep internal fields in a separate index or behind a separate permission. Query logs need the same care, since people type personal details into search boxes and agents pass them through.
Risk 2: agents changing things without a person's approval
Searching is low risk. Uploading a new catalogue, deleting items or publishing a change is not. The MCP specification says there should always be a human in the loop with the ability to deny tool invocations, and that clients should ask for confirmation on sensitive operations and log tool usage for audit (MCP specification, Tools, version 2026-07-28). Your side of that bargain is to make the permission to read separate from the permission to change, so a person can grant one without the other.
A readiness checklist for an agent-ready catalogue
Run it in an afternoon with whoever owns search and someone who can read raw results. Score each item 0 (no), 1 (partly) or 2 (yes). Anything scored 0 in the "Governed" group is a blocker before any agent door goes live; everything else is a priority list.
| Group | Check | How to test it | What "yes" looks like |
|---|---|---|---|
| Callable | There is a documented way for a program to query the catalogue | Ask your team for the URL, API or MCP server, and its documentation | A stable address or tool, documented in one place |
| Callable | Results are returned without running page scripts | Fetch a search URL with a plain HTTP client | Results are in the response, not loaded afterwards |
| Forgiving | Misspelt names still find the item | Search for 20 known items with one typo each | Most come back at or near the top |
| Forgiving | Partial names and changed word order work | Drop a word, reorder the rest | The intended item is still in the first few results |
| Forgiving | Specialist terms are not "corrected" into common words | Search for your own jargon, codes and abbreviations | Correction uses your catalogue's vocabulary, not a general dictionary |
| Legible | Each result has an identifier, title, URL and summary as fields | Inspect one raw result | Named fields; the URL is the item's canonical page |
| Legible | Nonsense returns nothing | Search for a made-up product | Zero results, not a page of loosely related items |
| Governed | The public index holds only public data | Search for a term only an internal field contains | No result |
| Governed | Reading and changing are separate permissions | Check what a search-only credential can do | It cannot upload, delete or publish |
| Governed | Agents act for a named person, with consent they can withdraw | Connect an assistant and look at what it asks for | A consent step naming the agent and its permissions; a place to revoke it |
| Measured | Zero-result searches are counted | Open the search report | A zero-result rate and the top failed queries, reviewed by someone |
| Measured | Agent calls can be told apart from people's | Ask whether the logs record who or what made each call | You can answer "are agents finding our products?" with numbers |
A catalogue that scores well on "Forgiving" and "Legible" but has no callable door is one integration away from being agent-ready. A catalogue with a polished agent door and a 0 on "Forgiving" will be called, fail quietly and be dropped.
How Tomorrow Central Search handles agents
Most catalogue searches are built for one audience; when agents arrive, they either cannot get in or get in with too much. Tomorrow Central Search, our self-serve catalogue search, is built around the four properties above and serves one index through two doors: a public one for visitors, and an authorised one for agents acting for a named person in your organisation.
- For your own people's agents. Search is reachable through Tomorrow Central's MCP server. An agent connects for one person, through a consent screen that names it and the permissions it wants; its access is checked like the person's and can be withdrawn (how agents connect). Within what the person allowed, it can list your search projects, run searches, read the statistics including searches that returned nothing, upload a refreshed catalogue, issue a search link or key, and switch Search on. Upload needs the person's say in particular, because it replaces the whole index.
- For visitors and the assistants they browse with. The same index sits behind a search box on your verified website, or a hosted results page you can link to.
- For imperfect queries. Search corrects misspellings against your catalogue's own vocabulary, and its statistics show which searches still return nothing.
Tomorrow Central Search has a free plan for trying this on your own catalogue. Where the catalogue must stay inside your own infrastructure, ITMTB deploys and tunes the same engine on-premises; see enterprise search.
Frequently asked questions about catalogue visibility for AI agents
Are AI agents finding my products?
Page analytics alone will not tell you, because an agent calling a search does not behave like a visitor. Check whether your search logs record agent calls separately, and run your own known items through the doors an agent would use, with realistic typos and partial names.
Is catalogue visibility for AI agents the same as SEO?
No. SEO is about pages being crawled, ranked and clicked by people. Agent visibility is about a search being callable, forgiving and machine-readable, and about the agent being allowed to use it.
What does MCP have to do with AI agent product discovery?
MCP is an open standard for connecting AI applications to external systems, including search tools. A catalogue search published as an MCP tool can be called directly by compatible assistants instead of being reached by reading web pages.
What are the risks of letting AI agents search our catalogue?
Exposing data the website never showed, and agents changing things without consent because one permission covers reading and writing. Both are decisions to make before anything goes live.
Do we need to rebuild our search to be visible to AI agents?
Usually not. Most of the work is in what already exists: how search handles imperfect queries, what fields results carry, what the index contains and how permissions are scoped.
Key takeaways
- Agents look things up by calling a search; one that cannot be called, forgives nothing or returns page text loses them.
- Query tolerance matters more for agents than for people, because an agent reports "not found" where a person would try again.
- Treat the index behind any public door as public. Keep internal fields out of it.
- Separate the permission to read from the permission to change, and grant change only to the people who need it, with their explicit consent.
- Count zero-result searches and tell agent calls apart from people's, or you cannot answer whether agents are finding your products.
Where to start
Give the checklist above to whoever owns site search and run it against your current search; the "Forgiving" and "Governed" rows usually show where the work is. To try an agent-ready search on your own catalogue, sign up for Tomorrow Central Search on the free plan, or read more on the Tomorrow Central Search page. If the catalogue has to stay on your own infrastructure, or you want ITMTB to run the checklist with your team, see enterprise search or contact us.
Sources
- Model Context Protocol, "What is the Model Context Protocol (MCP)?", accessed 19 October 2026: https://modelcontextprotocol.io/docs/getting-started/intro
- Model Context Protocol specification, "Tools", version 2026-07-28, accessed 19 October 2026: https://modelcontextprotocol.io/specification/2026-07-28/server/tools
- Model Context Protocol, "The MCP Registry", accessed 19 October 2026: https://modelcontextprotocol.io/registry/about
- OWASP GenAI Security Project, "LLM06:2025 Excessive Agency", accessed 19 October 2026: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- Tomorrow Central, "Agents", accessed 19 October 2026: https://tomorrowcentral.com/agents
- ITMTB enterprise search case study: /blog/enterprise-search-case-study-business-research-company
Is your catalogue ready for AI agents?
ITMTB runs the readiness checklist against your catalogue and search, shows where agents will fail to find things, and sets up governed agent access: self-serve on Tomorrow Central, or on-premises.
