ChatGPT Apps Directory: A Market Map for Builders

The ChatGPT apps directory holds 4,000+ listings from 3,600+ vendors. 94.6% of those vendors ship exactly one app. 12.7% of listings say what the app can actually do. And not one single listing carries a popularity rank, a trending rank or a new flag.

Put those four numbers together and you have the answer to the only question a builder actually has about this directory, which is whether it is a distribution channel worth building for. It is a large, complete, well-described catalogue with no published evidence that being in it does anything. That is not a reason to avoid it. It is a reason to be precise about what you expect from it.

This is a census, not a roundup. We enumerated every listing, parsed every declared tool name, and read the whole thing as a market map. Figures were re-queried live on 19 September 2026. The companion studies cover the other directory and the demand side: the full two-directory count is in the AI connector census, and the per-industry version is in the vertical whitespace study.

The answer up front

If you are weighing whether to build a ChatGPT app, the deciding variable is not the size of the directory. It is whether you need the directory to find your customers. Every measurable property of this catalogue says it is good at describing what exists and publishes nothing about what performs.

That makes it a cheap surface to be present on and an unreliable one to depend on. The same conclusion applies to any channel with no feedback loop, and it is the reason we keep pushing founders toward channels they can measure, as in who micro SaaS actually sells to and finding your first customers.

Why this is not a shopping list

Almost everything written about this directory is a list of apps to install, aimed at someone who wants to connect their email to ChatGPT. That reader is well served and is not who this is for.

The builder’s question is the opposite one. Not which app should I install but is this a place where software gets found and paid for. Answering that requires counting the whole directory and looking at its structure, which nobody had done. The closest thing to a complete list of this directory in public is a plain markdown file on GitHub. Everything else is either OpenAI’s own documentation or an article about how to get your app noticed, which is itself a signal about what builders are anxious about.

We take the same position on every marketplace we study: the interesting question is never which product to pick, it is whether the market rewards the people building in it. That framing drives the plugin ecosystem comparison, Chrome extension ideas and the state of micro SaaS competition.

Method and limitations

The honest headline of that table is the second-to-last row. Most marketplace analysis leans on install counts or revenue share. Neither is available here, so every conclusion below is drawn from structure rather than performance. We would rather say that plainly than imply a measurement we do not have, which is the same standard we hold in the connector census and our revenue benchmarks.

The shape of the directory

94.6% of vendors ship exactly one app

3,400+ of 3,600+ vendors have a single listing. That is the most telling structural fact in the directory and it is easy to misread in either direction.

What a 94.6% single-app rate actually tells you

It tells you almost nobody is running a portfolio strategy here. In a marketplace where listings reliably produce revenue, successful vendors ship a second and a third product, because the channel is proven and the marginal cost of another listing is low. That is not happening.

Two readings fit. Either the ecosystem is young enough that nobody has iterated yet, or the first listing did not return enough to justify a second. We cannot distinguish them from directory structure alone, and we will not pretend otherwise. But the absence of portfolio behaviour is exactly the pattern we saw in the plugin ecosystems that turned out to pay worst, which we measured properly in Shopify app vs WordPress plugin and priced in what micro SaaS actually charges.

The useful comparison is an ecosystem where portfolio behaviour is visible. Where developers ship a second and a third product, you can infer the first one paid. Where they do not, you cannot infer anything, which is the situation here. Revenue-side evidence for that inference lives in the state of indie SaaS revenue and solo developer revenue examples.

The largest vendor ships 55

In a 4,000+ listing directory, the biggest single vendor accounts for 55. There is no equivalent of the handful of studios that dominate a mature app store. Concentration is genuinely low, which is good news for a newcomer on visibility and bad news as a signal about the channel. Low concentration plus no ranking means the directory is flat in both directions: nothing is crowding you out and nothing is lifting you up. We use the same read on crowding in finding a profitable niche and boring business ideas.

The missing demand signal

Here is the finding that should change how you think about this directory. We checked every listing for a popularity rank, a trending rank and a new flag.

Zero, zero and zero

Not one of the 4,000+ listings carries any of them. No ranking. No trending. No recency marker. No verified tier either. There is no published field anywhere in this directory that distinguishes a listing people use from a listing nobody has opened.

For comparison, the Claude connectors directory publishes a popularity rank on 2,700+ of its 2,800+ listings and a trust tier on all of them. One directory tells you what is popular and how much it has been vetted. The other does not.

That asymmetry is worth sitting with, because it is the single biggest practical difference between the two surfaces and almost nobody writing about them mentions it. The full comparison is in the census, alongside the same treatment we give the Stripe Index and the funded company database.

What the directory does publish, and publishes well

It would be unfair to leave it there, because on descriptive completeness the ChatGPT directory is excellent. 100% of listings have a description, a vendor, a category, a version and sample prompts. There are no holes. Anyone building analysis on top of it gets clean, complete rows, which is more than most public datasets offer. Compared with the review corpora we normally work in, where coverage decays and fields go empty, this is unusually clean. We document those coverage problems honestly in the Capterra analysis guide and the complaint database comparison.

Complete and silent at the same time

That combination is the directory’s defining property: exhaustive about what an app claims, silent about whether the claim matters to anyone. You can learn everything about the supply side and nothing about the demand side.

For a builder that is a specific kind of hard. You can compete on positioning because the fields are there, and you cannot tell whether positioning is working because the outcome fields are not. Any strategy that requires measurement is off the table, which is why we push toward measurable channels in how founders research markets and finding your first SaaS customers.

How the Claude directory compares

Storefront versus interface registry

That table is not a scoreboard, it is a description of two different artefacts. The ChatGPT directory is a storefront: organised around a person browsing for something to switch on, complete on prose, silent on machinery. The Claude directory is an interface registry: organised around a connector as an MCP server, which publishes its tool list as a matter of protocol.

Neither is better in the abstract. They reward different things. A storefront rewards positioning and a name. A registry rewards depth of surface area, because yours sits next to everyone else’s and is directly comparable. Which one suits you depends on what you are building, which is the decision we walk through in what to build as a solo developer and how to build a micro SaaS. Setup and connection mechanics for each surface are in using MCP with Claude and the MCP setup guide.

Only 12.7% declare capability

541 of 4,000+ listings publish a machine-readable tool list. The other 87% publish a description and nothing structured about what the app does. If you are trying to understand the competitive landscape by reading listings, you are reading marketing copy for seven out of every eight entries. If you were running competitor analysis on this directory, that is the constraint to plan around, and the workaround is to analyse the other directory where disclosure is near total. The method is in competitor analysis for SaaS.

84.7% of declared tool names say nothing

It gets stranger inside the 12.7%. Of the 5,300+ tools the directory does declare, 4,500+ (84.7%) have names we cannot parse into a verb at all. Writes are 378 (7%), classifiable reads 324 (6%), admin 74, meta 30, transactional 17.

On the Claude side the same parser classifies the overwhelming majority successfully. The difference is not the parser. Running the same classifier over both corpora is what makes the comparison meaningful at all, which is the single-methodology discipline we also used across seven plugin ecosystems in the plugin study.

Names as capability labels, not operations

Look at the most common object nouns in the ChatGPT directory’s declared tools and the reason becomes obvious: review, skill, design, analysis, research, strategy, setup, docs. Those are not operations on a resource. They are labels for a capability or a persona.

An MCP server names things like create_invoice or list_appointments, which parse cleanly because they describe an operation on an object. A directory listing names things like strategy review, which describes a service. That is a genuine structural difference between the two surfaces and it is worth naming precisely rather than treating as a data quality problem.

Why the naming matters if you are building here

Because it tells you what the listings actually are. A large share of this directory is closer to a packaged prompt or a workflow than to an integration with a system. That is not a criticism, it is a description of the competitive set you would be entering.

It also tells you the bar. If most listings are capability labels, a listing that genuinely connects to a real business system is structurally differentiated, not just better marketed. That gap is the most actionable thing in this article, and it is the same logic behind single-feature micro SaaS and SaaS ideas backed by pain points.

17 transactional tools, in the whole directory

The entire ChatGPT directory declares 17 tools that can move money or commit an irreversible external action. Seventeen, across 4,000+ listings. That is 0.3% of declared tools, against 0.8% on the Claude side.

A developer who built a network that only AI agents could use found the practical version of this and led their write-up with it: “PLAIN CHATGPT CANNOT POST AT ALL, and the documented fix doesn’t work either. Its browsing tool is GET-only. It can read every page and physically cannot write, however the instruction is worded.”

Seventeen transactional tools is not a gap that a better listing closes. It is a property of the surface, and it caps what any app here can promise. The full read-write breakdown across both directories, and why the vendors holding the money-moving systems keep declining, is in the census and the whitespace study.

Reads, writes and the gap between them

Agent developers working against this constraint describe it the same way: “I’m not adding mutate tools until the read loop is tighter” and “the external system completes the action, the response times out, and the agent retries. Now you have two tickets, two emails, or two purchases.”

The classifiable slice splits 378 writes to 324 reads, which reads oddly until you remember the base is small and heavily filtered. We would not build an argument on a ratio inside a 15% sample, and we flag that rather than present it as a finding. The number we are confident about is the transactional one, because 17 is 17 regardless of the denominator.

Six published endpoints

6 listings out of 4,000+ publish an MCP endpoint. On the Claude side the figure is 2,600+. If you want an agent to reach something directly rather than through a platform-mediated UI, this directory is not currently the surface for it. That is a real constraint on the kind of product you can ship here, and it is worth checking before you design around an assumption. The practical implications are covered in AI agents beyond coding and verifying AI agent work.

The category map

Two categories are 41.9% of everything

Productivity and business operations together take 989 and 791 listings, or 41.9% of the directory. Add developer tools and the top three is 51.4%. Half of the catalogue serves knowledge work.

An operator in r/EntrepreneurRideAlong explained what that concentration feels like from outside it: “Every tool I tried felt like it was built for tech companies, not for people actually doing the work.” A directory half-full of knowledge-work tools is not serving the businesses documented across 1M+ complaints in our corpus. Their descriptions of daily work look nothing like a productivity app: “A lot of his work involves moving information between different websites that have no integration with each other”, “What starts as a quick check turns into a 15-hour-a-month slog of copy-pasting numbers, hunting down missing PDFs, and playing detective to spot duplicate payments”, and “you open 12 tabs, export CSVs, and wrestle VLOOKUPs.” That mismatch is what we chase in boring industries begging for micro SaaS.

That is what you would expect from an ecosystem whose earliest adopters were connecting their own working tools, and it is the same concentration we measured across both directories in the connector census.

The thin end of the map

Healthcare 77. Communication 38. Security 35. Science and research 19. These are the categories a builder should look at hardest, because thin supply in a category with real businesses in it is the definition of an opening.

The caution is that thin supply sometimes means thin demand, and sometimes means a structural barrier. In healthcare it is very clearly the latter, which our vertical readiness study covers: every healthcare-adjacent vertical we scored is blocked at the system of record. Thin here is a symptom, not an invitation, and knowing which is which is most of the work. Healthcare operators describe the barrier directly: “The integration issues left us unable to take calls for three weeks” and “Accounting reports are lengthy and confusing. I often need to run multiple reports to reconcile balances.” The demand is documented. The reachability is not. Telling those apart is the job in finding a profitable niche.

A caveat on the categories

Business operations and security exist only on this platform in our canonical mapping, because the two directories use different source taxonomies. Within-directory shares are sound. Comparing a category’s size across platforms is not, and we do not do it. The same caveat is on every category table we publish, including the Stripe Index.

Overlap with the Claude directory

Of 5,100+ vendor domains across both directories, only 918 (18.0%) appear on both. 2,500+ are ChatGPT only. The ChatGPT directory holds the largest pool of single-platform vendors in the ecosystem.

Everyone here has made a platform bet

Most of them did not frame it that way. They built for one surface because that is the surface they were using, and the consequence is that four out of five vendors are invisible to agents on the other platform. If you build for both you are doing something 82% of this ecosystem is not, which is a real if unglamorous differentiator. Building across both also means building against two different sets of rules, which is the cost side of that differentiator. Weigh it the way we weigh any platform decision in buying versus building a SaaS.

The discoverability question

Given zero published ranking and 4,000+ listings from 3,600+ vendors, there is no visible mechanism by which a good listing beats an average one. That does not prove discovery is broken. OpenAI plainly holds usage data it does not publish, and placement may be driven by signals we cannot see.

What we can say is narrower and still useful: there is no public evidence that being in the directory produces usage, and no public way for a developer to find out.

What builders report

The anecdotal record is consistent, and worth treating as exactly that. A developer who spent six months building an agent that books travel started because the directory did not solve his problem: “The immediate suggestions from Claude was to use the integrated connectors. I tried those but they were really poor. I still had to book myself, and they didn’t give full results.”

Another, in r/SaaS, described the outcome that this whole market map is meant to help you avoid: “7 months passed and over 20k visited the site and only 4 people actually saw what i built.” A third framed the goal: “I don’t want to spend another 3-6 months building something that people think is cool but nobody actually pays for.”

What the buying side sounds like

Builders deciding where to spend a quarter are unusually candid in public, and the pattern is consistent enough to be worth reading as evidence rather than anecdote. Every quote below is anonymized to subreddit.

Not one of those is a complaint about the ChatGPT directory specifically. That is the point. The people who would build here are worried about whether anything they build gets found and paid for, and this directory is the only major surface in the ecosystem that publishes nothing on either question. Working from documented demand instead is the approach in finding SaaS ideas from real user pain points and finding business ideas on Reddit.

People are building unofficial directories

The clearest signal of all is revealed preference. A builder posted in r/startupideas that most ChatGPT apps never get discovered, and that they had built an unofficial directory scraping the official one daily in response.

Unofficial directories get built when the official one is not answering a question people have. The question here is not what exists, because the official directory covers that completely. It is what is working, which nothing covers. Unmet demand for a dataset is itself a documented idea pattern, and a reliable one, as in unique business ideas backed by real complaints and B2B SaaS ideas.

Optimising a listing with no feedback loop

There is a small industry of advice on ChatGPT app directory optimisation, and the tactics are reasonable: clear description, accurate category, honest naming. The structural problem is that the directory exposes 100% of the input fields and 0% of the outcome fields.

You can optimise. You cannot learn. Every other channel a founder uses at least returns a number. Where a channel returns nothing, the correct posture is to spend little on it and put your measurement effort somewhere that answers back, which is the argument in how to find problems worth solving and idea validation tooling.

Against other marketplaces

Mature marketplaces publish install counts, ratings, rankings or explicit revenue share terms, because those signals are what let a developer decide where to spend a quarter. We used exactly those signals to compare seven plugin ecosystems on how many independents reach $1,000 a month, and the answer varied enormously by platform.

None of that analysis is possible here yet, and that absence is itself the most useful thing to know. Compare the available evidence with Chrome extension economics or what software businesses sell for, and the difference in what you can find out is stark. A founder in r/smallbusiness summarised why measurable channels matter in a sentence about something else entirely: “I missed a callback yesterday that probably cost me a $2k job.” You cannot manage what does not report back. Benchmarks that do report back are in SaaS revenue benchmarks by category.

Earlier in its life cycle than the count implies

4,000+ listings sounds mature. No ranking, no tier, no install counts, 94.6% single-app vendors and 6 published endpoints all say early. The listing count is running ahead of the marketplace machinery, which is normal and worth pricing into any plan with a twelve-month horizon. Early is not the same as bad. It does mean your plan should survive the machinery not arriving, which is the stress test in how to build a SaaS and AI product validation for solo founders.

Is 4,000+ saturated?

Not in the way the number suggests. Saturation means many credible competitors chasing the same customer. What this directory has is many entries, most from vendors who never shipped a second one, most not declaring what they do, almost none able to transact.

Wide, shallow, and hard for a different reason

The honest read is that the directory is not crowded, it is unmeasurable, and unmeasurable is its own kind of hard. A crowded market at least tells you where the demand is. Treating an existing competitor as validation rather than disqualification is our standing position, argued in the state of micro SaaS competition. This directory does not give you enough information to run that argument either way.

When building here makes sense

Three cases. You already have an audience and the listing is a convenience for them rather than an acquisition channel. You are extending an existing product and the listing costs you a week. Or you are deliberately taking an early position in a category that is thin for a reason you understand and believe will change.

In all three the listing is a complement to distribution you already control. That is the pattern that works across every marketplace we have measured, and it is covered in getting to the first $1k MRR and simple SaaS ideas for solo developers.

When it does not

One case, and it is the common one: you are building primarily because the directory looks like distribution. Nothing published about this directory supports that expectation, and 94.6% single-app vendors is the closest thing to evidence either way. If your plan needs the channel to work, you need a channel that reports back. The alternative is the outcome one builder described after seven months: “over 20k visited the site and only 4 people actually saw what i built.” Volume without a conversion path is the failure mode, and avoiding it is the point of finding your first customers.

What to build if you build here anyway

Build the thing that 87% of the directory is not: an app that connects to a real business system and declares what it does. The demand for exactly that is documented in plain language: “Modules need more seamless integration to eliminate repeated data entry”, “The reports we were looking for aren’t there, and I’m forced to compile everything manually”, and “Bank integration eats CONTROLLERS for breakfast. Integration promised automation but delivered manual uploads, broken file formats, cryptic bank error messages.” The census says most listings are capability labels and almost none can transact, so genuine system connection is structurally differentiated rather than merely better.

And pick your system carefully, because the connector census shows which ones are reachable at all. The functions with the worst coverage across both directories are support, compliance, inventory and payments, which is where the unserved work sits. The full map is in the census and the per-vertical version is in the whitespace study.

To make that concrete, here is what the thin end of the category map sounds like from the people inside it. Every one of these describes work an app in this directory could in principle do and almost none of them currently does. Quotes are anonymized to platform and software category.

None of that work is glamorous and all of it is paid for today, by a human, every month. A directory listing that genuinely does one of those jobs is competing against a spreadsheet rather than against the other 4,000+ listings, which is a far better fight. Finding more of these is what the pain points database, the pain point MCP tools and Discover are built for.

The distribution rule this all points to

Distribution you can measure beats distribution you are listed in. It is unglamorous and it survives every marketplace we have looked at. A listing in a directory that publishes no outcomes is a business card, not a channel, and business cards are worth having and worth almost nothing to plan around. An operator who rebuilt a paid analytics product himself described the calculation everyone in this market keeps making: “I was paying for a profit app to stitch it all together, and a while back I cancelled it and rebuilt it myself.” Directory presence does not protect you from that. An accumulated data model does, which is the argument in what transfers when you sell a SaaS and why SaaS customers churn.

The pre-build checklist

Five questions, in order, before you commit a quarter to this surface. Does the directory publish anything that would tell you whether your listing worked? Would you build this product if the directory did not exist? Is your app a capability label or a system connection? Is the category you are entering thin because of low demand or because of a structural barrier? And do you have one channel you control that does report back?

A founder in r/SaaS wrote the same checklist from the other end: “If you could have a small SaaS built specifically for you, what problem would you want it to solve?” and “problems that you deal with regularly, currently involve repetitive manual work, and you’d realistically pay $20 to $500 a month to make disappear.” That is a better brief than any directory can give you.

A no on the second question is the one that should stop you. Everything else is manageable. Working those questions against real data is what finding SaaS ideas and the 8-stage validation framework are for.

How to reproduce this

Enumerate every listing in the directory. Record which descriptive fields are present and which outcome fields are absent, because the absences are the finding. Group by vendor to get concentration. Parse every declared tool name into a verb and an object noun and record the parse failure rate rather than discarding it. Then compare against the other official directory, because a single directory in isolation has nothing to be measured against. Both corpora are queryable through the Agent Index MCP tools if you would rather re-run this than rebuild it, and the wider tool set is documented in the full MCP reference and cross-source research.

What would change our mind

Three things, stated so they are falsifiable. If the directory began publishing a popularity or install signal, the central criticism here would evaporate and the channel would become plannable overnight. If capability disclosure rose from 12.7% toward the other directory’s 98.6%, the competitive landscape would become legible. And if the single-app vendor rate fell meaningfully below 94.6%, that would be the first real evidence that listings are returning enough to justify a second one.

We will re-run this and say so either way. In the meantime, both directories are browsable at the connector browser, the per-vertical verdicts are in Agent Index, and the Agent Index MCP guide documents the seven tools that put the census inside your assistant. For the demand side, start with the pain points database or Discover.

Frequently asked questions

How many apps are in the ChatGPT apps directory?

4,000+ as of September 2026, from 3,600+ distinct vendors. OpenAI’s own help documentation notes the app directory was migrated into the plugin directory on 9 July 2026, so the two names now describe one surface.

Is it worth building a ChatGPT app in 2026?

It depends on whether you need the directory to find your customers. It publishes no popularity rank, no trending signal, no new flag and no verified tier, so there is no public evidence that placement drives usage. Cheap surface if you bring your own audience. Unreliable if you do not.

How many ChatGPT apps say what they can actually do?

541 of 4,000+, which is 12.7%. The remaining 87% publish a name, description, vendor and category but no machine-readable tool list. On the Claude side the figure is 98.6%.

Do most vendors ship more than one ChatGPT app?

No. 3,400+ of 3,600+ vendors, 94.6%, ship exactly one. The largest single vendor ships 55. This is an ecosystem of one-off entries rather than portfolios.

What does the ChatGPT directory publish about demand?

Nothing. Zero listings carry a popularity rank, a trending rank or a new flag. Every listing carries a version and sample prompts, so the directory is complete on what an app claims and silent on whether anyone uses it.

How many ChatGPT apps can take a transactional action?

The whole directory declares 17 transactional tools, 0.3% of the 5,300+ it declares in total. Writes are 7% and classifiable reads 6%.

Why are most ChatGPT tool names unclassifiable?

84.7% of declared names cannot be parsed into a verb. They read like capability labels, with object nouns such as review, skill, design, analysis and strategy, rather than typed operations such as create_invoice. That is a structural difference from an MCP server, not a parsing failure.

What category dominates the ChatGPT directory?

Productivity at 23.3% and business operations at 18.6%, which is 41.9% between them. Healthcare is 1.8%, communication 0.9%, security 0.8% and science and research 0.4%.

How does the ChatGPT directory compare to the Claude connectors directory?

They are different kinds of surface. ChatGPT is larger, complete on descriptive fields, silent on capability and popularity. Claude is smaller, publishes a tool list on 98.6% of listings, a trust tier on all of them and a popularity rank on 2,700+. One is a storefront, the other an interface registry.

Do ChatGPT and Claude list the same vendors?

Mostly not. Of 5,100+ vendor domains across both directories, 18.0% appear on both. 2,500+ appear on ChatGPT only.

Does the ChatGPT directory have a discoverability problem?

The data is consistent with one and does not prove it. With no published ranking and 4,000+ listings from 3,600+ vendors, there is no visible mechanism by which a good listing beats a mediocre one. Builders report the same, and at least one has built an unofficial directory in response.

Should I optimise my listing metadata for the directory?

You can, and it is cheap, but nobody can measure whether it works. The directory exposes 100% of the input fields and none of the outcome fields, so metadata is the only lever available and also the only one with no feedback loop.

Is the directory saturated at 4,000+ apps?

Not in the way that number suggests. 94.6% of vendors ship one app, 12.7% declare capability and 0.3% of declared tools can transact. Wide and shallow rather than contested, though wide and shallow with no demand signal is its own kind of hard.

What is a better distribution channel than the directory?

Any channel where you can measure the response. Distribution you control beats distribution you are listed in, particularly when the listing surface publishes no performance data at all.

How does this compare to other app marketplaces?

Mature marketplaces publish install counts, ratings, rankings or revenue share terms, and those signals are what let a developer choose where to build. This directory publishes none of them yet, which places it earlier in its life cycle than its listing count implies.

Can I query this data directly?

Yes. Agent Index covers both official directories and ships seven MCP tools that let an AI assistant search the census, pull per-category coverage and return per-vertical verdicts. The Agent Index MCP guide has example prompts for each.

How often does this change?

The directory changes daily. This is a snapshot taken on 19 September 2026, and we publish no trend claim because we have no time series for this dataset.

BigIdeasDB Research. (2026). ChatGPT Apps Directory: A Market Map for Builders. BigIdeasDB. Retrieved from https://bigideasdb.com/chatgpt-apps-directory-market-map