Skip to main content
Glama
josifb

whichlib

by josifb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Trending repositories

trending_repos
Read-only

Discover GitHub repositories trending by day, week, or month, or rising repos of any age; filter by language and view scores.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many repositories to return, 1-100.
periodNo"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
languageNoGitHub language name, e.g. "TypeScript", "Python", "Rust". Matches that language only. Omit for all languages.
withDownloadsNoAlso look up npm/PyPI weekly downloads for each repository. Slower: one registry lookup per repository.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.3
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed5 schema fields changedv0.1.2
    • changedInput schema / properties / language / description
      Previous 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."
    • addedInput schema / properties / limit / description
      Added value: +"How many repositories to return, 1-100."
    • addedInput schema / properties / period / description
      Added 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)."
    • changedInput schema / properties / period / enum
      Previous value: -[
-  "day",
-  "week",
-  "month"
-]New value: +[
+  "day",
+  "week",
+  "month",
+  "rising"
+]
    • addedInput schema / properties / withDownloads / description
      Added value: +"Also look up npm/PyPI weekly downloads for each repository. Slower: one registry lookup per repository."
  3. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools