Methodology: how we select and check entries

Sources

We look for candidates on GitHub by ecosystem topics (mcp-server, claude-skills, agent-skills, claude-code-plugin and similar) and in public catalogs of skills and MCP servers. From other catalogs we take only the link to the original source.

Anyone can suggest an entry through the submission form. A submission goes through the same rules as the editors’ own finds.

How we select

We decide by what is in the repository and treat the description as a hint. We look at the file tree for something you can install: SKILL.md, plugin.json or marketplace.json, package.json or pyproject.toml, an MCP server launch, commands in the README. Many stars count in favor of listing, and we check such repositories with extra care.

We do not list:

• repositories that are missing, archived or empty;
• projects that are not a skill, MCP server, plugin or CLI for agents: plain libraries, websites, link lists without their own code;
• projects whose README does not explain what they do and how to install them;
• little-known projects with no commits for more than 18 months;
• duplicates of published entries and forks without changes;
• collections that only gather other people’s skills;
• malicious tools, protection bypass, data theft, spam.

How a card is written

The editors write each card from the author’s README, SKILL.md and manifests: what the tool does, who needs it, when it does not fit, its limitations and how to remove it. We draft with the help of AI and check the draft against the repository files. Install commands come only from the author’s documentation. If the author gives no command, we say so.

The editors write the English text together with the Russian one. When it is missing, the site machine translates the Russian text with a domain glossary, and until then the English page shows the Russian text with a note.

GitHub data and counters

• A background job takes stars, forks, license, the archived flag and the last commit date from the GitHub API and goes through the whole catalog once a day. The date of the last check is shown on the card.
• Stars describe the whole repository and are labeled as repository stars. Skills from one monorepo share one number.
• The copy counter counts clicks on the copy button next to a command on the site.
• The install counter counts distinct devices in 30 days from CLI and MCP events, CI runs excluded. A card shows the number from 10 installs.

How we keep the catalog current

The system checks every GitHub entry once a day. A problem counts as confirmed after two checks in a row about a day apart, so a one-off GitHub failure changes nothing.

• The repository is deleted: the entry is unpublished and its address leads to the catalog section.
• The repository is renamed or moved: the link updates itself.
• The author archived the repository or has not updated it for over a year: the entry stays with a note on the card and keeps its place in listings.
• The license changed, stars dropped sharply or the skill folder is gone: the editors decide.
• If the check itself fails on a noticeable part of the catalog, changes stop until it recovers.

Access level

The access level shows what a tool adds to what the agent can already do. It does not rate code quality. The agent already reads the files of your project, so reading those files does not raise the level by itself.

The editors set the level and reasons from the README, the launch method and the permissions the tool needs. There is no automated code audit yet.

• Minimal: instructions, rules and reference material. The tool runs nothing and makes no network calls.
• Extended: the tool runs code or makes network calls and only reads data from external services.
• Broad: the tool writes or deletes data, runs commands, or handles secrets, money, email or personal data.

How access affects installation

An entry with broad access, or with a level that has not been set yet, gets no one-click install into Cursor and VS Code on its card. The CLI installs a broad access entry only after explicit consent and shows the reasons first.

Install recipes

A recipe is a machine-readable install description: which components get installed (a skill, MCP server, plugin, CLI or agent rules), from which commit and which variables they need. Arbitrary commands from a README never go into a recipe.

We build a recipe in three layers:

• repository manifests at the pinned commit: server.json, marketplace.json and plugin.json, folders with SKILL.md, package.json and pyproject.toml;
• commands and MCP fields from the card: npx skills add, claude mcp add, JSON configs, /plugin install, package installs with npm, pip, brew, cargo and go;
• an AI model reading the README, when the first two layers find nothing or disagree. We look up every path from the model’s answer in the repository tree and every package in npm, PyPI or Docker Hub. If even one is missing, we reject the recipe.

Recipe checks

• The commit is pinned by SHA. Skill files get one sha256 digest, so a recheck notices any edit.
• The schema rejects a recipe with values that look like secrets or with paths outside the repository.
• A recipe holds no secrets: an environment variable name stands where a value would be.
• Every recipe response in the API is signed with an Ed25519 key, and the CLI checks the signature before installing.

Recipe statuses

• auto: built from manifests and card data, the sources agree, no AI involved.
• ai: built by reading the README, paths and packages were found. Nobody checked it by hand, so the card and the CLI show a warning.
• verified: a person on the editorial team checked the recipe. This is the only status that means a manual check, and no entry gets it automatically.
• review: a recheck found a change that matters for security. Until the editors review it, the site, API and CLI serve the last accepted version.
• unsupported: no automatic install, the card shows the author’s manual instructions.

Recheck against the repository

A background job rechecks recipes about once a week, and sooner after a card edit. Same commit: only the check date changes. New commit with the same component files: the recipe moves to the new commit. A changed launch command, package, arguments, variables, network addresses or scripts in the skill folder: the new commit is not accepted and the recipe goes to review.

npx skillfoxx update installs only a version that passed this recheck.

What “checked” and “verified” mean

The “Checked against the repository” line on a card means an automatic recheck of the recipe against a commit. There is no manual code audit behind it. The “Recipe checked by hand” note appears only on recipes with status verified.

What we do not guarantee

• That third-party code is safe or works.
• That the author will not change the repository, a registry package or a remote server after our recheck. npm and PyPI packages without a pinned version and remote MCP servers can change at any time.
• That the access level reasons are complete: we read the README, manifests and launch files and do not review the code line by line.
• Compatibility with every version of every agent.

Editors’ pick

The editors set this badge while preparing a card. Projects by well-known vendors and widely used projects get it. The badge reflects an editorial opinion and measures nothing. It cannot be bought.

How Foxx AI picks tools

Foxx AI suggests only catalog entries. First the site shortlists candidates by matches with the project’s dependencies, frameworks and files and by the meaning of the request. Then an OpenAI model explains why each entry fits. Entries in the matches follow the same selection rules as the whole catalog, and there are no paid spots.

On an entry page Foxx AI answers about the tool itself only from the card data and the README. When they hold no answer, it says so and links to the repository.

Incidents

If an entry turns out to have a serious vulnerability or malicious code, we open an incident and unpublish the entry when needed. While an incident of high or critical severity is open, neither the CLI nor MCP installs the entry. Use the report button on any entry page to tell us about a problem.