An Agent Skill is not a connector
The Skills page listed 153 credentialed third-party integrations and called them skills. Not one of them was an Agent Skill.
Gmail is not a skill. It is an OAuth grant with tool definitions attached, and a page calling it a skill taught nobody which of the two things they needed. The distinction is now structural rather than editorial.
Two objects, two catalogues
An Agent Skill teaches an agent how to do something well. A folder with a SKILL.md at its root: markdown, plus optional scripts and reference files. No credentials, because there is nothing to authenticate against. Portable to any agent that reads a skills directory. The unit of distribution is text, so the copy is the install.
A Connector grants an agent access to a service. Auth config, tool definitions, an endpoint. Connected in the app that holds the credential, bound to the machine it was entered on, and worthless as text — pasting a Gmail connector into a repository gives you nothing but a shape.
One teaches; the other grants access. The archive of the first is at /skills, 10 skills today. The second is at /connectors — 13 built into Lob Bot, plus any MCP server you point it at.
What the official skills carry
Each one holds something this codebase knows that a general model does not: reading a receipt, including the null-versus-zero rule and the named-versus-plan_ceiling baseline; picking a tier instead of defaulting to flagship, with the table generated from MODEL_TIERS so it cannot go stale; holding an agent inside a budget from the per-call receipt; auditing a codebase for unmetered provider calls, with the grep list derived from PROVIDER_BASE_URLS; diagnosing a gateway 400, 402 or 429.
Frontmatter is derived from the typed fields rather than stored beside them, so the card on the page, the YAML an agent matches on, and the bytes the copy button hands you cannot disagree.
There are no install counts, no stars and no ratings. We have none, and a fabricated number is precisely the class of claim the rest of this repository has spent days deleting.
The counts were wrong, and they were our numbers
The published figure counted rows, not connectors. Fifteen ids were declared twice by a block appended in April, and a sixteenth was the same product registered under its own tool-function name — brave and brave_search, unique ids, one search engine, counted twice.
Every lookup goes through getConnectorById, which is a find, so the earlier record has always won. The later ones were dead for every lookup and live only for things that iterate — which is to say, for the count we published and for nothing else.
Keeping the earlier declaration was not a coin toss. The April rows set secret: true on none of their password fields, dropped every helpUrl, replaced real placeholders with "Enter your API Key", and gave Mailgun a domain placeholder copied from the entry above it. Had any of them ever won a lookup, fifteen credentials would have rendered unmasked.
Counts on the site now come from src/lib/counts.ts, which counts the catalogue rather than repeating a number somebody typed.
All posts


