search_reposLABSCO SUMMARY
Discovery, not archaeology.
It deliberately omits blame, PR history and version diffs — that is what git and gh are for — and spends the saved surface on the find-and-evaluate loop instead. The design choices show: seven tools rather than thirty, markdown responses rather than JSON dumps, and every response ending with a suggested next step so the agent chains rather than re-reasons. Rate limits are tracked per bucket, Search at 30 requests per minute and Core at 5,000 per hour, with automatic backoff when either runs out.
What it is
Seven read-only tools built around one workflow: find a candidate, evaluate it, then read how people actually use it. Repository search takes several phrasings in one call and ranks on literal relevance rather than raw popularity; repo browsing, file reads and symbol lookup all run against remote GitHub with no local checkout.
What you get
search_repos— discovery by topic, stars, language, recency or trending, accepting multiple query phrasings in one callsearch_packages— direct PyPI or npm lookup returning version, description, links and the GitHub repo URLrepo_tree— a remote repo's file layout with depth and glob filtersget_file— any file at any branch, tag or commitfind_symbol— goto-definition through real AST queries, so a class or function is found where it is declared rather than wherever the string appearslist_tags— tags and recent releases, the fastest is-this-maintained checksearch_code— full-text search across every public file on GitHub, withrepo:,language:,path:, boolean operators and regex
Requirements
A GitHub token — without one the unauthenticated ceiling is 60 requests per hour and you will hit it immediately. It is picked up automatically from GH_TOKEN, GITHUB_TOKEN, GITHUB_PERSONAL_ACCESS_TOKEN, or from gh auth token if the GitHub CLI is already logged in, so users of gh configure nothing. Public repo read access is enough; no scopes need selecting. Python 3.11+ and uv. The package is fossick-mcp (version 0.1.4), run over stdio with uvx fossick-mcp. MIT licensed.
Setup effort
One command — uvx fossick-mcp
USE CASES
01
Picking a library that is not just the popular one
Search with several phrasings at once and let relevance ranking surface the small, focused, actively-maintained option; check its release cadence before committing.
02
Reading a repo you just found
Walk its layout with a glob filter, open the entry point and the README, and jump to where the core type is defined — no clone.
03
Seeing how an API is used in production
Search every public file for the call pattern, filtered by language or path, then read the matching files in context.
04
Vetting a dependency before adopting it
Compare last release dates across two candidates and confirm the GitHub repo behind the package name matches what you expect.
05
Catching up past a model's training cutoff
Look for what shipped or started trending recently in an ecosystem, rather than relying on what the model already knows.
7 tools
Listed in project docs. Your client may show a different list.
search_packagesrepo_treeget_filefind_symbollist_tagssearch_codeBEFORE YOU INSTALL
What to know first
Tools you get
7 tools named in the project's documentation.
Requires
- uvx on PATH
- Python 3.11+
Optional
- GH_TOKEN in your environment
- GITHUB_TOKEN in your environment
- GITHUB_PERSONAL_ACCESS_TOKEN in your environment
INSTALLATION
Connect your client
Server setup
TERMINAL
uvx fossick-mcpMCP Clients
Claude Desktop, Claude Code, Cursor, Windsurf
JSON
{
"mcpServers": {
"fossick": {
"command": "uvx",
"args": [
"fossick-mcp"
]
}
}
}VS Code
VS CODE · TERMINAL
code --add-mcp '{"name":"fossick","command":"uvx","args":["fossick-mcp"]}'Cline
CLINE · JSON
{
"mcpServers": {
"fossick": {
"type": "stdio",
"command": "uvx",
"args": [
"fossick-mcp"
]
}
}
}Codex
CODEX · TOML
[mcp_servers.fossick]
command = "uvx"
args = ["fossick-mcp"]
