How AI assistants find your product
Assistants cite what they can read: clear pages, an llms.txt, and directories they can query. Not another AI tools list. What to do, in order.
A growing share of "how do I find a tool for X" now happens inside an assistant. Nobody opens ten tabs; they ask, and they get three names and a sentence about each. If you are building something, the question that follows is obvious and the advice about it is mostly nonsense.
Here is the mechanism, and then what to actually do.
Assistants are not browsing Product Hunt
The mental model that trips people up is that an assistant goes and looks at the same places you would. It does not, and the two things it actually does behave very differently.
It answers from memory. Ask a broad question — "what are the best directories for finding indie builders" — and a model will usually answer without fetching anything. What comes back is what it absorbed in training: the same dozen well-known names, in roughly the same order, every time. No search ran. Nothing you publish this month can change that answer, because nothing was consulted.
Or it goes and reads. Ask something narrower — "who is building developer tools in Portugal", "bootstrapped AI companies that are raising" — and the model has no memorised list to recite, so it searches, fetches pages, and answers from what it found. That is a completely different situation, and it is the one you can win.
You can watch the difference in about a minute. Ask an assistant a broad question and look for citations; usually there are none. Then ask a narrow, specific one and watch it fetch. Every practical thing below is aimed at the second case, because the first is not a marketing problem — it is a distribution and reputation problem measured in years.
The upshot: your target is not the head query. It is the hundreds of specific ones where nothing is memorised and something has to be read.
Three layers, in order of effort
Everything that makes a product readable falls into three layers. Do them in this order; each one is cheap and the later ones do not work without the earlier ones.
Layer one: your own pages
This is most of it, and it is the part people skip because it is not a growth hack.
- Say what it is in one plain sentence, above the fold. "A scheduling tool for physiotherapy clinics" is quotable. "Reimagine your workflow" is not quotable by anything, human or otherwise. If a model cannot extract a claim, it cannot repeat one.
- Name the audience and the job. Who it is for and what it replaces. This is what turns a fetch into a citation, because the assistant is matching a user's situation, not a keyword.
- Put the facts in text. Pricing, platform, what it integrates with. A screenshot of your pricing table is invisible; a table is not.
- Render something without JavaScript. Many crawlers behind assistant answers do not execute it. If your entire page is an empty
<div>until a bundle runs, what gets fetched is an empty<div>. You can check what they actually see in a few seconds.
Layer two: llms.txt
A small text file at /llms.txt that says what your site is and points at the pages worth reading. It is a convention rather than a standard, adoption is uneven, and it is fifteen minutes of work.
Treat it as cheap insurance, not as a growth channel. It will not make anything recommend you. What it does is remove ambiguity for the things that do read it, which is the same job a good title tag does, and it is one of the six things the readability checker looks for.
Layer three: sources that can be queried
The layer almost nobody does anything about, and the one this whole page is really about.
An assistant answering a narrow question wants a source it can ask, not just a page it can read. A catalogue with an open API — or an MCP server — is something an agent can filter: by category, by country, by stage, by whatever axes the catalogue actually has. One call and it has ten candidates with structured facts attached, instead of five pages it has to parse and guess at.
Being in one of those is the closest thing there is to being reachable by an agent. It is also the layer you cannot build yourself: you can make your own site readable, but you cannot make yourself queryable in somebody else's catalogue except by being in it.
A server directory is not a product directory
This is the confusion that wastes the most time, and the two things share a name.
An MCP server registry lists servers — things an agent can connect to. Smithery, PulseMCP, the official servers repository. If you have built an MCP server, that is where it goes. If you have built a scheduling tool for physiotherapy clinics, being in one of those does nothing for you at all, because nobody asking about scheduling tools is browsing a list of servers.
An agent-queryable product directory lists products, and exposes them through an API or an MCP server so an agent can filter them. The server is the door; the products are what is behind it. This is the one that matters if what you built is a product.
When somebody tells you to "get listed in the MCP directories", ask which kind they mean. Usually they do not know there are two.
What a listing has to look like to be worth anything
Not every listing is readable, and a listing that is not readable does nothing for this.
- Real sentences, not a tagline. A listing that is a logo, a name and a URL is unquotable. One with a paragraph describing the product is a source.
- Structured facts alongside the prose. Category, country, stage, platform. This is what makes a listing filterable rather than merely readable, and filterable is what an agent needs.
- A link that passes. Some directories mark every outbound link
nofollow, which is worth knowing before you spend the afternoon — how to check, in two minutes. - Permanence. A launch board entry is about a day. A directory entry is about existing. Only one of those is still answering questions in six months.
The afternoon version
If you have one afternoon and want the whole of it done:
- Rewrite your first sentence so it names the thing and the audience with no adjectives in it. This is the highest-leverage hour on the list and the one most likely to be skipped.
- Check what a crawler sees. Run your URL through the readability checker. If the page is empty without JavaScript, fix that before anything else on this page matters.
- Write an llms.txt. Fifteen minutes. What the site is, and links to the three or four pages worth reading.
- Get listed in two or three directories that publish structured data, not twenty that do not. Where to submit your startup is the list, and what a builders directory is is how to tell the kinds apart.
- Do a launch too, separately. It is a different job with a different payoff — see Product Hunt alternatives — and it is not a substitute for any of the above.
What is not on this list: buying "AI SEO" packages, stuffing your page with "best AI tool for X", or paying anyone who promises a mention in an assistant's answer. Nobody can promise that. Anyone selling it is selling a guess.
Where this directory fits
WhatAreYouBuilding.AI is a free, worldwide directory of what independent builders are shipping — AI, SaaS and dev tools, by country, category and funding stage. Also queryable by agents via MCP.
That last sentence is layer three, and it is worth being concrete about what it means, because the phrase gets used loosely. Every product, builder and community in the directory is queryable over an MCP server and a plain JSON API, with no key, no account and no OAuth. An agent can be pointed at https://whatareyoubuilding.ai/api/mcp and asked who is building developer tools in Germany, or which bootstrapped founders said they are raising, and it gets structured records back rather than a page to parse. The endpoint, the tools and what to ask it are all documented.
It is not an MCP server registry — see the section above — and it is not an AI tools catalogue; a quarter of what is listed is filed under AI and the rest is not.
Being listed here is not a guarantee of anything, and no directory can honestly offer one. What it is: a page about your product, written in sentences, with structured facts attached, that an agent can find by filtering rather than by luck. Listing is free, a person reads every submission, and you can do it in about a minute. Who runs it is a page rather than a mystery.
Questions people actually ask
Will doing all this get me mentioned by ChatGPT? It improves the odds on specific questions and does approximately nothing for broad ones. Anyone telling you otherwise is guessing, including us — the honest version is that you are making yourself findable, not buying a placement.
Is llms.txt actually used? Unevenly, and less than its advocates suggest. It costs fifteen minutes and removes ambiguity for the things that do read it. That is the whole case for it; treat a bigger claim with suspicion.
Does my product need its own MCP server? Only if an agent doing something inside your product is useful — booking, querying your data, taking an action. It has nothing to do with being discovered, which is what this page is about. Two different projects that share an acronym.
What about schema.org markup on my own site? Worth adding, and it is layer one rather than a fourth layer. SoftwareApplication or Product markup makes your own facts machine-readable at the point they are already written. It will not do anything for a page that has no facts on it.
Is any of this different from normal SEO? Less than the phrase "AI SEO" implies. Being readable, saying plainly what you do, and being cited by other sites were the answer before and are the answer now. What genuinely changed is layer three: a source an agent can query is a new kind of thing, and it did not exist to be in five years ago.
How long does it take to show up? Longer than anybody wants to hear. Assistants lean on sources they already reach for, and becoming one of those is a matter of being referenced by other people over months. The work above makes you findable when somebody does look; it does not make anybody look.