Git for Me! is an MCP server that helps an AI agent find real, licensed open-source repos to reuse before writing code itself, via a three-step method: gather requirements, search three forges live, and verify every pick.
git_for_me (step 1) — Takes your need plus stack, platform, license and upkeep ("unknown" is fine); if any are missing it returns the four questions to ask first, then returns the method: split the job into parts.
git_for_me_search (step 2) — Searches up to 6 parts (id, name, topic, phrase, 1–2 keywords, optional language) live on GitHub, GitLab and Codeberg: most-starred and rising topic repos, keyword name/description matches, and GitHub README text.
git_for_me_verify (step 3) — Checks every picked repo live, drops dead ones, and returns the report to show the user with verdicts (USE, ADAPT, BUILD, WRITE) per part.
Flags risks — No license, copyleft/weak copyleft, archived, stale, little used, forks, mirrors, unchecked, and picks made from memory rather than search.
Shows everything — Also lists repos the search found but weren't picked, and tells you to search again or recall replacements when needed.
Searches Codeberg for repositories matching project parts, using most-starred topic results and keyword matches in names and descriptions; excludes archived repositories and forks.
Searches GitHub for repositories matching project parts, using most-starred topic results, rising repositories, keyword matches in names and descriptions, and README text; excludes archived repositories and forks.
Searches GitLab for repositories matching project parts, using most-starred topic results and keyword matches in names and descriptions; excludes archived repositories.
Odds are, most of what you want to build is already open source. Tell your AI agent what you're making, and it finds it: which repos to use as they are, which to adapt, and what's left for you to write. Every repo it names is real, licensed for your use or flagged, and checked live.
It searches GitHub, GitLab and Codeberg. Works with Claude Code, Codex, Copilot, Cursor, Gemini CLI, Cline, Devin, Open WebUI and any other MCP client, or as an Agent Skill.
Its companion, Where My Hug At?, does the same for Hugging Face models.
How it works: four questions · parts · the search · verdicts · the live check · flags
Related MCP server: Implementation Intelligence MCP
Add it to your agent (Claude Code here; every other option below):
claude mcp add --scope user git-for-me -- npx -y git-for-meThen ask:
Git for me: a CLI that pulls the tables out of PDF invoices into a spreadsheet.
Your agent asks the few things it can't guess, splits the job into parts, and comes back with a report like the one below, every repo in it looked up moments before. It works for anything made of code:
Git for me: typo-tolerant search for the recipes on my Next.js site. Git for me: a nightly job that backs up Postgres to S3 and tells Slack if it fails. Git for me: a browser extension that saves recipes without the life story.
Ask for "a library that reads PDFs" and you get whatever is popular: in the wrong language, under a license you can't ship, or abandoned years ago. So before anything is named, four details come first. Your agent fills in what the conversation or your codebase already says, and asks you the rest:
What it asks | What that decides | |
Stack | What will it be written in?TypeScript on Node, Python 3.12, Rust | Which repos work as libraries, and which only beside your code |
Platform | Where will it run?a web app, a CLI, a server, a phone app | What fits at all |
License | What may the result be used for?commercial, open source, personal | Which licenses are allowed |
Upkeep | How much code are you willing to own?needs to stay maintained, happy to own a fork | A maintained dependency, or a fork you keep up |
"Not sure yet" is a fine answer: the picks then cover the range.
The agent breaks the need into parts, each with an input and an output (a PDF → its tables, tables → a spreadsheet). A part not worth a dependency (glue, configuration, logic only your project has, a few lines) is marked WRITE: a dependency for ten lines is a cost, not a feature.
What an agent remembers of open source is as old as its training, and misses the long tail. So nothing is picked from memory. For every other part, the agent writes a search (a topic, the stack's language, a few keywords, the job in a few words), and it runs on three forges:
Way | What it finds | Where |
Most starred in the topic | What's proven | GitHub, GitLab, Codeberg |
Rising in the topic | New repos gaining stars, including ones newer than the agent's training | GitHub |
Names and descriptions holding each keyword | Tools that aren't tagged with the topic | GitHub, GitLab, Codeberg |
README text | The long tail, by what the README says, like a web search | GitHub |
The ways take turns in the results, so a niche tool isn't buried under whatever is most starred. Archived repos are left out everywhere, and so are forks on GitHub and Codeberg. A stack that can use more than one language (TypeScript can use JavaScript) searches them all.
Verdict | Meaning |
USE | A repo the search found does this job as it is: depend on it, or run it beside your code. |
ADAPT | One comes close: fork it or copy the part you need, license permitting. |
BUILD | Nothing it found does the job: build it, reading the closest repos first. |
WRITE | Not worth a dependency: write the code. |
The agent judges the results by what they say: description, stars, recent activity, license, language. It may add a repo it knows that the search missed, but that pick ranks after the search's, and the report marks it from memory.
Every pick is looked up on its forge, live. Any that don't exist are dropped, and the agent goes back to the search for others. The rest are flagged for what would bite later, and that report is what you see. It also lists what the search found that wasn't picked, so nothing it turned up is hidden. A BUILD part whose search found repos says to check them before building one.
Under the hood it's an MCP server with three tools: git_for_me for the
method (steps 1, 2 and 4), git_for_me_search for step 3, and
git_for_me_verify for step 5.
Flag | When |
UNCHECKED | Its forge didn't answer (down, rate-limited). The repo is kept, and asked again next time. |
ARCHIVED | Read-only: every fix is yours. |
NO_LICENSE | No license: all rights reserved, so its code may not be reused. |
OWN_TERMS | A license its forge can't identify: read it. |
UNKNOWN_LICENSE | On Codeberg, which names no licenses: it has a license file, so read it. |
COPYLEFT | GPL, AGPL and kin: shipping it with your code can bind your code to its license. |
WEAK_COPYLEFT | LGPL, MPL and kin: changes to it must be shared, but using it unchanged usually doesn't bind your code. |
STALE | No pushes in two years. |
LITTLE_USED | Under 50 stars. |
FORK | A fork: check whether the original is the better pick. |
MIRROR | A mirror: pick the original it copies. |
The prompt above, from a live run on 2026-10-14 for Python 3.12 on a laptop, closed source, kept maintained (abridged):
_Searched and checked live just now: 6 named, 0 not there and dropped._
## USE · Read the tables
**Repo: jsvine/pdfplumber**
Python · license MIT · 10.8k stars · pushed 2 months ago · found: most starred in table-extraction, name or description has tables
Also: camelot-dev/camelot
The search also found, not picked:
- pymupdf/PyMuPDF (10.9k stars): found as most starred in table-extraction
## USE · Read scanned invoices
**Repo: ocrmypdf/OCRmyPDF**
Python · license MPL-2.0 · 35.0k stars · pushed 3 days ago · found: readme text, name or description has ocr, most starred in ocr
Watch out: weak copyleft: changes to it must be shared under its license, but using it unchanged usually doesn't bind your code.
Also: PaddlePaddle/PaddleOCR
## USE · Write the spreadsheet
**Repo: jmcnamara/XlsxWriter**
Python · license BSD-2-Clause · 4.0k stars · pushed 2 months ago · found: name or description has xlsx, most starred in xlsx
Also: pyexcel/pyexcel
## WRITE · Run it from the command line
No repo: write this one.
## WRITE · Tidy the invoice tables
No repo: write this one.Three of the five parts already existed, all turned up by the search, and the agent left out PyMuPDF because its AGPL would bind closed-source code. What's left to write is the glue and the logic only these invoices have.
Needs Node 22.18 or later. USAGE.md has step-by-step setup and links for 20+ agents: Claude Code and Desktop, Codex, Copilot (CLI and VS Code), Cursor, Windsurf, Devin, Cline, Gemini CLI, Goose, OpenCode, Zed, Junie, Kiro, Amp, Warp, Continue, LM Studio, Hermes, Mistral Vibe and Open WebUI. The quick routes:
Claude Code, Codex, Copilot CLI, as a plugin: the tools, plus a skill that knows when to reach for them. One marketplace serves all three.
/plugin marketplace add bikemeardsley/git-for-me # Claude Code
/plugin install git-for-me@git-for-me
codex plugin marketplace add bikemeardsley/git-for-me # Codex
codex plugin add git-for-me@git-for-me
copilot plugin marketplace add bikemeardsley/git-for-me # Copilot CLI
copilot plugin install git-for-me@git-for-meAny other MCP client: a stdio server in the client's config. Most call the
key mcpServers (USAGE.md has the exceptions).
{ "mcpServers": { "git-for-me": { "command": "npx", "args": ["-y", "git-for-me"] } } }Antigravity CLI, as a plugin: agy plugin install https://github.com/bikemeardsley/git-for-me/tree/main/plugin
Gemini CLI, as an extension: gemini extensions install https://github.com/bikemeardsley/git-for-me
As an Agent Skill, for agents that read SKILL.md:
npx skills add bikemeardsley/git-for-me.
GITHUB_TOKEN (optional, and worth setting). Without one, GitHub allows
10 searches a minute, which covers about two parts of a job; with one, 30. A
fine-grained token
with no permissions is enough. Pass it as GITHUB_TOKEN
(how, per agent); the Claude Code plugin asks for
it and keeps it in secure storage. It goes to GitHub alone: GitLab and
Codeberg need none. Without a token, a private GitHub repo looks missing,
because GitHub answers 404 for both.
The search the agent writes for each part (a topic, a language, keywords, a
few words about the job) and the repos it picks, as GETs to api.github.com,
gitlab.com/api and codeberg.org/api, plus your token, to GitHub alone, if
you set one. The token never appears in a report. The need as you wrote it,
the method and the report stay between you and your agent.
Starting it with npx (as the MCP server, or the skill's shell fallback)
downloads the git-for-me package from the npm registry, registry.npmjs.org.
Nothing is sent there but the request for the package.
The search finds what the forges' own searches can: topics, names, descriptions, and on GitHub README text. A repo with none of those words can still be missed.
"Rising" is GitHub's alone: the topic's most starred repos created in the last half year, since GitHub has no trending API, and GitLab and Codeberg can't filter by creation date.
GitLab's keyword search runs in any language (filtered by one, it times out on common words), and its results show no language until a pick is checked.
License flags read each forge's license detection, not the license text. Codeberg detects none, so a repo there is flagged to read its license file, or as unlicensed if it has none.
Only GitHub, GitLab.com and Codeberg are searched. Self-hosted GitLab and Gitea servers aren't, and Bitbucket can't be: it has no public search.
Report a vulnerability privately through GitHub Security Advisories, not a public issue. SECURITY.md lists what it touches: GETs to the three forges, and nothing on your machine.
npm install # also builds build/, which is what npx runs
node src/server.ts # the server, straight from source
npm test # offline: the forges are mocked, and the server is driven over stdio and HTTP
npm run check # typesFrom a clone, add it to your agent with
claude mcp add --scope user git-for-me -- node /path/to/git-for-me/src/server.ts.
npm install builds JavaScript into build/ because Node won't strip types
from a package inside node_modules, which is where npx puts it.
MIT. Not affiliated with the Git project, GitHub, GitLab or Codeberg.
Step 1 of 3, before recommending any open-source repo or writing something that might already exist. If stack, platform, license or upkeep is missing, returns the questions to ask the user first: call again with the answers ("unknown" is fine). Then returns the method: split what the user wants to build into parts, search GitHub, GitLab and Codeberg for each with git_for_me_search, and decide from what it finds which parts an existing repo covers (use it as is or adapt it), which nothing covers (build it), and which are not worth a dependency (write them). Follow it.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What you want to build, in plain words: what goes in, what should come out, and what it is for | |
| stack | No | What it will be written in, such as "TypeScript on Node" or "Python 3.12" | |
| upkeep | No | How much code you are willing to own, such as "needs to stay maintained" or "happy to own a fork" | |
| license | No | What the result may be used for, such as "commercial, closed source" or "open source" | |
| platform | No | Where it will run, such as "a web app", "a CLI" or "a server" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does disclose meaningful traits: the tool may return questions rather than act, "unknown" is an acceptable answer, and it returns a method rather than performing the search itself (delegated to git_for_me_search). It stops short of describing exact output shape, but the two-phase behavior is well conveyed.
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?
Front-loaded with the sequencing cue ('Step 1 of 3'), and every clause contributes to the workflow. It is dense and slightly run-on in the middle, but there is minimal filler.
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?
No annotations or output schema exist, so the description must explain return behavior — and it does, stating it returns either questions or a method. For a 5-parameter orchestration tool this is largely complete, though the precise structure of the returned method is only sketched.
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?
Schema coverage is 100%, so all five parameters are already documented, establishing a baseline of 3. The description adds real value by explaining that the four optional fields may be omitted and that 'unknown' is a valid response, giving an agent guidance the schema alone does not provide.
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 states this is "Step 1 of 3" of a workflow that gathers requirements before recommending a repo, and that it returns intake questions or a build/search method. It distinguishes itself from siblings by naming git_for_me_search as the tool it hands off to. The specific verb ('returns the questions' / 'returns the method') is present but somewhat buried in workflow prose.
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?
Explicitly states the trigger condition ('before recommending any open-source repo or writing something that might already exist') and the fallback behavior ('If stack, platform, license or upkeep is missing, returns the questions to ask the user first: call again with the answers'). It also names the sibling to use next. Nothing about when to invoke is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step 2 of 3: searches for each part: on GitHub the topic's most starred and rising repos, names and descriptions holding each keyword, and README text; on GitLab and Codeberg the topic and the keywords. Returns what it found, with stars, license, language, last activity and how each turned up, to pick each part's verdict and candidates from. Then call git_for_me_verify.
| Name | Required | Description | Default |
|---|---|---|---|
| parts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the live search scope per platform (most starred, rising, README text on GitHub; topic/keywords on GitLab/Codeberg) and the returned fields (stars, license, language, last activity, how each turned up). It omits auth needs and rate-limit behavior, which would matter for a live multi-platform search.
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?
Front-loaded with the pipeline position, then the search behavior, then the return payload and next step. It is dense and slightly clause-heavy, but every sentence carries useful information with little waste.
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?
No output schema exists, and the description does explain the return payload (stars, license, language, last activity, match provenance). Combined with the explicit next-step routing to verify, it is close to complete, with only auth/limits and full parameter semantics left unaddressed.
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?
Top-level schema coverage is 0% for the single 'parts' parameter, though nested item fields (topic, phrase, keywords, language) are documented in the schema. The description adds the 'for each part' framing and ties the search targets to those fields, but says nothing about 'id'/'name' or the maxItems constraints, so it only partially compensates.
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?
States a specific verb (searches) and resource (repos for each part) across named platforms GitHub, GitLab and Codeberg, and specifies what is matched: topic, keywords, names/descriptions, README text. Placing itself as 'Step 2 of 3' and naming the next call (git_for_me_verify) cleanly separates it from its siblings.
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 workflow framing ('Step 2 of 3', 'Then call git_for_me_verify') gives clear context for when this tool runs in the pipeline. It does not state exclusions or when to skip it, but the sequencing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step 3 of 3: checks every picked repo live on its forge, drops the ones that are not there, flags no license, copyleft, archived, stale, little used, forks and mirrors, marks picks the search didn't turn up as from memory, shows what it found that wasn't picked, and returns the report to show the user. If nextAction is SEARCH_FIRST or RECALL_REPLACEMENTS, do what its instructions say and call again.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What you want to build, in plain words: what goes in, what should come out, and what it is for | |
| components | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it enumerates which conditions get flagged (no license, copyleft, archived, stale, little used, forks, mirrors), how from-memory picks are marked, and that unmatched finds are surfaced. It does not state read-only vs mutating nature, auth needs, or rate limits.
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?
Front-loaded with 'Step 3 of 3: checks...' and free of filler, but the core is one very long sentence piling up flag after flag, which harms parseability. The conditional guidance is a clean second sentence.
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?
There is no output schema, so the description's account of what is returned (a report for the user, flags, from-memory marks, unmatched finds) is essential and present, and the nextAction loop is covered. Given the nested components schema and multi-step workflow, it is largely complete, though parameter-level and safety detail remain thin.
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?
Schema coverage is 50%, so the schema partially documents the two parameters. The description clarifies the domain concepts ('picked repo', 'picks', 'marks picks the search didn't turn up as from memory') that map onto components/candidates, but adds no syntax or format detail for 'need' or 'components' beyond that.
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?
States a specific action—checks each picked repo live on its forge—plus the downstream effects (drops missing, flags license/archived/stale/forks) and its place as 'Step 3 of 3'. The pipeline positioning distinguishes it from git_for_me_search, though the verb 'checks' is broad rather than precise.
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 'Step 3 of 3' framing establishes ordering, and it explicitly states the conditional branch: 'If nextAction is SEARCH_FIRST or RECALL_REPLACEMENTS, do what its instructions say and call again.' No explicit when-not-to-use or named-sibling comparison, but the workflow context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
git_for_megit_for_me_searchgit_for_me_verifyScored across 3 tools
The three tools form a clear 1-2-3 sequence with distinct roles (plan, search, verify), and descriptions explicitly state the step order. However, the names are very similar and the base tool name 'git_for_me' doesn't convey its planning role, so an agent might misselect without reading descriptions.
All tools use snake_case and share the 'git_for_me' prefix, following a predictable pattern. The base tool lacks a verb suffix while the others have '_search' and '_verify', which is a minor inconsistency.
Three tools map exactly to the three-step workflow, each earning its place with a distinct function. The count is well-scoped for the server's narrow decision-support purpose.
The surface covers requirements elicitation, multi-forge search, and live verification, which is complete for helping users decide on existing repos. No obvious gaps or dead ends in the workflow.
Finds real, maintained open-source repos that fit your project. MCP grounding for coding agents.
Free enterprise-grade due diligence for your app, run by your coding agent. Then the full SDLC.
The open-source talent graph for humans and AI agents. Find developers.
Open-source licence risk checks for AI coding agents and dependency trees.
