skyzhao1223/wheel-hub
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | GitHub token to raise the API rate limit from 60 to 5,000 requests/hour. Optional but strongly recommended for real use; always pass it explicitly through the client's env config. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_ossA | Search GitHub for high-quality open-source solutions before implementing a feature. Returns ranked candidates with stars and descriptions. |
| evaluate_repoA | Score a single GitHub repository (0-100) on popularity, momentum, maintenance and trust, with an adopt/adapt/inspect/avoid verdict. |
| compare_alternativesA | Search for alternatives to a feature/tool and evaluate each one. Use before writing new code to avoid reinventing the wheel. Returns a ranked verdict table. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
evaluate_repo clearly targets a single known repo, but search_oss and compare_alternatives heavily overlap — both search GitHub for solutions before coding and return ranked candidates/verdicts. An agent could easily pick the wrong one since the boundary (finding a solution vs. finding alternatives to something) is subtle.
All three follow a verb_ prefix pattern (evaluate_repo, search_oss, compare_alternatives), which is predictable. Minor inconsistency in the noun suffixes (repo vs. oss vs. alternatives) keeps it from being fully uniform.
Three tools is a little thin but well-scoped for a narrow 'avoid reinventing the wheel' purpose. Each tool earns its place in the discover-then-evaluate flow.
The surface covers the core lifecycle: search for candidates, compare alternatives, and score a specific repo. Minor gaps like fetching detailed repo metadata or readme content exist, but core workflows are covered.