Skip to main content
Glama
josifb

whichlib

by josifb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Compare repositories

compare_repos
Read-only

Compare 2-10 GitHub repositories side by side to get a 0-100 score, tier, stars, forks, downloads and a verdict, so you can choose between known candidates.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
reposYesRepository names as owner/repo, e.g. ["colinhacks/zod", "fabian-hiller/valibot"]. Not URLs or npm/PyPI package names.

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. Changed1 schema field changedv0.1.2
    • changedInput schema / properties / repos / description
      Previous 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."
  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?

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools