Searches GitHub repositories using the GitHub Search API based on keyword queries, providing structured repo evidence (README excerpts, metadata) for AI agents.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@repohunt Find me a rate-limiting middleware for Express"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Grounded GitHub repo discovery as an MCP server. Your AI agent expands one intent into several keyword queries; repohunt fires them at GitHub's live Search API, dedupes and ranks the hits, and returns clean structured evidence (a trimmed README excerpt plus metadata) for the agent to judge.
No embeddings. No corpus. No backend. No LLM inside the server. All the intelligence lives in the agent you're already paying for, so repohunt costs nothing to run and nothing to use beyond your own GitHub rate limit.
When you start a feature, the right first move is often "find a repo to fork, study, or avoid" rather than building from scratch. GitHub's native search is a flat keyword list with no judgment. Thankfully, GitHub already maintains the keyword index; the calling agent supplies the query variety on the way in and the ranking judgment on the way out.
While keyword search has a somewhat weak intent-recall than say semantic search, this tool narrows the gap by (a) searching README bodies, not just names and descriptions, and (b) firing 4-8 agent-expanded query variations per call.
Related MCP server: Repo Radar MCP
A token raises your search rate limit from ~10/min (unauthenticated, degraded) to 30/min. Public-repo read needs no scopes at all.
Classic token (simplest):
Note: repohunt. Expiration: your choice.
Select NO scopes. Public read needs none.
Generate and copy the ghp_... token.
Fine-grained token (most locked-down): open https://github.com/settings/personal-access-tokens/new, set Repository access to Public repositories (read-only) with no account permissions.
The token only ever lives in your MCP host config on your machine. repohunt never
sends it anywhere except api.github.com.
Claude Desktop: open Settings > Developer > Edit Config, then add:
{
"mcpServers": {
"repohunt": {
"command": "npx",
"args": ["-y", "repohunt"],
"env": { "GITHUB_TOKEN": "ghp_your_token_here" }
}
}
}Restart the host. You should see find_repos in the tool list. The same
command/args/env shape works for Cursor, Claude Code, or any MCP host.
If GITHUB_TOKEN is missing, repohunt exits immediately with a message telling you
exactly how to fix it. It never runs silently unauthenticated.
find_repos toolOne tool. Your agent calls it; you don't.
Input
Field | Type | Required | Notes |
|
| yes | Keyword search strings. The agent expands ONE intent into 4-8 varied queries (synonyms, library names, restatements). More variety = better recall. |
|
| no | GitHub language filter, e.g. |
|
| no | Drop repos below this star count. Default |
|
| no | Enriched candidates to return. Default |
Output: structured JSON. A list of candidates, each with full_name, url,
description, readme_excerpt, stars, forks, open_issues, last_pushed,
license, primary_language, and matched_queries (which of your queries surfaced
it). Plus optional notes (hints) and degraded (set when rate limits made the
results partial). It returns evidence, not a verdict. Ranking is the agent's job.
Example. You ask your agent: "find me a rate-limiting middleware for Express." The agent expands the intent and calls:
{
"queries": [
"express rate limit middleware",
"express-rate-limit",
"api throttling node",
"request throttling express",
"leaky bucket rate limiter node"
],
"max_results": 5
}repohunt returns (trimmed):
{
"candidates": [
{
"full_name": "express-rate-limit/express-rate-limit",
"url": "https://github.com/express-rate-limit/express-rate-limit",
"description": "Basic rate-limiting middleware for the Express web server",
"readme_excerpt": "# express-rate-limit\n\nBasic rate-limiting middleware for Express. Use to limit repeated requests to public APIs and endpoints such as password reset...",
"stars": 3000,
"forks": 320,
"open_issues": 4,
"last_pushed": "2026-05-20T12:00:00Z",
"license": "MIT",
"primary_language": "TypeScript",
"matched_queries": ["express rate limit middleware", "express-rate-limit", "request throttling express"]
}
]
}The agent reads the excerpts and tells you which repo to fork, study, or avoid.
queries[] -> fan-out search (in:name,description,readme, bounded concurrency)
-> pool & dedupe (record matched_queries) -> cheap pre-rank -> TRIM
-> fetch READMEs for the survivors ONLY -> denoise + excerpt
-> return structured evidence (no model call, ever)Bounded concurrency keeps GitHub's secondary rate limits happy; READMEs are fetched
only for the trimmed candidate set (never the whole pool); a rate-limited query or
README degrades to partial results with a degraded note instead of failing.
npm install
npm run build # tsc -> dist/
npm test # vitest, mocked + deterministic
npm run typecheck
# optional: live smoke test against the real GitHub API
RUN_LIVE=1 GITHUB_TOKEN=ghp_... npm testMIT. See LICENSE.
Search GitHub for repositories matching a development intent and return structured EVIDENCE (not a verdict) for you to rank.
IMPORTANT — before calling this tool you MUST expand the user's single intent into 4-8 VARIED keyword queries: synonyms, likely library/package names, and problem restatements. Do not pass one raw phrase; keyword recall depends on the variety you supply. The server fires every query against GitHub's live search (README body included), dedupes, pre-ranks, and returns the strongest candidates each with a trimmed README excerpt + metadata. You then rank them and decide fork / study / avoid.
Example — intent "rate limiting middleware for express": queries: [ "express rate limit middleware", "express-rate-limit", "api throttling node", "request throttling express", "leaky bucket rate limiter node", "ddos protection express middleware" ]
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Keyword search strings (aim for 4-8). Expand ONE user intent into several varied variations (synonyms, library names, problem restatements). More variety = better recall. | |
| language | No | Restrict to a GitHub-recognized language, e.g. 'typescript'. | |
| min_stars | No | Filter out repos below this star count. Default 0. | |
| max_results | No | How many enriched candidates to return. Default 8, hard cap 15. |
| Name | Required | Description |
|---|---|---|
| notes | No | |
| degraded | No | |
| candidates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully describes the tool's behavior: it fires multiple queries against GitHub's live search (including README body), dedupes, pre-ranks, and returns the strongest candidates with trimmed README excerpts and metadata. It also clarifies that the tool returns evidence, not a verdict, which sets accurate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear intro, an important note, and an example. Every sentence adds value, but it is slightly lengthy. However, the length is justified given the complexity of the tool's usage pattern.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple queries, pre-ranking), the absence of annotations, and the presence of an output schema, the description is complete. It covers how to generate queries, what the server does, and what the agent should do with the results, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning beyond the schema: it explains the need for 4-8 varied queries, provides an example of proper expansion, and clarifies the roles of language, min_stars, and max_results in the context of candidate selection. This enhances the agent's understanding of how to use parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches GitHub for repositories matching a development intent and returns structured evidence. The verb 'find' and resource 'repos' are specific, and it distinguishes itself well from hypothetical siblings by emphasizing the intent-based search and evidence-returning behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when and how to use the tool: expand the user's single intent into 4-8 varied keyword queries, and do not pass one raw phrase. It also explains what to do after receiving results (rank and decide). This fully clarifies usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no ambiguity; the tool's purpose is clearly distinct.
Single tool uses snake_case, consistent with common MCP naming conventions.
One tool is appropriate for a focused 'repo hunting' purpose, though a slightly broader set might be expected for a complete search experience.
The tool covers the primary domain of searching GitHub repos with keyword expansion and ranking, leaving no obvious gaps for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Finds real, maintained open-source repos that fit your project. MCP grounding for coding agents.
Agent-native search engine with live web research optimized for AI agents.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielrltan/repohunt'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
