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:

…