Find open-source GitHub issues to contribute to, matched to your skills; you approve every PR.
Scored across 11 tools
Most tools are distinct (find_issues vs claim_issue vs release_issue vs submit_patch), but the three proof tools — start_proof, finish_proof, submit_proof — have overlapping boundaries that are hard to tell apart from their descriptions alone (both finish_proof and submit_proof talk about handing back captured material and uploads). submit_lesson also overlaps conceptually with submit_patch for Learn claims. An agent can recover the order from the descriptions, but misselection between the proof tools is plausible.
Consistent snake_case with a verb_noun pattern throughout (claim_issue, find_issues, release_issue, start_proof, submit_patch, report_readiness). The only deviations are the query-style my_contributions, which reads as a noun phrase rather than a verb, and the proof lifecycle verbs (start/finish/submit) where the verbs overlap semantically. Minor but real deviation from the otherwise uniform pattern.
11 tools is a well-scoped size for a contribution-workflow server, and each tool maps to a recognizable stage (discover, claim, readiness, patch, follow-up, proof, lesson, release). The proof lifecycle alone consumes three slots, which feels slightly heavy relative to its importance. Overall reasonable, not bloated.
The contribution lifecycle is essentially covered end to end: finding issues, claiming and releasing them, reporting build readiness, submitting patches, starting follow-ups, and proving behavior, plus status via my_contributions. Minor gaps exist — no explicit way to abandon/withdraw a submitted patch or check upload/check state except indirectly through finish/submit_proof and my_contributions. No severe dead ends.
Claims a pool issue (by issueId or its GitHub URL) after checking it is still free on GitHub, and answers its brief. The claim lasts 24 hours from your last call naming it, 7 days at most. Submit a patch that passes the checks within 48 hours of the claim (or the follow-up's start), of a send-back or of your last passing submission, or it lapses. Calling it again on a held issue renews the claim and answers the brief again. Every other call past your attempts and open pull requests at a time counts as a new claim, refused ones included: 10 a day per account (fewer while it is on smaller limits), shared with your hosted runs. A repository may take claims only from GitHub accounts of a minimum age or GitRanks developers of a minimum tier: below that bar (or not known yet), the claim is refused as repo_excluded (reason contributor_bar), in words that say what the repository asks. A repository's own rules can refuse one issue the same way: repo_no_gfi (it keeps its good first issues for people), repo_coordinate_first (it wants a maintainer's go on the issue before a pull request, and there is none yet), repo_issue_gate (a workflow of the repository closes pull requests on issues not assigned to their author, or without its approval label). Some repositories count pull requests on GitHub: first_timers (it takes AI-assisted pull requests only from people with a merged pull request there, and you have none) and repo_open_cap (you have as many open pull requests there as it takes from one person, or GitRanks has as many open there as its maintainers allow); while your pull requests there are not read yet, both refuse, in words that say so.
Inputs: url, mode, issueId.
Open-source issues recommended for this contributor, best first, filtered by the input. Each says whether it can be claimed now. Issues are left out when their repository would refuse this contributor's claim, or its rules hold the issue back from an AI-assisted pull request for now, such as good first issues kept for human newcomers. Without a token it answers the day's example issues, the same for everyone.
Inputs: mode, repo, after, first, +4 more.
Once every screenshot is uploaded: GitRanks checks them (type, size, metadata stripped) and the contributor sees the proof in a minute. Answers missing with the slots still to upload.
Inputs: proofId (required).
Your claims at work (with their lease and any change the contributor asked for), the ones waiting on their review, and your pull requests with their state and follow-ups. followUpRecommended marks a pull request with feedback or failing checks waiting. Renews the lease of every claim it lists.
Inputs: first, state.
Gives a claimed issue back, with why; you are not offered it again. Use taken when someone else already works on it (assigned, a comment claiming it, their pull request), closed when it is closed on GitHub, already_fixed when the default branch has the fix, maintainer_rejected when a maintainer turned this change or its approach down (a closed pull request, a comment, a beginner label taken off), stale when the issue is outdated (the code it describes has moved on): we stop offering it to anyone and check it again. The other reasons leave it open to others.
Inputs: reason (required), attemptId (required), note, forYou.
How a repository builds, tests and lints, as you found it. Kept for this contributor's later briefs alone.
Inputs: repo (required), notes, toolchain, lintCommand, +2 more.
Starts work on one of your open pull requests (reviews, comments, checks), and answers its brief with the fork and branch to commit on. For a pull request marked followUpRecommended, or when the contributor thinks something is wrong: pass their words as reason, which the brief puts first as their instruction. Not for a pull request you opened by hand.
Inputs: prId (required), reason.
When a review bot asks one of your pull requests for real behavior proof (a run on a real setup, its logs or screenshots), holds the proof for you for 2 hours and answers its brief: what the bot asks, where to work and the rules. Call it again to renew the hold. Only the contributor can post: they check what you capture on gitranks.com.
Inputs: pr (required), agent.
GitRanks Learn (invite-only): once the patch of a Learn claim passed its checks, hands back the lesson on your fix that the claim's lessonBrief describes (4 to 6 steps of typed blocks, questions with their key). Our checks and a short review run at once: on a pass the contributor takes the lesson on gitranks.com and only then approves the pull request; on a fail the findings come back, one per line: fix the lesson and submit it again. A new patch needs a new lesson.
Inputs: lesson (required), attemptId (required).
Hands back your commits as git format-patch --stdout with your report and your brief for the contributor. Our checks run at once: when they pass, the contributor reviews and approves the pull request on gitranks.com (the answer has the link); when they fail, fix the patch and submit again. Submit a patch that passes the checks within 48 hours of the claim (or the follow-up's start), of a send-back or of your last passing submission, or it lapses. On a follow-up, an empty patch with no replies ends it as nothing to fix.
Inputs: risk (required), agent (required), patch (required), tests (required), +8 more.
Hands back what you captured: outcome proved with the section to add to the pull request body, cannot_prove with the reason and a reply drafted for the pull request, or fix_broken with what failed. With files, the answer has one upload URL per screenshot and the next step. 3 accepted submissions a day per pull request.
Inputs: outcome (required), proofId (required), summary (required), note, +4 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Hire engineers by what they shipped: find, judge and shortlist developers from public GitHub work.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Discover GitHub projects welcoming AI agent contributions. Public search and listing reads.
The open-source talent graph for humans and AI agents. Find developers.
Add one secure layer between your agents and this server.
