Bot directory: what to check before installing
A bot directory is a browsable catalog of bots you can install. Here is what a listing has to tell you, and the five checks worth making before you run one.
A bot directory is a browsable catalog of bots you can compare and install, each listed with what it does and what it needs from you. That is the whole definition, and it hides an enormous range in practice: some directories list chat commands, some list personas, and a few list things that do real work in your real accounts while you are asleep.
The listing is the only thing you get to read before you hand something access. So the interesting question is not which directory is biggest. It is what a listing is obliged to tell you, and what most of them quietly leave out.
Four things people call a bot
The word stopped being specific years ago. Directories inherited the confusion, which is why two sites that both call themselves a bot directory can have almost nothing in common.
| What people call a bot | Where it lives | What starts it | What the directory usually lists |
|---|---|---|---|
| Chat platform bot | Telegram, Discord, Slack | Someone types a command | Name, blurb, an add button |
| Assistant or custom GPT | A vendor's chat app | You open the chat | A persona and some example prompts |
| Script or RPA bot | Your machine or a runner you maintain | A cron entry you own | A template repo, sometimes a video |
| AI worker | A managed runtime | A schedule or an event | The job, the apps, the exact access level |
The first three rows are the ones most directories are full of, and they share a property: the bot does nothing until a person is present. The fourth row is a different kind of thing, and the reason it needs a richer listing is that it is the only one you are not going to be watching.
If you want the line drawn properly, [AI agent vs AI worker](/blog/ai-agent-vs-ai-worker) is the long version. The neighbouring confusion, between a bot you install into a chat app and an AI plugin, is worked through in agent skills vs plugins vs MCP vs kits.
The five checks
Whatever the directory, five facts decide whether a listing is safe to act on. A good listing answers all five before you click anything. Most answer one.
1. Identity. Whose account does it act as? A bot bolted onto your own login inherits everything you can reach, and its actions look like yours in every audit log. A bot with its own key does not.
2. Permissions. Not "connects to Gmail". Which mailbox, read or write, and what happens when you want to revoke it in six weeks without deleting the whole thing.
3. Trigger. What starts it. This is the fastest way to tell a chat bot from something that will actually take work off you, and it is covered properly in schedule or webhook.
4. Cost. What one run costs, who pays for the model, and whether the price you are quoted is the subscription or the usage. [What an AI worker costs](/blog/what-an-ai-worker-costs) breaks the arithmetic down.
5. Record. What you can read afterwards. If a bot handled forty things last night, you need to know which forty, and what it did to each.
| Check | A listing that answers it | Red flag |
|---|---|---|
| Identity | "Runs under its own key, revocable on its own" | "Sign in with Google" and nothing further |
| Permissions | Per app, at Off, Read or Write, shown before install | "Requires access to your account" |
| Trigger | A named schedule or a specific event | "Just ask it to" |
| Cost | Per run, with the model priced separately | One monthly number, no usage detail |
| Record | A receipt per run, listing every action | A chat transcript, or nothing |
None of these are exotic. They are the questions you would ask about a contractor with a key to the office, which is roughly the arrangement you are entering into.
Why the permission line is the one that matters
Every other check has a workaround. Permissions do not.
A directory listing that says "connects to your email" is describing a request for the entire mailbox, forever, because that is the only thing most connectors know how to ask for. What you want instead is a stated access level per connected app, decided before the bot runs and changeable after: read the calendar, draft but never send, touch this CRM object and no other. That separation is what an app firewall is, and it is enforced outside the model rather than requested inside the instruction.
The distinction is not pedantic. An instruction is a sentence a model can talk itself past under pressure, which is the argument in [why an instruction is not a safety control](/blog/instruction-is-not-a-control). A permission is a wall. A directory that lists the first and not the second is selling you a promise.
What a kit listing shows
WorkerKit's directory is a bot directory in the fourth sense above: every entry is a worker kit, which is a job plus the exact access it needs plus the schedule it runs on, packaged by a publisher so you can read all of it before agreeing to any of it.
A listing carries, on the page, before you install:
- The instruction, in full. The standing brief the worker follows on its four hundredth run, not a marketing summary of it.
- The apps and the level. Which accounts it touches and whether each one is read or write, per app, visible on the listing.
- The trigger. The schedule it ships with, or the event it waits for.
- Model grades. How the same job scored on different models, because the kit is model agnostic and the cheap model is often good enough.
- The publisher, with their other kits and their aggregate numbers.
Some real ones, so this is not abstract: Executive Daily Briefing reads calendar, email and tasks and writes nothing at all. Support Inbox Triager sorts an inbox and drafts, it does not send. Engineering Pulse reads GitHub and reports. Inbound Lead Qualifier is the one that writes to a CRM, which is exactly why its listing says so in the permission strip rather than in paragraph four.
Taking one creates a worker in your own account, with its own key and only the access you granted, in about a minute.
Shortlisting without installing anything
A directory is only useful if you can narrow it before you commit. Three ways that cost nothing:
- By app. The app hubs group every kit by the accounts it touches, so you can start from "what am I already paying for" rather than from a name you have never heard.
- By job. The category hubs answer the query you actually typed, which is usually a job title or a task, not a product name.
- By machine. /kits.md is the whole catalog as plain markdown for an agent to read, so you can hand it to an assistant and ask which three are worth your attention.
Then read the instruction. It takes two minutes and it is the highest value thing you can do in a bot directory, because the instruction is the bot. Everything else on the page is packaging.
When a bot directory is the wrong place to look
Worth saying plainly, because the honest set of cases is smaller than the category's enthusiasm suggests.
- The work is not repeatable. A one off piece of research does not need a key, a schedule and a receipt. Open an assistant instead.
- The job is specific to you. If it depends on your team's private conventions, no published listing will match it. Build it in the studio and keep it private.
- The judgement cannot be written down. If you cannot say what a good run looks like without the word "appropriate", nothing in any directory will do it. What to automate first is the triage.
- A listing is close but not right. That is normal and fixable, and it is its own decision: see when a kit is 80% of what you need.
A directory earns its place when the job is repeatable, its definition of done is writable, and its mistakes are recoverable. Draft an email: yes. Move money: no, or at least not first.
FAQ
What is a bot directory?
A bot directory is a browsable catalog of bots you can compare and install, with each entry listing what the bot does and what access it needs. The quality of a directory is set almost entirely by how much a listing is required to disclose: a name and a blurb is a link list, while a listing showing identity, per app permissions, trigger, cost and the record it leaves is something you can actually make a decision from.
Is a botdirectory the same as a bot directory?
Yes. People type it as one word, botdirectory, and mean the same thing: a place to browse and install bots. The spelling makes no difference to what you should check before installing one, which is the five points above.
Are bots in a directory free?
Usually the listing is free and the running is not. A chat bot costs whatever its vendor charges. Something that runs unattended has a real per run cost, because a model is called every time it runs, and a directory that hides that is hiding the number that matters at scale. WorkerKit's pricing puts the plan and the runtime cost on separate lines for that reason, and the free plan runs 5 workers with no card.
What should I check before installing a bot from a directory?
Identity, permissions, trigger, cost and record, in that order. The one people skip is permissions, and it is the one with no workaround afterwards: a bot granted your whole mailbox on day one cannot be narrowed later without disconnecting it. Read the access level before you read the feature list.
Where do I find a directory of AI workers rather than chat bots?
You are on one. The WorkerKit directory lists workers that run on a schedule or an event on a managed runtime, each with its instruction, its per app access and its receipts visible before install. If you want to publish into it rather than install from it, publishing a kit is the walkthrough, and /publish is the programme.
Can a bot from a directory read my email?
Only if you grant it, and the grant should be specific. A well built listing asks for one app at one level, so "read the inbox, never send" is a state you can choose and later revoke without deleting the worker. If the only option presented is full account access, that is the answer to whether the directory takes this seriously.