AgentSkillsHub: a scored directory for Claude Skills and MCP servers

The problem AgentSkillsHub solves, and for whom

The README states the goal plainly: find the right MCP server or Claude Skill in under 30 seconds instead of "spelunking through random GitHub topics". That is a narrow problem, but a real one. GitHub topic pages sort by stars and recency, not by whether a repository documents its install path, exposes a config file, or has a README an agent can parse. Two projects with the same star count can be wildly different in readiness.

The intended reader is someone building with Claude Code, Cursor, Windsurf, Cline or OpenAI Codex who needs a component, not a framework. The directory classifies each project into one of seven categories: mcp-server, claude-skill, codex-skill, agent-tool, prompt-library, ai-coding-assistant, uncategorized. That classification is what makes browsing useful, because an MCP server and a prompt library have almost nothing in common operationally.

The README also claims 117,000+ projects. That number is a claim about catalogue size, not about how many of those projects are any good, and the scoring exists precisely because size alone tells you nothing.

How the collection and scoring pipeline actually works

The pipeline is documented as six phases: Collection, Cleaning, Evaluation, Scoring, Presentation, plus an Upsert step. GitHub Actions triggers it every eight hours. Weekdays get an incremental sync that only touches new or updated repositories; Sundays get a full sync. Each phase has a stated budget, which is the detail that tells you how the system behaves under GitHub's rate limits. Search runs 10+ GitHub queries with a budget of about 30 calls, Masters fetches verified skill creators at about 18, Extra covers community submissions at about 14, Enrich spends up to 500 calls on owner profiles, and README fetches full README content up to 50KB each with a ceiling of 300 calls.

Cleaning deduplicates by repo_full_name, assigns a category by keyword, infers a project type, and buckets size from micro (50KB or less) to large (over 5MB). Evaluation is where the opinion lives. Six quality dimensions carry explicit weights: README Structure 23%, Agent Readiness 20%, then Completeness, Clarity and Specificity at 15% each, and Examples at 12%. The composite score combines nine signals, again weighted: Quality 20%, Stars 18%, Recency 11%, Forks 10%, Commits 10%, Issue Resolution 10%, Momentum 8%, Author Followers 8%, Size Bonus 5%.

The arithmetic matters. Stars and forks together account for 28% of the composite, which is more than the entire quality analysis contributes. The README structure dimension, the single heaviest quality input, measures sections, code blocks, badges and table of contents. A repository with a beautiful README and a mediocre implementation can outrank a terse but correct one. Recency uses exponential decay, e to the minus 0.01 times days, so a project loses roughly 1% of its recency contribution per day. Momentum is a Z-score on star growth. None of these signals inspects the code.

Installing the backend and running the API locally

The README gives a two-part Quick Start. The backend is Python 3.12 with FastAPI, SQLAlchemy and httpx, and the frontend is React 18 with TypeScript, Vite and TailwindCSS v4. Running the backend locally is the fastest way to see what the scoring produces on real data.

The README's backend steps create a virtual environment, install requirements, copy the environment template and start uvicorn:

cd backend
python3.12 -m venv venv && source venv/bin/activate
pip install -r requirements.txt
cp .env.example .env   # Add GITHUB_TOKEN
uvicorn app.main:app --reload

The only variable the README marks as required is GITHUB_TOKEN. The other documented variables are SUPABASE_DB_URL, RESEND_API_KEY, ADMIN_TOKEN and SYNC_INTERVAL_HOURS, which defaults to 8. Without Supabase configured, the README's architecture table lists SQLite as the local database option. Note that the README does not say which of the optional variables the local server needs, so expect to read .env.example rather than the README for that.

Once the server is up, the documented endpoints are plain GET routes. The README lists /api/skills, /api/skills/{id}, /api/trending, /api/rising, /api/top-rated, /api/most-starred, /api/masters, /api/landing, /api/stats, /api/feed.xml and /api/sitemap.xml. The README does not document the port either server binds to, so check the uvicorn output rather than assuming a default. For the frontend, the README's steps are npm install and npm run dev inside frontend/:

cd frontend
npm install
npm run dev

/api/trending returns star velocity leaders over seven days, /api/rising returns projects new this week, and /api/stats returns summary statistics.

Where the scoring model breaks down

The Size Bonus is the clearest example of a metric that can mislead. It gives smaller repositories a higher contribution, on the reasoning that a compact skill is easier to adopt. But a 40KB MCP server and a 40KB abandoned experiment receive the same bonus, and the bonus is applied before anyone has checked whether the code runs. Size is a proxy for focus, and proxies drift.

Issue Resolution at 10% has a subtler problem. It is computed as resolved divided by total. A repository that closes issues aggressively by marking them stale scores better than one that leaves a long tail of unanswered questions, even if the stale-closed issues were real bugs. Nothing in the documented pipeline distinguishes the two.

The README advertises the directory as "security-graded", and links a security report. The scoring tables in the README do not include a security dimension among the six quality dimensions or the nine composite signals. Security grading appears to be a separate layer, and the README does not document how a grade is assigned or what it covers. Treat the grade as a metadata-derived signal, not a code review, and do not let it substitute for reading the source of anything you plan to run with filesystem or network access.

Finally, the star and fork weighting means the composite score is partly a popularity contest. A genuinely useful internal tool with twenty stars will rank below a well-marketed project with two thousand, even if the latter is a wrapper around three API calls.

AgentSkillsHub compared with a curated awesome list

The obvious alternative is an awesome-style list, for example an Awesome agent skills collection. The difference is not format, it is who does the work and when.

A curated list is edited by humans, usually infrequently, and its value comes from the editor's judgement about which entries deserve to be there. It is cheap to maintain, easy to read and impossible to keep current. Entries rot silently. AgentSkillsHub inverts this: the pipeline runs every eight hours and applies the same rubric to every repository, so a project that stops committing visibly loses recency and momentum weight without anyone editing a line. That is the trade-off. You get consistency and freshness, and you give up the judgement that a human editor would apply when deciding that a popular project is actually a bad recommendation.

The other difference is queryability. An awesome list is a document. AgentSkillsHub exposes /api/skills with search, filter and sort, a /compare/ view, and /best/{scenario}/ landing pages, backed by PostgreSQL full-text search using tsvector with a GIN index. If you want to build a tool on top of the catalogue, or filter by category, the API is the reason to pick it. If you want a short reading list, the awesome list is still cheaper.

Maintenance, deployment and licensing

The repository is not archived, and the last push was on 2026-09-15, so the project is current as of that date. The deployment model is unusual in a way that reduces operational cost: GitHub Actions runs sync.yml every eight hours, deploy.yml, and newsletter.yml on Mondays. The frontend is a React SPA on GitHub Pages. Data lives in Supabase PostgreSQL, with email through the Resend API and Supabase pg_net. If you self-host, your recurring costs are Supabase and the GitHub API rate limits, not servers.

The upgrade surface is the schema and the scoring weights. Because scores are computed during Upsert and stored, changing a weight in services/scorer.py does not retroactively rescore existing rows until the next sync touches them. The README does not document a migration or rescoring command, so a weight change and a full Sunday sync are effectively coupled.

On licensing: the repository root listing in the README's own structure includes .gitignore, CLAUDE.md, CONTEXT.md, README.md, backend/, docs/, frontend/, memory/, ops/ and supabase/, and no LICENSE file appears. The README does not state a licence. If you plan to reuse the scoring code or the catalogue data, confirm the licence with the maintainer first. This is not legal advice; it is a gap you should close before depending on the project.

Editorial conclusion

Adopt AgentSkillsHub if you keep losing time to GitHub topic pages and want a scored shortlist of MCP servers or Claude Skills, or if you want to run the pipeline yourself against your own database. Do not adopt it as a security gate: the security grading is a signal computed from repository metadata, not a code audit, and the README does not document what the grade measures. Before you rely on it, check the licence of zhuyansen/agent-skills-hub, since no licence file is listed in the repository root, and read docs/scoring-algorithm.md to see whether the weighting matches how you pick tools.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. zhuyansen/agent-skills-hub on GitHub