Most of the work sold under AI visibility aims at one outcome. An assistant answers a question, and your brand appears in the answer because something it read said so. That is citation, and it is earned from the outside.
There is a second way in, and it works nothing like the first. A user installs your plugin, and from then on the assistant calls your software directly. You aren’t a source it found, you’re a tool it holds.
OpenAI moved that surface in July 2026, and the ChatGPT plugin directory is now where it lives. It rewards different work than citation does. Below is what the directory is, how it decides to call one tool over another, and what its review gate refuses.
There is also an honest case for most companies leaving it alone this year, and that case is made here too.
Cited and Connected Are Two Different Jobs
It helps to separate the two outcomes before comparing them, because they get sold as though they were the same thing.
Being cited means retrieval found a page, the model used it, and a reference appeared. The buyer never chose you. They asked a question, and you were part of the answer that came back.
Being connected means the buyer chose you deliberately. They installed a plugin and authorised it, so the assistant can now call it. None of that happens by being found.
| Cited | Connected | |
|---|---|---|
| How you get there | Something the model reads mentions you | A person installs your plugin |
| Who decides | The retrieval layer | The user, or their workspace admin |
| Reaches people who | Have never heard of you | Already know who you are |
| What you control | What gets published about you | Your own metadata and software |
| What it costs | Editorial and outreach work | Engineering, review, maintenance |
Read the third row twice, because it decides the strategy. Connection sits downstream of awareness, and it isn’t a substitute for it.
Nobody installs a plugin from a company they’ve never encountered. The install is a decision made after the introduction, so the surface that produces introductions still has to work first.
What Changed in July 2026
On 9 July 2026 OpenAI migrated its app directory into a plugin directory. Plugins became, in OpenAI’s own wording, the primary way to discover workflow capabilities across ChatGPT and Codex.
Existing connections carried over untouched. What changed is the packaging and the shop window, not whether your integration kept working.
One detail in the architecture documentation matters more than it first appears. ChatGPT and Codex share a single universal directory, so one public listing is discoverable from supported surfaces in either product.
That is a single listing reaching two unrelated audiences. A tool built for marketers sits in the same directory a developer browses from inside a coding environment.
What a Plugin Is Made Of
A plugin is a package. It can hold either of two things, or both of them together.
Skills
A skill is a folder holding an instruction file, plus any scripts, references or templates it needs. It tells the model when to use a workflow, which steps to follow, and what a good result looks like.
Skills are the smaller shape, and OpenAI recommends starting there. If written instructions plus the tools the model already has would finish the task, you don’t need to build a server at all.
One plugin can package a single skill or group related ones together. A meeting follow-up plugin might carry separate skills for drafting a recap, pulling out action items, and preparing a customer email.
MCP servers
MCP is the Model Context Protocol, the open standard an assistant uses to call external tools. A server built on it defines the tools available, their input and output schemas, the authentication required, and what comes back.
You need one when the plugin has to reach a service you operate, authenticate a user, or run behaviour on infrastructure you control. The server is also where you decide which capabilities to expose and which to withhold.
What a connected app can do
The capability range is wider than most people assume. Apps inside a plugin can search your connected data sources and pull that context into the conversation.
They can take write actions, feed multi-source research that cites back to originals, render interactive cards, and sync content in advance into a workspace knowledge base. Permissions default to a setting OpenAI calls important actions.
Under that default, reading happens automatically. Anything with meaningful effect outside the conversation gets a confirmation prompt first.
How ChatGPT Decides To Call Your Tool
Here is the sentence that should interest anyone who has ever written a title tag. ChatGPT and Codex decide when to call your tool based on the metadata you provide.
Not on your install count. Not on your domain authority. On the names, descriptions and parameter documentation you wrote.
OpenAI’s guidance is to treat that metadata like product copy. It needs iteration, testing and analytics rather than a single pass at launch, and the recommended conventions are specific.
Name
Pair the domain with the action, in the shape used by an example like calendar.create_event. The name carries meaning to the model, so a vague one costs you selections.
Description
Open with the words “Use this when”, then name the cases where the tool should not fire. Stating the exclusions isn’t optional politeness, it’s how you keep the tool quiet on requests that belong elsewhere.
Parameter documentation
Describe every argument, give examples, and constrain inputs to allowed values wherever the input permits it. A model that cannot tell what an argument expects will either guess or skip your tool.
Behaviour hints
Mark tools that only retrieve or compute with a read-only hint. On everything else, declare whether it deletes or overwrites user data, and whether it reaches outside the user’s own account.
Anyone who has written meta descriptions will recognise the shape of this problem. You are writing for a reader that decides in one pass whether you are relevant, and your competitors write for the same reader.
The difference is that this reader reports back. You can watch which tool it picked and which arguments it passed.
The Golden Prompt Set Is Keyword Research in New Clothes
Before touching any wording, OpenAI’s guidance is to assemble a labelled set of prompts and record what should happen for each one. It calls this a golden prompt set, and it has three parts.
Direct prompts
The user names your product or your data source outright. These are the straightforward ones, and they map cleanly onto branded search.
Indirect prompts
The user describes the outcome they want without naming any tool. This is the entire non-branded opportunity, and it is where the wording of your description does the real work.
Negative prompts
Cases where your tool should stay silent, because a built-in capability or another company’s plugin is the right answer. Classic keyword research has no equivalent, and it is the part most teams would skip.
Document the expected behaviour for every prompt, then keep the set. It becomes the regression test you rerun each time the metadata changes.
Testing runs in developer mode, switched on under settings, with your server registered in the plugins area of ChatGPT. For each prompt you record which tool was selected, which arguments were passed, and whether the interface rendered.
Precision Comes Before Recall
Two measures come out of that test set, and they pull against each other.
Precision asks whether the right tool ran when something ran. Recall asks whether your tool ran on every prompt where it should have.
Loosen a description to catch more prompts and recall climbs while precision falls. The tool starts firing on requests it has no business handling, and tightening the wording reverses both effects.
OpenAI’s stated priority here is unambiguous. Aim for high precision on the negative prompts before chasing marginal recall improvements.
That reverses the instinct most marketing teams bring to a new channel. Broad-match thinking says cast wide and sort it out later, which here produces a tool users learn to distrust because it interrupts requests that were never for it.
The operational advice is equally plain. Change one metadata field at a time so improvements can be attributed, keep a dated log of revisions and results, then replay the prompt set after every change.
Once you are live, review tool-call analytics weekly. Spikes in wrong-tool confirmations usually mean the metadata has drifted away from what the tool now does.
In Companies, an Admin Decides Before the User Does
Consumer thinking about installs misses the gate that matters for business software. In a workspace, administrators manage which plugins can be installed from workspace settings.
They can also manage each underlying app’s access and permissions, and configure which actions require confirmation. The individual user’s enthusiasm is not the deciding vote.
For anyone selling into companies, this reshapes the whole funnel. Your buyer may want your plugin and still be unable to add it, which puts your listing in front of a procurement conversation rather than a one-click decision.
It also means the qualities that clear an internal review matter as much as the ones that win a user. Clear permissions, a real privacy policy and predictable behaviour become distribution features, not compliance overhead.
What the Review Gate Rejects
Public listings go through review, and the published guidelines are more specific about failure than most application store rules.
- No duplicating built-in capability. A plugin must do something the products can’t already do.
- No copycats. Misleading or imitative designs, impersonation and spam are named directly.
- No static shells. Frames with no meaningful interaction are rejected.
- No implied endorsement. A plugin must not suggest OpenAI made or approved it.
- No generic names. Single-word dictionary terms untied to your brand get called out.
- No advertising. Plugins cannot serve ads or exist mainly as an advertising vehicle.
- No hijacking. Inserting unrelated content or redirecting the interaction is prohibited.
Submissions must also come from a verified individual or organisation, confirmed through the OpenAI platform dashboard. Misrepresentation, hidden behaviour or attempts to game the system can remove a developer from the programme entirely.
Notice how much of that list concerns intent rather than code quality. A technically sound plugin built as a marketing channel fails on purpose grounds before anyone inspects the server.
The Fair Play Clause Bans the First Thing an SEO Would Try
One clause deserves its own section, because it forecloses a tactic otherwise sitting in plain sight.
If a model chooses tools by reading descriptions, then writing a description that tells the model to prefer you looks like the obvious move. That is prompt injection as competitive strategy, aimed squarely at the selection step.
The guidelines close that door by name. Plugins must not include descriptions, titles, tool annotations or other model-readable fields that manipulate how the model selects or uses other plugins. The prohibition applies at both tool and plugin level.
Interfering with fair discovery is listed as its own violation. The clause then goes one step further, requiring that descriptions reflect your value accurately and without disparaging alternatives.
Anyone who watched keyword stuffing get priced out of search will find this familiar. A surface opens, the manipulation is obvious, and this time the rule against it arrives early rather than after a decade of escalation.
What survives is the unglamorous version. Describe what your tool does and when it should stay quiet, then test whether the model agrees with you.
What the Directory Does Not Publish
One limit belongs in any honest brief on this surface. OpenAI documents how a model chooses between tools it already has. It doesn’t publish how listings rank against each other inside the directory.
That distinction matters more than it sounds. Tool selection is documented and testable, while directory placement is neither.
So anyone selling you a ranking method for the listing itself is describing something with no published mechanism. The honest position is that nobody outside OpenAI knows how placement works.
Treat the tested part as the work. Your golden prompt set produces evidence you can act on, whereas listing position produces speculation.
What Happened When We Shipped Our Own
Enthusiasm about this surface should meet first-party evidence, and we have some, because we shipped MCP tools on this site and logged the result.
Across 75 days, agents read the tool listing regularly and called it 77 times. The full breakdown of those logs is worth reading before anyone budgets for this work.
Reading and calling turned out to be different behaviours. Assistants inspected what was on offer far more often than they used it, and that gap is the thing to plan around.
It is also the gap the precision and recall guidance exists to close. Our conclusion was to ship four well-described tools rather than thirteen thin ones, and nothing in OpenAI’s newer guidance contradicts it.
The practical lesson was about expectations rather than engineering. A tool listing is inventory an assistant can draw on, and inventory doesn’t move because it exists.
If you build here, plan for a long stretch where the logs show interest without action. That stretch is normal, and it’s the period where description quality either earns calls or doesn’t.
The Surfaces Churn Faster Than the Strategy
Checking the documentation for this article turned up something worth stating plainly.
ChatGPT Atlas, the browser launched with considerable noise in October 2025, is deprecated. Standalone agent mode is retired and folded into ChatGPT Work, and the app directory itself became the plugin directory in July.
Three named surfaces changed status inside roughly ten months. Any strategy built around one product name inherits that instability.
What didn’t move is the mechanism underneath. Assistants still select from what is available based on how it is described, and they still need something outside themselves to establish that you exist.
That holds for a tool listing exactly as it holds for a page competing to be read. The container changes far faster than the rule.
Who Should Build One, and Who Should Not
The gate is specific enough to answer this quickly.
Worth considering
You have a real product with an API, and users who would rather operate it inside a conversation than open your interface. The plugin does something the assistant cannot already do without you.
You also have engineering capacity for the ongoing part, not only the launch. Weekly analytics review, prompt replays and metadata revisions are maintenance, not a project with an end date.
Not worth it
You run a services business, an agency or a content site. There is no software for a plugin to call, and one built to promote you fails the advertising and purpose rules directly.
You would be wrapping a thin layer over something built in. That is the first rejection reason on the list.
You want it for visibility rather than utility. The rules are constructed to catch exactly that, and a listing nobody installs produces nothing anyway.
How This Sits Beside Citation Work
For most companies reading this, the plugin directory belongs to their product team rather than their marketing team. That isn’t a dismissal, it’s a scoping decision.
The reason is the awareness dependency described at the top. A listing converts people who already know your name, so the work that creates recognition has to run either way.
That work hasn’t changed shape. Assistants still assemble answers from sources they trust, and they still let the user narrow which sources count in research modes.
Being mentioned by those sources remains how an unfamiliar brand enters the conversation at all. No amount of plugin engineering substitutes for it.
If you do ship a plugin, the same discipline applies in a new place. You’ll be writing careful descriptions of what you do, testing whether a machine understood them, and revising when it didn’t.
That is recognisably the job you already know. Only the field you’re typing into is new.
Frequently Asked Questions
What is the ChatGPT plugin directory?
It is the shared listing where people discover, install and share plugins in ChatGPT and Codex. OpenAI migrated its earlier app directory into it on 9 July 2026, and describes plugins as the primary way to discover workflow capabilities across both products.
How does ChatGPT decide which plugin tool to call?
You write the metadata that decides it. OpenAI’s guidance states that ChatGPT and Codex choose a tool from its name, description and parameter documentation. It recommends treating that copy as a product asset needing testing and iteration.
Can I write a plugin description that tells the model to prefer my tool?
No. The plugin guidelines prohibit descriptions, titles, tool annotations or other model-readable fields that manipulate how the model selects other plugins or interfere with fair discovery. Descriptions must also avoid disparaging alternatives.
Does publishing a plugin help my brand get cited in ChatGPT answers?
They are separate mechanisms. Citation comes from retrieval finding published sources that mention you, while a plugin runs only after a user installs it. Since people rarely install tools from companies they do not recognise, awareness work still has to happen first.
What gets a plugin rejected at review?
Duplicating built-in capability, copycat or misleading design, impersonation, and spam are all named. So are overly generic names, serving advertising, existing mainly as an advertising vehicle, redirecting the conversation, and collecting data beyond what the request needs.
Should a marketing agency build a ChatGPT plugin?
Usually not. A plugin needs software for the assistant to call, and one built primarily to promote a business fails the purpose and advertising rules. Agencies are better served by the work that gets their clients mentioned in sources assistants already read.