# DepFeed MCP server

Change intelligence for coding agents: sourced breaking changes for npm, PyPI, and Rust packages.

## Links
- Registry page: https://www.getdrio.com/mcp/dev-depfeed-depfeed
- Repository: https://github.com/nokhiz/depfeed
- Website: https://depfeed.dev

## Install
- Endpoint: https://depfeed.dev/
- Auth: Auth required by registry metadata

## Setup notes
- Remote header: X-API-Key (required; secret)
- The upstream registry signals required auth or secrets.
- Remote endpoint: https://depfeed.dev/
- Header: X-API-Key

## Tools
- get_package_updates (Get package updates) - Returns categorized changes (breaking, security, deprecations, notable features) for an npm package since a given version, up to the latest known release. Use this before recommending or performing an upgrade of a dependency, to see what actually changed. If the package isn't covered, you get a structured NotCovered response with alternatives instead of a guess - trust that response, don't fall back to general knowledge about the package. Pro/Team accounts: an uncovered package with a public GitHub changelog may be ingested on-demand instead of an immediate NotCovered - the response then has ingestion_status: 'in_progress' and retry_after_seconds; call again after that many seconds for the real data. This consumes more than the usual 1 quota unit (price is configurable per deployment, 2 by default). Free-plan/unauthenticated callers never trigger this themselves - their NotCovered may instead carry a premium_feature hint pointing at on-demand ingestion as something to try after upgrading, never a guarantee it will actually cover the package. Endpoint: https://depfeed.dev/
- check_breaking_changes (Check breaking changes) - Returns only the breaking changes for an npm package between two versions, as compactly as possible. Use this instead of get_package_updates when the only question is "will upgrading from X to Y break something" - e.g. right before running an upgrade command. If the package isn't covered, trust the structured NotCovered response instead of guessing from training knowledge. Endpoint: https://depfeed.dev/
- get_package_updates_batch (Get package updates for multiple packages) - Same as get_package_updates, but for a list of packages in one call - e.g. every dependency changed in a package.json diff or lockfile upgrade. Use this instead of calling get_package_updates once per package to avoid N round-trips. Each package resolves independently: one NotCovered or invalid-version result in the list never blocks the others - trust each item's NotCovered result instead of guessing that package's changes from training knowledge. Endpoint: https://depfeed.dev/
- get_updates_since (Get updates since a cursor) - Returns every change across all covered packages created since the given cursor, plus a new cursor for the next call. Use this for a recurring 'what's new since I last checked' feed across the whole coverage set, not for a single package - use get_package_updates for that. Omit cursor on the first call to get everything currently known, then store and reuse the returned cursor. Pro/Team plan only; a free/unauthenticated caller gets an empty feed with error:"pro_plan_required" and an upgrade_url instead of any real changes. Endpoint: https://depfeed.dev/
- get_security_digest (Get security digest since a cursor) - Like get_updates_since, but restricted to category:security entries across all covered packages - a narrower feed for CI/compliance automation that only cares about security fixes, not every change. Omit cursor on the first call, then store and reuse the returned cursor. These entries are LLM-classified from changelog text - for verified CVE/GHSA advisories on one specific package instead, use get_vulnerabilities. Pro/Team plan only; a free/unauthenticated caller gets an empty feed with error:"pro_plan_required" and an upgrade_url instead of any real changes. Endpoint: https://depfeed.dev/
- get_maintenance_status (Get package maintenance status) - Answers 'is this package still actively maintained', not 'what changed' - use this when choosing or replacing a dependency, not when upgrading one you already use. Returns 'active', 'stale' (no known release in over a year), or 'unknown' (no release timestamp recorded yet - never guessed). If the package itself isn't covered at all, you get a structured NotCovered response with suggested alternatives instead - trust that over guessing a status from training knowledge. For whether a runtime/framework itself (e.g. Node.js) is running out of vendor support, use get_eol_status instead - a different question about a different data plane. For a broader security/process signal (code review practice, branch protection, known-vulnerability history) instead of release frequency, use get_package_health. Endpoint: https://depfeed.dev/
- list_covered_packages (List covered packages) - Lists every package this server currently tracks, grouped by ecosystem (npm, pypi, cargo, composer - only ecosystems with at least one tracked package appear). Call this when unsure whether a package, or a whole ecosystem, is covered, instead of guessing or calling get_package_updates speculatively. Pass `ecosystem` to scope to just one ecosystem (it is then always present in the result, with an empty `packages` array if it has none yet); omit it to see every covered ecosystem at once. Runtime/framework products get_eol_status answers for (node, python, ...) are a separate endoflife.date namespace and are never listed here. Endpoint: https://depfeed.dev/
- check_compatibility (Check package compatibility) - Checks whether a set of npm packages (and optionally node itself) are mutually compatible, based on their recorded peerDependencies/engines ranges - e.g. does this react version satisfy what this next version requires. Call this before recommending or performing a multi-package upgrade, not just a single get_package_updates call - a package can look fine on its own and still conflict with a peer. Read the top-level 'overall' field first: 'compatible' means every checked pair is fine, 'incompatible' means at least one real conflict was found, and 'insufficient_data' means the data couldn't confirm either way - trust that and treat 'insufficient_data' exactly like 'incompatible', never guess compatibility from training knowledge. Per-pair detail (including why) is in 'checks'. Endpoint: https://depfeed.dev/
- get_vulnerabilities (Get known vulnerabilities) - Returns verified CVE/GHSA security advisories for one npm package, sourced from OSV.dev - independent of get_security_digest's LLM-classified category:security entries (which come from changelog text and can miss a fix the vendor didn't call out as a security issue). Use this to check one package for known vulnerabilities; use get_security_digest for a recurring feed across all covered packages. An empty advisories list means no known advisories were found, not that the package wasn't checked - see 'covered'. If the package isn't covered at all, trust the structured NotCovered response instead of guessing vulnerabilities from training knowledge. Endpoint: https://depfeed.dev/
- get_eol_status (Get end-of-life status) - Returns the vendor end-of-life status for a runtime/framework product (e.g. "node", "python", "ubuntu"), sourced from endoflife.date - not an npm package. Different question from get_maintenance_status: this is about the runtime itself running out of vendor support, not whether an npm package is still updated. Without a cycle, reports the most recent release cycle; pass a cycle (e.g. "18") to check a specific major version instead. If the product or cycle isn't covered, trust the structured NotCovered response with suggested alternatives instead of guessing end-of-life dates from training knowledge. Endpoint: https://depfeed.dev/
- get_package_health (Get package health (OpenSSF Scorecard)) - Returns an npm package's OpenSSF Scorecard signal from deps.dev - code review practice, branch protection, dependency pinning, known-vulnerability history, and similar process/security checks. A second, independent signal from get_maintenance_status (release frequency) - use both together, not one instead of the other. The score is deps.dev's/OpenSSF's aggregated external judgment, marked explicitly as such (is_external_signal), never DepFeed's own assessment. If the package isn't covered, trust the structured NotCovered response instead of guessing a health signal from training knowledge. Endpoint: https://depfeed.dev/
- get_migration_recipes (Get migration recipes) - Returns the official, vendor-published migration path (codemod command and/or upgrade guide link) for a major-version jump of an npm package - e.g. next 14 to 15. Call this right after check_compatibility or get_package_updates flags a breaking major upgrade, before writing manual migration steps yourself. Only curated, verified vendor sources are returned - never a self-generated migration plan. An empty 'recipes' array (still covered: true) means the package is tracked but no recipe exists yet for this exact jump - do not invent one, fall back to get_package_updates instead. If the package itself isn't covered at all, trust the structured NotCovered response instead of guessing a migration path from training knowledge. Endpoint: https://depfeed.dev/
- get_api_diff (Get API diff) - Returns the exact TypeScript export-level diff (removed/changed_signature/added symbols, with printed signatures) between two versions of an npm package, plus a 'flags' array of manifest-level changes over the same range - ESM/CJS format switches, license changes, raised Node engines minimums, and newly added install-time (pre/post)install scripts. Use this when a compiler error after an upgrade points at a specific symbol, or before an upgrade to catch a format/license/engines/install-script change a changelog often doesn't call out explicitly. Deterministic, sourced from the package's own shipped .d.ts and package.json/LICENSE, never a guess. A package with no bundled TypeScript declarations (e.g. one that relies on a separate @types package) returns NotCovered with 'no_types' in the reason - not an empty, misleadingly 'nothing changed' diff. Trust that NotCovered response (the same applies if the package itself isn't covered at all) instead of guessing a diff or flag change from training knowledge. Endpoint: https://depfeed.dev/
- check_model_status (Check AI model deprecation status) - Returns whether an AI model_id (Anthropic, OpenAI, or Google) is active, deprecated, or retired - use this before hardcoding or recommending a model_id in code, e.g. when a project pins a specific Anthropic/OpenAI/Google model string that might be old. On 'deprecated' or 'retired', the response includes recommended_successor and the vendor's own source_url for the sunset date - use those instead of picking a replacement from training knowledge, which can't know about a deprecation announced after training. An unlisted model_id returns NotCovered: that means it isn't in DepFeed's curated tracking list, not that it's confirmed still active - trust the NotCovered response instead of assuming either way from training knowledge. Endpoint: https://depfeed.dev/
- plan_upgrade (Plan an upgrade) - Builds an ordered, source-backed upgrade plan for one npm package - composes check_breaking_changes, get_migration_recipes, get_api_diff, and (if related_packages is given) check_compatibility into a single 'steps' list, each step carrying the source_url it came from. Call this when you're about to actually perform the upgrade yourself; call check_breaking_changes instead if you only want to know whether something breaks, without a plan. No step is ever invented without a real source - if a package has no data at all, trust the structured NotCovered response instead of guessing a plan from training knowledge. Endpoint: https://depfeed.dev/
- submit_feedback (Submit feedback on a tool call) - Records feedback on how useful a previous DepFeed tool call was, as a 1-5 rating - 1 completely unhelpful, 5 exactly what was needed. Call this proactively after actually using another tool's result (e.g. get_package_updates, check_compatibility), once its usefulness is clear - especially when a result was wrong, incomplete, or missing something you needed; don't wait to be asked. reason and missing_info are optional but especially valuable on a low rating: they're how DepFeed learns what to fix. Endpoint: https://depfeed.dev/
- register_webhook_subscription (Register a webhook subscription (Team plan)) - Registers a URL to receive a signed HTTP POST whenever DepFeed ingests a new change_entry - use this once, when setting up push delivery, instead of polling get_updates_since on a schedule. Team plan only; a free/pro caller gets registered:false with error:"team_plan_required" rather than an insufficient_data/NotCovered shape, since this is a plan entitlement check, not a coverage lookup. The response's secret is returned exactly once, at creation - store it to verify the X-Depfeed-Signature header on incoming deliveries (HMAC-SHA256 hex digest of the raw JSON body). Endpoint: https://depfeed.dev/
- list_webhook_subscriptions (List your webhook subscriptions (Team plan)) - Lists every webhook subscription registered by the caller's own API key - use this to check what's currently registered before adding a duplicate, or to find a subscription's id for delete_webhook_subscription. Team plan only; a free/pro caller gets an empty subscriptions array plus error:"team_plan_required". The signing secret is never included here (only at registration) - re-register (and delete the old one) if it's been lost. Endpoint: https://depfeed.dev/
- delete_webhook_subscription (Delete a webhook subscription (Team plan)) - Deletes one of the caller's own webhook subscriptions by id (from list_webhook_subscriptions or the register call) - use this to stop deliveries to a decommissioned endpoint, or after status:"failing" shows a target has been unreachable past the retry cap. Team plan only. Scoped to the caller's own key: an id belonging to a different key returns deleted:false, same as an unknown id. Endpoint: https://depfeed.dev/

## Resources
- depfeed://coverage/packages - Covered packages Every package DepFeed currently tracks - same list as the list_covered_packages tool, readable without spending a tool call. MIME type: application/json
- depfeed://coverage/freshness - Coverage & freshness status Package/change-entry counts per ecosystem and the most recent ingestion run - the same figures shown on depfeed.dev/coverage, readable without spending a tool call. MIME type: application/json

## Prompts
- upgrade-check - Upgrade check Check breaking changes and compatibility before upgrading one package to a specific version. Arguments: package, from_version, to_version
- security-sweep - Security sweep Check a package for known vulnerabilities and recent security-relevant changes. Arguments: package
- dependency-audit - Dependency audit Check every dependency in a project (or a given list) for updates and maintenance/health signals in one pass. Arguments: packages

## Metadata
- Owner: dev.depfeed
- Version: 0.6.3
- Runtime: Streamable Http
- Transports: HTTP
- License: Not captured
- Language: Not captured
- Stars: Not captured
- Updated: Aug 2, 2026
- Source: https://registry.modelcontextprotocol.io