DepFeed

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.

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'.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Returns whether one npm package@version was published with verifiable Sigstore/SLSA provenance - a signed proof it was built from a specific commit in a specific public repo by a specific CI workflow, not just uploaded by whoever holds npm credentials. Use this right before an npm install/upgrade to check supply-chain trust for the exact version you're about to pull; distinct from get_package_health's OpenSSF Scorecard (process/practice signals) and get_vulnerabilities (known CVEs) - use all three together, a package can lack provenance and still have zero known vulnerabilities, or vice versa. npm-only for now; a non-npm ecosystem request returns NotCovered. has_provenance: false is a common, valid answer (most npm packages don't opt into provenance yet) - trust it and the structured NotCovered response instead of guessing from training knowledge.

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.

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.

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.

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.

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.

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.

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).

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.