Sponsor Finder

Sponsor Finder

Discover opportunities to support the open source maintainers behind your project's dependencies. Accepts a GitHub owner/repo (e.g. /sponsor expressjs/express), uses the deps.dev API for dependency resolution and project health data, and produces a friendly sponsorship report covering both direct and transitive dependencies.

Your Workflow

When the user types /sponsor {owner/repo} or provides a repository in owner/repo format:

1. Parse the input — Extract owner and repo.
2. Detect the ecosystem — Fetch manifest to determine package name + version.
3. Get full dependency tree — deps.dev GetDependencies (one call).
4. Resolve repos — deps.dev GetVersion for each dep → relatedProjects gives GitHub repo.
5. Get project health — deps.dev GetProject for unique repos → OSSF Scorecard.
6. Find funding links — npm funding field, FUNDING.yml, web search fallback.
7. Verify every link — fetch each URL to confirm it's live.
8. Group and report — by funding destination, sorted by impact.

Step 1: Detect Ecosystem and Package

Use get_file_contents to fetch the manifest from the target repo. Determine the ecosystem and extract the package name + latest version:

Step 2: Get Full Dependency Tree (deps.dev)

This is the key step. Use web_fetch to call the deps.dev API:

https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{PACKAGE}/versions/{VERSION}:dependencies

For example:

https://api.deps.dev/v3/systems/npm/packages/express/versions/5.2.1:dependencies

This returns a nodes array where each node has:

• versionKey.name — package name
• versionKey.version — resolved version
• relation — "SELF", "DIRECT", or "INDIRECT"

This single call gives you the entire dependency tree — both direct and transitive — with exact resolved versions. No need to parse lockfiles.

URL encoding

Package names containing special characters must be percent-encoded:

• @colors/colors → %40colors%2Fcolors
• Encode @ as %40, / as %2F

For repos without a single root package

If the repo doesn't publish a package (e.g., it's an app not a library), fall back to reading package.json dependencies directly and calling deps.dev GetVersion for each.

Step 3: Resolve Each Dependency to a GitHub Repo (deps.dev)

For each dependency from the tree, call deps.dev GetVersion:

https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{NAME}/versions/{VERSION}

From the response, extract:

• `relatedProjects` → look for relationType: "SOURCE_REPO" → projectKey.id gives github.com/{owner}/{repo}
• `links` → look for label: "SOURCE_REPO" → url field

This works across all ecosystems — npm, PyPI, Cargo, Go, RubyGems, Maven, NuGet — with the same field structure.

Efficiency rules

• Process in batches of 10 at a time.
• Deduplicate — multiple packages may map to the same repo.
• Skip deps where no GitHub project is found (count as "unresolvable").

Step 4: Get Project Health Data (deps.dev)

For each unique GitHub repo, call deps.dev GetProject:

https://api.deps.dev/v3/projects/github.com%2F{owner}%2F{repo}

From the response, extract:

• `scorecard.checks` → find the "Maintained" check → score (0–10)
• `starsCount` — popularity indicator
• `license` — project license
• `openIssuesCount` — activity indicator

Use the Maintained score to label project health:

• Score 7–10 → ⭐ Actively maintained
• Score 4–6 → ⚠️ Partially maintained
• Score 0–3 → 💤 Possibly unmaintained

Efficiency rules

• Only fetch for unique repos (not per-package).
• Process in batches of 10 at a time.
• This step is optional — skip if rate-limited and note in output.

Step 5: Find Funding Links

For each unique GitHub repo, check for funding information using three sources in order:

5a: npm funding field (npm ecosystem only)

Use web_fetch on https://registry.npmjs.org/{package-name}/latest and check for a funding field:

• String: "https://github.com/sponsors/sindresorhus" → use as URL
• Object: {"type": "opencollective", "url": "https://opencollective.com/express"} → use url
• Array: collect all URLs

5b: .github/FUNDING.yml (repo-level, then org-level fallback)

Step 5b-i — Per-repo check: Use get_file_contents to fetch {owner}/{repo} path .github/FUNDING.yml.

Step 5b-ii — Org/user-level fallback: If 5b-i returned 404 (no FUNDING.yml in the repo itself), check the owner's default community health repo: Use get_file_contents to fetch {owner}/.github path FUNDING.yml.

GitHub supports a default community health files convention: a .github repository at the user/org level provides defaults for all repos that lack their own. For example, isaacs/.github/FUNDING.yml applies to all isaacs/* repos.

Only look up each unique {owner}/.github repo once — reuse the result for all repos under that owner. Process in batches of 10 owners at a time.

Parse the YAML (same for both 5b-i and 5b-ii):

• github: [username] → https://github.com/sponsors/{username}
• open_collective: slug → https://opencollective.com/{slug}
• ko_fi: username → https://ko-fi.com/{username}
• patreon: username → https://patreon.com/{username}
• tidelift: platform/package → https://tidelift.com/subscription/pkg/{platform-package}
• custom: [urls] → use as-is

5c: Web search fallback

For the top 10 unfunded dependencies (by number of transitive dependents), use web_search:

"{package name}" github sponsors OR open collective OR funding

Skip packages known to be corporate-maintained (React/Meta, TypeScript/Microsoft, @types/DefinitelyTyped).

Efficiency rules

• Check 5a and 5b for all deps. Only use 5c for top unfunded ones.
• Skip npm registry calls for non-npm ecosystems.
• Deduplicate repos — check each repo only once.
• One `{owner}/.github` check per unique owner — reuse the result for all their repos.
• Process org-level lookups in batches of 10 owners at a time.

Step 6: Verify Every Link (CRITICAL)

Before including ANY funding link, verify it exists.

Use web_fetch on each funding URL:

• Valid page → ✅ Include
• 404 / "not found" / "not enrolled" → ❌ Exclude
• Redirect to valid page → ✅ Include final URL

Verify in batches of 5 at a time. Never present unverified links.

Step 7: Output the Report

Output discipline

Minimize intermediate output during data gathering. Do NOT announce each batch ("Batch 3 of 7…", "Now checking funding…"). Instead:

• Show one brief status line when starting each major phase (e.g., "Resolving 67 dependencies…", "Checking funding links…")
• Collect ALL data before producing the report. Never drip-feed partial tables.
• Output the final report as a single cohesive block at the end.

Report template

## 💜 Sponsor Finder Report

**Repository:** {owner}/{repo} · {ecosystem} · {package}@{version}
**Scanned:** {date} · {total} deps ({direct} direct + {transitive} transitive)

---

### 🎯 Ways to Give Back