Skip to main content
Glama
josifb

whichlib

by josifb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Recommend repositories

recommend_repos
Read-only

Find open-source library candidates before adding a dependency by describing your need in plain words and getting ranked GitHub repositories with scores and verdicts.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
needYesThe need in plain words, e.g. "python pdf parser", "react state management". Name the task, not a library.
limitNoHow many repositories to return, 1-10.
languageNoGitHub 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.

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. Changed3 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\", \"C++\". JavaScript also matches TypeScript repositories and the reverse; Python also matches Jupyter Notebook. Omit to search all languages."
    • changedInput schema / properties / limit / description
      Previous value: -"How many recommendations to return."New value: +"How many repositories to return, 1-10."
    • changedInput schema / properties / need / description
      Previous 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."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools