DeepGit Repository Research
Find GitHub repositories that fit a request, with evidence beyond keyword matches.
- Source repo
- zamalali/DeepGit
- Stars
- ★ 927
- Last updated
- 2mo ago
- License
- MIT
- Primary language
- Python
- FA score
- 57/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformClaude API (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A Go engineer comparing GitHub projects for a pub/sub message broker wants a ranked fit assessment rather than a star-count list.
- Not a fit if
- Users unwilling to configure a GitHub token and LLM credentials
- Source review
- 57/100 · Major gaps
What does this agent do, and when should you use it?
DeepGit is a GitHub repository research engine available as a terminal CLI, a Python library, and an MCP server. It turns a natural-language request into search angles, topics, hard requirements, preferences, and anti-patterns, then gathers candidates through keyword and topic searches, with an optional local semantic index. Activity, license, tests, CI, and relevance signals narrow the candidates before an LLM ranks them against the request. When the result is uncertain, DeepGit reads candidate source code, tests, and manifests before reassessing the ranking. It returns Markdown reports or structured results with fit scores, explanations, and risks. Running it requires Python 3.11+, a GitHub token, and credentials for a chosen LLM provider; Docker is also documented for deploying its MCP HTTP server.
Submit a request with deepgit search, Python's search or search_structured, or MCP tools find_repositories, find_repositories_json, and deep_research. DeepGit calls GitHub GraphQL to search keyword queries and topics, and can upsert seen repositories into a local LanceDB vector index and retrieve semantic neighbors. It filters candidates using activity, health, license, tests/CI, and relevance, then asks an LLM to rank them using README information and signals while enforcing hard constraints such as language and hardware limits. If its confidence gate finds contested picks, it reads their actual source, tests, and manifests, reranks them, and has a reflection critic review the order. Results are Markdown reports or structured data; check_setup() reports the status of token, LLM credentials, and semantic-layer configuration.
- A Go engineer comparing GitHub projects for a pub/sub message broker wants a ranked fit assessment rather than a star-count list.
- A maintainer looking for a library with strict language or hardware requirements, such as a C++ JSON library that does not require a GPU.
- A developer integrating repository discovery into Python code needs structured scores, explanations, and risks.
- A Claude Desktop, Cursor, or VS Code user wants to call repository research directly from an MCP client.
- A team comparing close alternatives wants deeper checks of source code, tests, and manifests, and accepts additional model calls when needed.
How do you install or deploy this agent?
Requires Python 3.11+ and a GitHub token with public-repository read access. Clone the repository and install the recommended semantic extra; it is optional and adds LanceDB and fastembed for persistent semantic recall. Configure the GitHub token and credentials for one supported LLM provider: Groq, OpenAI, Anthropic, or Vertex AI.
How do you use this agent?
After installation, search from the CLI or call the Python API. The MCP entry point runs over stdio or streamable HTTP; the Docker image starts an HTTP MCP server on port 8080 by default. The snippets below show CLI/Python usage and an MCP client configuration.
What are this agent's strengths and limitations?
- Combines keyword queries with star-sorted topic sweeps, which the README says can surface repositories missed by keyword search.
- Treats language and hardware limits as hard constraints and also filters using activity, license, tests, and CI signals.
- Escalates to source, test, and manifest reading when picks are uncertain, enabling closer evidence-based comparisons.
- Documents CLI, Python, MCP, and Docker paths; its persistent semantic index is optional.
- First use requires both a GitHub token and LLM provider credentials; model/API charges depend on the provider used.
- Repository discovery depends on GitHub network access and LLM evaluation, so it does not fit fully offline workflows.
- Semantic recall requires the optional LanceDB and fastembed extra; without it, search is limited to keyword and topic paths.
- Hard queries may use more LLM calls, and the README's benchmark figures cover only 12 held-out queries.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| DeepGit Repository Research This agent | 57 · Major gaps | CLIFree + model costs | ★ 927 | 2mo ago | Python | — |
| GenAI Agents Comprehensive Tutorial Collection | 25 · Major gaps | Library / SDKFree + model costs | ★ 25k | 3d ago | Jupyter Notebook | OpenAI API |
| Compartment | 76 · Good | CLIFree | ★ 580 | 15d ago | Python | Codex · Claude Code |
| Generative AI with LangChain | 52 · Major gaps | Library / SDKFree + model costs | ★ 1.5k | 2mo ago | Jupyter Notebook | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The README identifies the required GitHub token, optional LLM-provider credentials, and the purposes of search, semantic indexing, and MCP tools, giving partial data-flow transparency (2). The files do not show permission scoping, credential storage, or redaction. They also do not describe confirmation before tool actions, external effects, recovery, or rollback, so those criteria score 1. The README says ranking uses README content and signals, with source reading for contested candidates, which provides some attribution basis (source_attribution 2), but no complete citation convention is shown.
The README, pyproject.toml, and requirements.txt broadly agree on Python support, core dependencies, and the optional semantic extra; the README says keyword/topic search remains available without the extra (self_consistency 2; dependency_availability 2). Dependencies have minimum versions or an upper bound, but there is no lockfile or evidence of security review, so dependency_security is 1. The static material does not show concrete error messages or recovery guidance (failure_messages 1).
The stated audience is developers, and the README covers CLI, Python library, Docker, and MCP use, with separate fast-search and deep-research tools (audience_and_scenarios 2). It describes keyword/topic search, optional semantic recall, and code reading when results are uncertain (capability_boundaries 2; trigger_precision 2). Python 3.11+, token/provider variables, and multiple deployment configurations are specified (environment_fit 2), though limits and environment-specific troubleshooting are sparse.
The README organizes installation, usage, workflow, benchmarks, and MCP configuration clearly, though it is lengthy (information_architecture 2). Setup steps, environment variables, optional dependencies, and client configuration are specific (install_notes 3). Project and entry-point names are consistent, but the Docker default and other MCP run modes are not fully reconciled in their behavioral descriptions (naming_stability 2). There are usage and benchmark commands but no FAQ (examples_and_faq 2); limitations are lightly documented (known_limitations 1). The MIT file matches the metadata (license 3). Version 4.0.0 is listed, but no changelog or clear maintenance/update commitment appears in the supplied files (versioning_changelog 1; maintenance_responsibility 1).
The product offers Markdown and structured output with repository, fit score, rationale, risks, and telemetry, supporting both readers and programmatic use (output_usability 3). Multi-angle retrieval, semantic recall, and source reading for contested cases offer a clear claimed benefit over basic GitHub search (marginal_value 2), but the README's benchmark figures are not independently corroborated by the supplied files. The README claims about two LLM calls for typical queries, a free initial filtering stage, and optional semantic dependencies show cost awareness (cost_benefit 2); full cost and resource data are absent.
The README describes retrieval, filtering, ranking, and escalation, and says results include rationale and risks, providing some traceability (claim_traceability 2), but no concrete evidence-citation format is shown. README and project configuration corroborate setup, version, entry points, and dependencies; benchmark and quality claims lack an independent source in the supplied material (cross_source_corroboration 1). The review distinguishes documented workflow/configuration from benchmark figures stated only in the README, treating the latter as claims rather than verified facts (fact_inference_separation 2).
- Using the agent requires a GitHub token and, depending on the selected model provider, provider credentials; the supplied files do not explain credential protection, data retention, or request logging.
- The benchmark results reported in the README are not corroborated by other supplied materials; this static review did not run the project or reproduce the benchmark.
FAQ
Does using DeepGit cost money?
What GitHub access does it need?
check_setup() can check the token and LLM credential configuration.Can I use it without the semantic index?
[semantic] extra is optional. Without it, keyword and topic search still work, but local vector-based semantic recall is unavailable.Does DeepGit always read candidate source code?
find_repositories reads code only when its confidence gate finds uncertainty; deep_research always reads actual code and runs a reflection review.What output formats are available?
search return Markdown reports. search_structured and find_repositories_json return programmatic results with repository details, fit scores, explanations, and risks.