whichlib
whichlib is an MCP server that helps coding agents choose verified open-source libraries using scored recommendations, comparisons, and trending repos.
recommend_repos: Find the best repositories for a plain-language need (e.g., "python pdf parser") with optionallanguageandlimit, ranked by fit = score × relevance; returns score, tier, verdict, breakdown, packages, and downloads.compare_repos: Compare 2–10 knownowner/reponames side by side, best score first, with scores, tiers, verdicts, metrics, and downloads; missing repos go undernotFoundwithout failing the whole call.trending_repos: Discover the most-starred repos created in the last day/week/month orrisingrepos by stars gained this week, optionally filtered by language, limit, andwithDownloads.Every result includes a transparent 0–100 score from momentum, maintenance, adoption (stars, forks, npm/PyPI downloads), and license, plus a tier (Strong/Solid/Watch/Avoid/New) and a one-line verdict.
Runs over stdio or hosted HTTP; supports optional
GITHUB_TOKENfor higher rate limits and optional star-history downloads for real momentum scoring.
Uses the GitHub Search and repository APIs as the core data source: it retrieves candidate repositories for a plain-word need (by relevance order, stars order and topic queries), reads signals such as stars, forks, open issues, license, topics, last push date and archive status, and produces scored, tiered recommendations, side-by-side comparisons and lists of the most-starred repositories created in the last day, week or month.
Resolves JavaScript/TypeScript repositories to their published npm packages (trying <repo> and @<owner>/<repo>) and fetches last week's download counts from npm, which feed the adoption part of each repository's score and appear in verdicts and results.
Resolves Python repositories to their published PyPI packages and fetches last week's download counts, which feed the adoption part of each repository's score and appear in verdicts and results.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@whichlibwhich library should I use for date parsing in TypeScript?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
whichlib
The dependency picker for coding agents. Ask which library to use and get a scored, verified answer instead of a guess.
whichlib is an MCP server with three tools (recommend_repos,
compare_repos, trending_repos) and a free dashboard, Fresh Repos, that
shows the most-starred GitHub repositories created in the last day, week and
month. Every repository gets a transparent 0–100 score from momentum,
maintenance, adoption (stars, forks, npm and PyPI downloads) and license,
plus a one-line verdict.
For teams (waitlist): alerts when a dependency your repos use goes stale, and rules your team's coding agents must follow when they add one. Add a 👍 to the waitlist issue; at 20 signups it gets built. whichlib itself stays free.
Quick start
Agents: see MCP server below for the one-line install.
Dashboard: open whichlib.com/repos. The page calls the GitHub Search API straight from your browser. No account.
Optional: paste a GitHub token under Settings on the page to raise the API limit from 10 to 30 requests per minute. A fine-grained token with no permissions is enough. It stays in your browser's local storage.
Related MCP server: mcp-github-tools
What you get
Three tabs: Today, This week, This month. Each lists the 100 most-starred repos created in that window.
Sort by any column: stars, stars per day, forks, open issues, created date, last push, language, license or name. Click again to reverse.
Filter by language (17 languages) or by free text over name, description and topics.
The rank column always shows the stars rank, so after sorting by forks you still see where a repo stands.
Results are cached in the browser for 60 minutes per tab and language.
Light and dark themes follow your system setting.
How the numbers are defined
Trending here means "created in the period, ranked by stars". That is what the GitHub Search API supports. GitHub's own trending page ranks by stars gained in the period, which has no public API. The nightly snapshots in this repo will make that possible later.
Downloads do not exist for repositories on GitHub, only for release files. Forks are shown as the nearest public signal.
Stars/day is stars divided by the repo's age, floored at one hour.
Score
Every repo gets a score from 0 to 100, a tier and a one-line verdict. The
breakdown is always returned so a person or an agent can see why. The same
file, whichlib/lib/score.js, runs in the dashboard and in Node, so
the two can never disagree.
Part | Weight | Signal |
Momentum | 40% | Stars gained over the last 7 days from our daily star counts (top 1,000 repos per language plus new trending repos). Without history, stars per day since creation times 7, with age floored at one day, scaled by the npm/PyPI download trend when known (last week against the three weeks before, clamped to 0.5–2x). Log scale: 50 a week is already good, 5,000 is the max. |
Maintenance | 25% | Days since last push: full marks up to 30 days, zero at 365, linear between. Minus 0.2 when open issues exceed a tenth of the stars. Stability guard: a repo with 10k+ stars or 100k+ weekly downloads, pushed within the last year and not archived, never drops below 0.5 here. Heavy use plus silence is stability, not decay. |
Adoption | 25% | With weekly downloads known: 50% stars (max 100k), 20% forks (max 20k), 30% downloads (max 1M). Otherwise 70% stars, 30% forks. All log scale. |
License | 10% | Permissive 1.0, weak copyleft 0.75, strong copyleft 0.5, unrecognised 0.5, none 0. |
Tiers: Strong 75 and above, Solid 50, Watch 25, Avoid
below 25. Repos younger than 30 days get New instead, with the flag
too-new and a verdict that starts "Too new to judge": a launch burst of
stars and a push today say nothing yet about upkeep. Their 0-100 score is
still computed, so rankings do not change. The names are chosen to read correctly for a six-week-old project
and a six-year-old library alike. Archived repos are capped at 20 and get the
verdict "Archived, avoid." A missing license is always named in the verdict.
Verdicts read like "Rising fast, 10.6k downloads/wk, pushed 2 days ago, MIT", "Gaining steadily, 145M downloads/wk, quiet for 6 months, widely used, BSD-3-CLAUSE" or "Slow growth, no push in 60 days, GPL-3.0".
Downloads
GitHub has no download count for repositories, but package registries do. After each snapshot, the enrich step maps JavaScript and TypeScript repos to npm and Python repos to PyPI, then fetches last week's downloads:
A package counts as the repo's only when the registry's own metadata links back to
github.com/<owner>/<repo>. A matching name alone is never enough, so a new repo calledwidgetis not credited with the downloads of an unrelatedwidgetpackage.Candidates tried:
<repo>and@<owner>/<repo>on npm,<repo>on PyPI.Mappings are cached in
registry-map.jsonon thedatabranch. Negatives are re-checked after 7 days, positives kept, downloads refreshed daily.On the first run, 63 of 858 eligible repos mapped to a package. Most repos under a month old are not published yet, which is expected.
Other languages (Rust, Go, Java...) are skipped for now. Cargo, Go and Maven can follow the same pattern.
Caveat: the dashboard has no snapshot history, so momentum uses the fallback. Scores on the Today tab are therefore provisional; the report and the MCP server use real stars-gained figures once there are two or more days of snapshots.
cd whichlib
npm run score # top 25 repos from the latest snapshot with score and verdictMCP server
The same score, served to coding agents. Three tools over stdio, or remote
at https://whichlib.com/mcp. Speaks MCP 2026-07-28; older clients keep
working.
Tool | Input | What it returns |
|
| The best repositories for the need, ranked by fit (score × relevance), with npm/PyPI downloads and a verdict each. Candidates come from GitHub's relevance order, its stars order and a topic query; see "How recommend finds and ranks candidates" below. |
|
| The repositories side by side, best first, same breakdown. |
|
| Most-starred repos created in the period, scored. |
Every result carries readable text and structuredContent (JSON) with the
score, tier, verdict, the four subscores, flags, packages and downloads.
Requires Node 22 or newer. Install into Claude Code (-s user makes it
available in every project):
claude mcp add whichlib -s user -- npx -y whichlibOr as a Claude Code plugin, which connects to the hosted server (nothing to install) and adds a skill that makes Claude check a library with whichlib before adding it (josifb/whichlib-claude-plugin):
/plugin marketplace add josifb/whichlib
/plugin install whichlib@whichlibCursor, Windsurf, Claude Desktop and others take the same command in their MCP config:
{ "mcpServers": { "whichlib": { "command": "npx", "args": ["-y", "whichlib"] } } }Use it without installing: the hosted server needs no Node.
claude mcp add --transport http whichlib https://whichlib.com/mcpLimits and the web API are on whichlib.com/docs.
To run from a clone instead: node whichlib/mcp/server.mjs.
Environment variables, both optional:
GITHUB_TOKENraises GitHub's limits (search 10 to 30 per minute). A fine-grained token with no permissions is enough. Recommend makes three searches per call, so without a token it allows about three recommendations per minute.Star history: momentum uses real stars gained per week for the top 1,000 repos per language plus new trending repos, from daily star counts on the
databranch. Installed from npm, the server keeps the last 10 days in~/.whichlib/stars/and refreshes them in the background at most every 12 hours fromraw.githubusercontent.com(public files, no token, nothing sent).WHICHLIB_HISTORY=offturns the download off; repos without history fall back to stars per day since creation. In a clone,npm run pull-datafillswhichlib/data/starsinstead, andFRESH_REPOS_DATA_DIRpoints at any folder of daily files.WHICHLIB_TELEMETRY=offorDO_NOT_TRACK=1disables anonymous call counting. What is counted: tool name, a random install id, version, platform, Node major version and the MCP protocol version of the call. Never queries, repository names or results. The collector is a small Cloudflare Worker intelemetry/, and its aggregate numbers are public at https://whichlib-telemetry.todorovskijosif.workers.dev/stats.
Try it without a client:
cd whichlib
npm run mcp:smoke # starts the server over stdio, lists tools, calls each oneKnown bias, reduced: maintenance used to drop to zero at 90 days without a push, which put httpx (145M weekly downloads, six quiet months) in "Watch". The curve now runs to a year and the stability guard keeps widely used repos at 0.5 or better; httpx lands in "Solid". Release cadence from the GitHub releases API is the proper long-term signal and is still to come.
Recommendation eval
mcp/eval/needs.json holds 20 needs ("pdf parser" in Python, "state
management" in TypeScript, ...) each with a set of accepted answers a senior
engineer would consider reasonable. npm run eval runs them through
recommend_repos live and reports how often an accepted repo appears at
rank 1, 3 and 5, for our ranking and for baselines built from the same
candidate pool. Reports land in mcp/eval/results/.
Result on 2026-09-27, after query expansion (second report in results/):
Ranking | hit@1 | hit@3 | hit@5 | MRR |
ours (fit, see below) | 75% | 95% | 100% | 0.85 |
GitHub relevance order | 65% | 80% | 95% | 0.76 |
stars order | 45% | 65% | 75% | 0.56 |
score only, no relevance | 30% | 65% | 70% | 0.46 |
The first report, before expansion, had the same hit rates for our ranking (75 / 95 / 100, MRR 0.86) on a smaller pool. Expansion raised recall from 53 to 74 accepted repos across the 20 pools, never fewer on any need, and the baselines fell on that noisier pool while ours held. The fit rules are what keep the noise out.
How recommend finds and ranks candidates
Retrieval, three GitHub searches per need:
Text search in GitHub's relevance order, with known synonyms OR-ed in (
async OR asynchronous runtime), so vocabulary differences stop hiding libraries like tokio.The same text search in stars order, for the big names whose description only mentions the subject.
One topic query sorted by stars (
topic:cli,topic:image-processing), which surfaces what maintainers tagged themselves. The head word is used when it is specific (pdf, cli, orm) and the hyphenated phrase when it is broad (image-processing, state-management). GitHub rejectsORbetween topics, so it is one per request.
Language filters use families: JavaScript includes TypeScript and Python includes Jupyter, because many libraries moved to TypeScript.
Ranking key is fit = score × relevance:
relevance is 1.0 at GitHub relevance rank 1 falling to 0.5 at rank 25, 0.75 when found only through the topic query, 0.4 when found only in the stars order;
×0.75 when the repo names the subject only in its topic tags and ×0.5 when nowhere in its name, description or topics (it matched README text only);
×0.8 when you asked for a framework, library, parser or client and the repo reads like an application rather than a building block.
On the hosted service (whichlib.com), relevance instead uses a TypeSafe Jev
judgment of whether each candidate is an installable library whose main
purpose is the need (returned as signals.jevFit, with a weak-fit flag below
0.5) in place of the word-match factors; the npm package and own-token calls
use the word-match rules above.
Both score and fit are returned, with the relevance rank, the sources the
repo came from and the two signals, so an agent can see why.
node mcp/eval/inspect.mjs "<need>" [language] [wanted/repo ...] prints the
whole candidate pool for one need with these values.
Nightly snapshot job
whichlib/snapshot/ is a zero-dependency Node 22 script that stores the
top 100 repos for 3 periods times 9 languages into
whichlib/data/snapshots/YYYY-MM-DD.json. Consecutive snapshots are
what a momentum score needs.
cd whichlib
npm test # 16 unit tests, no network
npm run snapshot # about 3 minutes without a token, 1 minute with GITHUB_TOKENA GitHub Actions workflow (.github/workflows/snapshot.yml)
runs the job every day at 06:17 UTC and commits the result to the data
branch, so history accumulates without bloating main. Trigger it by hand
from the Actions tab or with gh workflow run snapshot. Bring the files down
locally with:
cd whichlib
npm run pull-data # copies new snapshots from origin/data into data/snapshots/
npm run score # now with real 7-day stars gained once there are 2+ daysA Windows Task Scheduler alternative is in
whichlib/README.md.
Repository layout
whichlib/ the npm package: MCP server, score, dashboard, jobs, eval, tests
whichlib/dashboard/ redirect to whichlib.com/repos
site/repos/ Fresh Repos dashboard (source)
whichlib/lib/ score.js, shared by browser and Node
whichlib/mcp/ MCP server: recommend_repos, compare_repos, trending_repos
whichlib/snapshot/ snapshot job, enrichment, history builder, score report
whichlib/server.json MCP registry manifest
telemetry/ call counter: Cloudflare Worker + Analytics Engine
RELEASING.md release stepsRoadmap
Done: dashboard, nightly snapshots, transparent score with tiers and verdicts, npm and PyPI downloads, MCP server with recommend, compare and trending tools.
Named whichlib. Package shape,
server.jsonfor the MCP registry and the call counter are ready; remaining: deploy the counter, make the repository public,npm publish,mcp-publisher publish, list in the Claude Code plugin marketplace and the awesome-mcp lists.Then wait four weeks and read weekly active installs and calls per install. That decides whether the team tier with policy rules gets built.
Later: Cargo, Go and Maven adoption; release cadence in maintenance; downloads in the dashboard; grow the eval past 20 needs from real usage.
License
MIT.
Available Tools
3 toolscompare_reposCompare repositoriesARead-onlyInspect
Compare 2-10 known GitHub repositories side by side, best score first: score and tier, stars, forks, open issues, last push, license, npm/PyPI weekly downloads (only when the registry links back to the repository) and a verdict. Each result has a 0-100 score (momentum 40% (stars gained per week; without history, lifetime stars per week scaled by the npm/PyPI download trend), maintenance 25%, adoption incl. npm/PyPI weekly downloads 25%, license 10%), a tier (Strong >=75, Solid >=50, Watch >=25, Avoid <25; New for repos under 30 days old, too new to judge), a one-line verdict and the full breakdown. Use this to choose between candidates you already have (for example zod vs valibot) or to check a dependency the project already uses; use recommend_repos to find candidates. One GitHub API call per repository plus npm/PyPI lookups. A repository that does not exist is listed under notFound and the rest are still compared; the call fails only if none can be fetched, or when GitHub's rate limit is reached or the token is rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| repos | Yes | Repository names as owner/repo, e.g. ["colinhacks/zod", "fabian-hiller/valibot"]. Not URLs or npm/PyPI package names. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld, and the description adds substantial context beyond them: one GitHub API call per repo plus npm/PyPI lookups, graceful handling of nonexistent repos via notFound, and the two failure modes (none fetchable, rate limit or rejected token). This is exactly the operational detail an agent cannot get from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and result set, then usage, then cost/failure behavior. It is dense and the scoring-weight parenthetical is verbose, but nearly every clause carries information an agent needs to interpret results, so little is waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description fully compensates: it defines the 0-100 score components and weights, the tier thresholds, the New tier for <30-day repos, the verdict, and the breakdown. Nothing needed to call or interpret this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, including the owner/repo format and 2-10 bounds, so the baseline is 3. The description adds real meaning on top: downloads are only reported 'when the registry links back to the repository', and an unresolvable repo lands in notFound rather than failing the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource and scope: 'Compare 2-10 known GitHub repositories side by side'. It enumerates exactly what is compared (score/tier, stars, forks, issues, push, license, downloads, verdict), so an agent knows precisely what this returns and how it differs from recommend_repos and trending_repos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('choose between candidates you already have... zod vs valibot, or check a dependency the project already uses') and names the alternative for the opposite case ('use recommend_repos to find candidates'). No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_reposRecommend repositoriesARead-onlyInspect
Find the best open-source library for a need before adding a dependency. Give the need in plain words and get up to limit GitHub repositories ranked by fit = score x relevance to the need. Each result has a 0-100 score (momentum 40% (stars gained per week; without history, lifetime stars per week scaled by the npm/PyPI download trend), maintenance 25%, adoption incl. npm/PyPI weekly downloads 25%, license 10%), a tier (Strong >=75, Solid >=50, Watch >=25, Avoid <25; New for repos under 30 days old, too new to judge), a one-line verdict and the full breakdown. Use this when you do not yet have candidates; use compare_repos when you already have names. Makes 3 GitHub searches plus npm/PyPI lookups for the shortlist. Without a GitHub token GitHub allows about 10 searches per minute; when the limit is hit the tool returns an error saying when it resets.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | The need in plain words, e.g. "python pdf parser", "react state management". Name the task, not a library. | |
| limit | No | How many repositories to return, 1-10. | |
| language | No | GitHub language name, e.g. "TypeScript", "Python", "Rust", "C++". JavaScript also matches TypeScript repositories and the reverse; Python also matches Jupyter Notebook. Omit to search all languages. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnlyHint/openWorldHint annotations by disclosing the scoring weights (momentum 40%, maintenance 25%, adoption 25%, license 10%), tier thresholds, the 'New' special case, that it issues 3 GitHub searches plus npm/PyPI lookups, the ~10 searches/minute unauthenticated rate limit, and that a limit hit returns an error stating the reset time. This is exactly the operational context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then usage routing, then mechanics and limits—a sensible order. The scoring/tier detail is dense for a single paragraph, but each clause carries information an agent needs to interpret results, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of describing returns and does so thoroughly: score range, weighted breakdown, tier bands, one-line verdict, and the New classification. Combined with the rate-limit and routing guidance, an agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100% with per-field descriptions and examples, so the baseline is 3. The description adds meaning beyond the schema by tying `limit` to the ranking mechanism ('up to `limit` ... ranked by fit = score x relevance'), clarifying that results are fit-ordered rather than arbitrary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (find/rank open-source repositories for a described need) with the intent spelled out ('before adding a dependency'). It explicitly distinguishes itself from the sibling compare_repos by candidate state, so an agent can separate the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit routing rule: 'Use this when you do not yet have candidates; use compare_repos when you already have names.' The schema's example needs ('python pdf parser') further reinforce when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_reposTrending repositoriesARead-onlyInspect
Discover projects: the most-starred GitHub repositories created in the last day, week or month, or with period "rising" repositories of any age that gained the most stars this week (like GitHub Trending; risingRank keeps that order). Optionally one language; each scored and returned sorted by score (starsRank keeps the stars order). Each result has a 0-100 score (momentum 40% (stars gained per week; without history, lifetime stars per week scaled by the npm/PyPI download trend), maintenance 25%, adoption incl. npm/PyPI weekly downloads 25%, license 10%), a tier (Strong >=75, Solid >=50, Watch >=25, Avoid <25; New for repos under 30 days old, too new to judge), a one-line verdict and the full breakdown. Not the right tool for picking a dependency, since new repositories have little maintenance history; use recommend_repos for that. One GitHub search (rising: one download of the daily list from raw.githubusercontent.com instead), plus one npm/PyPI lookup per repository when withDownloads is true. Without a GitHub token GitHub allows about 10 searches per minute; when the limit is hit the tool returns an error saying when it resets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many repositories to return, 1-100. | |
| period | No | "day", "week" or "month": repos created in the last 24 hours, 7 days or 30 days. "rising": repos of any age by stars gained this week (the top 1,000 repos per language plus new ones are tracked). | week |
| language | No | GitHub language name, e.g. "TypeScript", "Python", "Rust". Matches that language only. Omit for all languages. | |
| withDownloads | No | Also look up npm/PyPI weekly downloads for each repository. Slower: one registry lookup per repository. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and openWorldHint, and the description goes well beyond them: it discloses the scoring formula and weights, tier thresholds, the exact number of network calls (one GitHub search or one raw.githubusercontent fetch, plus one npm/PyPI lookup per repo when withDownloads is true), and the ~10 searches/minute unauthenticated rate limit plus the error-on-reset behavior. No contradictions. It stops short of describing result ordering guarantees beyond rank field names or pagination, which keeps it just below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, which is good, but the single paragraph is dense with nested parentheticals (the 40/25/25/10 weighting, tier cutoffs, downloads caveat, rate-limit aside) that can be hard to parse. Every clause carries information, but the packing reduces scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value information — and it does, describing the 0-100 score, its component breakdown, the tier labels and thresholds, and the one-line verdict. Combined with the usage exclusion and rate-limit disclosure, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantic meaning: 'rising' is defined as repos of any age by stars gained this week (tracking top 1,000 per language plus new ones), and it explains that risingRank vs starsRank preserves the respective order. That is ordering/behavior context the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Discover projects: the most-starred GitHub repositories...') and immediately scopes the two selection modes (recency vs rising). It explicitly names the sibling it is not (recommend_repos), so an agent can separate it from alternatives without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States an explicit exclusion with the condition that selects the alternative: 'Not the right tool for picking a dependency, since new repositories have little maintenance history; use recommend_repos for that.' It also clarifies when to use 'rising' vs 'day/week/month', which is genuine when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.2.3- Changed
compare_repos1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
recommend_repos1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
trending_repos1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
3 tool updates
v0.1.2- Changed
compare_repos1 field changed- changed
Input schema / properties / repos / descriptionPrevious value: -"Repository names in the form owner/repo."New value: +"Repository names as owner/repo, e.g. [\"colinhacks/zod\", \"fabian-hiller/valibot\"]. Not URLs or npm/PyPI package names."
- Changed
recommend_repos3 fields changed- changed
Input schema / properties / language / descriptionPrevious value: -"GitHub language name, e.g. \"TypeScript\", \"Python\", \"C++\"."New value: +"GitHub language name, e.g. \"TypeScript\", \"Python\", \"Rust\", \"C++\". JavaScript also matches TypeScript repositories and the reverse; Python also matches Jupyter Notebook. Omit to search all languages." - changed
Input schema / properties / limit / descriptionPrevious value: -"How many recommendations to return."New value: +"How many repositories to return, 1-10." - changed
Input schema / properties / need / descriptionPrevious value: -"What you need, in a few words."New value: +"The need in plain words, e.g. \"python pdf parser\", \"react state management\". Name the task, not a library."
- Changed
trending_repos5 fields changed- changed
Input schema / properties / language / descriptionPrevious value: -"GitHub language name, e.g. \"TypeScript\", \"Python\", \"C++\"."New value: +"GitHub language name, e.g. \"TypeScript\", \"Python\", \"Rust\". Matches that language only. Omit for all languages." - added
Input schema / properties / limit / descriptionAdded value: +"How many repositories to return, 1-100." - added
Input schema / properties / period / descriptionAdded value: +"\"day\", \"week\" or \"month\": repos created in the last 24 hours, 7 days or 30 days. \"rising\": repos of any age by stars gained this week (the top 1,000 repos per language plus new ones are tracked)." - changed
Input schema / properties / period / enumPrevious value: -[ - "day", - "week", - "month" -]New value: +[ + "day", + "week", + "month", + "rising" +] - added
Input schema / properties / withDownloads / descriptionAdded value: +"Also look up npm/PyPI weekly downloads for each repository. Slower: one registry lookup per repository."
3 tool updates
v0.1.0- First observed
compare_repos - First observed
recommend_repos - First observed
trending_repos
TDQS
Scored across 3 tools
Each tool targets a distinct stage of the dependency-adoption workflow: recommend_repos finds candidates from a plain-language need, compare_repos evaluates known names, and trending_repos surfaces new/rising projects. The descriptions explicitly cross-reference each other ('use compare_repos when you already have names', 'not the right tool for picking a dependency'), leaving no realistic overlap.
All three names are lowercase snake_case and share the '_repos' noun suffix, which makes the set easy to scan. The only minor deviation is 'trending_repos', which uses a gerund/adjectival modifier rather than the verb_noun pattern of recommend/compare_repos.
Three tools is exactly the right scope for a narrow library-selection server: discover, compare, and browse trends. Nothing looks padded or missing at the surface level, and each tool earns its place with a distinct workflow role.
The lifecycle (find candidates -> compare shortlist -> discover new projects) is well covered, including scoring, tiers, and registry download data. The main gap is a single-repository detail lookup: compare_repos requires 2-10 repos, so an agent cannot inspect one already-chosen dependency's full breakdown through a dedicated path.
Maintenance
Related MCP Connectors
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Discover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
Finds real, maintained open-source repos that fit your project. MCP grounding for coding agents.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables natural language queries to search GitHub for trending repositories by topic, summarize project READMEs, and compare multiple repos to uncover ecosystem patterns.2-
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to perform GitHub analytics and management tasks, including repository analysis, PR summarization, issue triage, release notes generation, and contributor statistics.25 npmMIT
- FlicenseAqualityBmaintenanceEnables searching and inspecting GitHub repositories, including topic and trending searches, repo overviews, file browsing, commit history, branches, and side-by-side repo comparisons.91-
- AlicenseAqualityAmaintenanceEnables AI agents to discover and evaluate GitHub repositories from natural-language feature descriptions, returning ranked adoption-grade candidates with evidence and quality signals.32MIT