reposniffer-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | GitHub token to raise search rate limits (authenticated = 30 req/min vs ~10). | |
| REPOSNIFFER_EMBED_BACKEND | No | Embedding backend to use. Set to 'api' to use an OpenAI-compatible endpoint for stronger quality (requires additional endpoint configuration). | local |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_reposA | Rank open-source GitHub projects that implement a described feature. Use when an agent needs to pick a library/project to adopt or study, and wants a verifiable, adoption-grade verdict with evidence and quality signals (stars, activity, license, archived status) instead of a hallucinated guess. |
| repo_intelA | Verify an existing repo the agent already found: is it alive, licensed, and best-of-kind? Returns a status verdict plus a few alternatives. Use BEFORE committing to a dependency to catch archived/stale/no-license repos. |
| healthA | Report embedding backend, model, and GitHub auth status. |
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
find_repos is clearly for discovering projects by feature, repo_intel is clearly for validating an already-known repo, and health is an operational diagnostic. The purposes are distinct and the descriptions reinforce the boundaries.
The names are readable and unambiguous, but they do not follow a single pattern: find_repos uses verb_noun, while repo_intel and health are noun-style labels. There is no chaotic mixing of casing, but the conventions are inconsistent.
Three tools is an appropriate size for a focused repo-intelligence server. Each tool has a clear role: discovery, verification, and service health, so none feels redundant or extraneous.
The core workflow is covered: discover candidate repos, validate them for adoption, and check service health. A minor gap is the lack of a dedicated detailed-comparison tool, but the combination of verdicts and alternatives in repo_intel makes the surface functional.