Do GitHub stars mean an agent skill or MCP server is safe? What our scan shows

Short answer: no. Stars measure attention, not safety, and in our scan they ran the other way. Of the 89 third-party skills, MCP servers and repos in our catalog with a GitHub star count, the 18 with 10,000+ stars had a high or critical automated finding 38.9% of the time, against 4.2% for the 24 with under 100 stars. The main driver is size: big, popular projects have more code, install hooks and docs for a scanner to flag. After the flagged lines were read, almost all of them passed. So use stars to find candidates, then vet each one the same way regardless of its count.

Stars are the first filter most builders reach for: a skill pack "blowing up on GitHub" (@Pluckycrypto) or "3,973 stars in 18 days" (@virtualunc) is how many tools get shared. This post checks whether that number tells an agent anything about risk, using the per-item results of our static scan of the Upskill library catalog (scans 2026-10-17 to 2026-11-13; method in our security research).

What we compared

Our curated catalog has 119 items. We left out the 26 house items written by Avatar 8 LLC (no GitHub stars) and 4 third-party items without a star count in the catalog file, which leaves 89. For each item we had its star count when it was fetched, the number of files the scanner read at a pinned commit, the automated severity counts, and the final verdict after the flagged lines were read. "Medium or higher" counts what was left after the scanner lowered findings in tests, fixtures and defensive text.

Findings by star count

The shares here are higher than the 41.2% on our research page because that figure also counts the 26 house items and 4 items without a star count, none of which had a medium-or-higher finding.

The most-starred group was flagged the most: 12 of 18 had a medium-or-higher finding and 7 a high or critical one, and 11 got an automated "review" or "reject". The median flagged item had 2,307 stars; the median clean one had 188. Then the reading step reversed the picture: 18 of the 18 items with 10,000+ stars passed, as did 24 of the 24 under 100. The few still at review sit in the middle bands (1 at 100 to 999 stars, 1 at 1,000 to 9,999).

Size explains more than stars

A scanner flags patterns, and a large project has more of them: more dependencies with known advisories, more install scripts, more docs and tests. Popular projects also tend to be large frameworks and libraries rather than single SKILL.md files. The median 10,000+ star item had 554 files scanned against 45 for items under 100 stars. So the star effect above is mostly a size effect; it says nothing good or bad about the authors.

What the high findings in popular repos were

These well-known, heavily starred items had high or critical automated findings and passed once the lines were read:

• Langfuse: npm preinstall and postinstall hooks in package.json.
• CCXT: postinstall hooks, and a curl-to-shell install command shown on its docs site.
• promptfoo: prompt-injection and eval-of-decoded-data examples inside its own red-teaming docs and blog.
• Task Master (claude-task-master): a cat .env line in its CLAUDE.md and AGENTS.md files.
• Beads (issue memory for agents): a postinstall hook and curl-to-shell lines in init templates.
• agent-browser (Vercel Labs): a postinstall script.
• Composio: a dependency name the typosquat rule matched (typescript6 vs typescript).

None of these is a hidden attack, but none is nothing either. An install hook runs code on your machine at install time, and a cat .env line in an agent-facing file tells your agent to read secrets. "Passed after reading" means the line does what the project says it does at that commit. It does not mean your agent should run it unreviewed.

Low stars are not a red flag on their own

Our discovery queue shows the other side. Since 2026-10-17 we reviewed 292 candidates and rejected 240; 123 of the rejected had 5 stars or fewer. But 5 of the 23 we approved had 20 or fewer. A low count is a reason to look harder at who publishes the item and whether anyone uses it, not a verdict. The reverse trap exists too: we rejected a re-upload of another repo that had suspiciously many stars and forks for its age, a known malware-lure pattern (what 240 rejections taught us).

What builders are asking

Of the 198 public posts about skills and MCP servers we collected on 2026-10-25, 7 mention GitHub stars. 5 cite a star count as the reason to try a tool (3 of them the same repo, posted by one account), 1 asks readers for a star, and 1 pitches a tool so you no longer "browse github repos and filter by stars" (Show HN: Skillstore, 2026-10-22). Nobody asked whether stars mean a tool is safe. A small sample is a hint, not demand data.

What to check instead of stars

1. Publisher and origin. Is this the original repo, and does the publisher match the product it connects to?
2. Agent-facing text. Read the SKILL.md, AGENTS.md, CLAUDE.md and prompts for instructions to read secrets, ignore the owner or hide actions.
3. Install path. Look for preinstall and postinstall hooks and curl-to-shell commands, and run installs where they cannot reach your keys.
4. Reach. List what it can touch: files, network, secrets, money. Give it the least access that does the job.
5. Size-adjusted expectations. Expect a large framework to raise flags; read them by category instead of rejecting or ignoring all of them.
6. License and activity. A license GitHub recognizes and recent commits. See the license check.
7. Pin the commit you reviewed. A verdict covers one commit; read the diff before upgrading.

The full checklist with commands is in how to vet an MCP server or agent skill.

What we have not measured

These are 89 items from a curated catalog, not a random sample of GitHub, and items with few stars only got in after passing our own review, which makes them look cleaner than low-star repos in general. Star counts are from the day each item was fetched. We did not measure installs, forks or contributor counts against findings, and a static scan cannot see what a hosted service does. We have not checked any repo for bought stars.

Let a coach pick and prune

Agent Coach matches vetted skills and MCP servers to your agent's job, shows each item's scan result at a pinned commit, and checks in daily on what to keep or remove. It is free. API and MCP details are in the developer docs. Paste one line into your agent:

Read https://upskill.coach/start and follow it.

Related: skills vs MCP servers, how to store API keys for MCP servers.

FAQ

Are agent skills and MCP servers with more GitHub stars safer?

Not in our data. Of 89 third-party skills, MCP servers and repos we scanned, the 18 with 10,000+ stars had a high or critical automated finding 38.9% of the time, against 4.2% for the 24 with under 100 stars. Bigger projects have more code to flag. After the flagged lines were read, 18 of the 18 items with 10,000+ stars passed. Stars measure attention, not safety.

Is a low-star skill or MCP server dangerous?

Not by itself. 5 of the 23 candidates we approved had 20 stars or fewer. Low stars mean little outside review; check who publishes it, whether it is the original source, and read the code yourself.

Can GitHub stars be faked?

Yes. Stars can be bought or farmed, and a re-upload of a popular project can collect stars and forks quickly. In our discovery we rejected a re-upload with suspiciously many stars and forks for its age. Check that the repo is the original source and that its publisher matches the product.

Why do popular repos get more security findings?

Mostly size. In our scan, items with under 100 files had a medium-or-higher finding 26.3% of the time, items with 1,000+ files 85.7%. Popular projects also ship install hooks, curl-to-shell installers and docs that quote attacks, which pattern scanners flag. Each flag needs reading, not panic.

What should I check instead of stars?

The publisher and whether it is the original repo, what the agent-facing files tell the agent to do, install hooks and install commands, what it can reach (files, network, secrets, money), the license, recent commits, and the exact commit you reviewed. Pin that commit.

Questions or corrections: ops@avatar33.com.