# DepFeed (remote · depfeed.dev)

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

- Trust score: 64/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

> **Recent critical change**: Authorization (2026-08-03). See the changelog below before you install this server.

## Components

- remote · `depfeed.dev`: 64/100 (this document), [markdown](https://verifymcp.io/servers/dev-depfeed-depfeed/depfeed.md), [page](https://verifymcp.io/servers/dev-depfeed-depfeed/depfeed)

## Channel facts

- Endpoint: `https://depfeed.dev/`
- Transports: `streamable-http`
- Auth: `required`
- Version: `0.6.3`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (delete_webhook_subscription).
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 81/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 3627 tokens (~172/item across 21 items; 19 tools + 2 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 3/100
  - Stability observed for 1 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http dev-depfeed-depfeed https://depfeed.dev/
```

### Codex

```toml
[mcp_servers.dev-depfeed-depfeed]
url = "https://depfeed.dev/"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "dev-depfeed-depfeed": {
      "type": "remote",
      "url": "https://depfeed.dev/",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add dev-depfeed-depfeed --url https://depfeed.dev/ --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  dev-depfeed-depfeed:
    url: "https://depfeed.dev/"
```

### Other

```json
{
  "mcpServers": {
    "dev-depfeed-depfeed": {
      "type": "http",
      "url": "https://depfeed.dev/"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 64, +41)

- [critical regression] Authorization: unverified → fail
- [security improvement] Transport: fail → pass
- [security] Tool “submit_feedback” rewrote its description, which is the text the model reads
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] Schema quality: unverified → 100
- [functional improvement] Stability: unverified → 0.03
- [functional improvement] MCP protocol: unverified → pass
- [functional] First check of Tool coverage: 100
- [functional] First check of Schema quality: fail
- [functional] First check of Schema quality: excellent
- [functional] First check of Schema quality: fail
- [functional] First check of Tool coverage: 100

### 2026-08-02 (score 23)

First indexed and scored.

## MCP tools (19)

### `get_package_updates` (~299 tokens)

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.

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `max_tokens` (integer): Soft budget for the response size; least important entries are dropped first if exceeded.
- `package` (string, required): npm package name, e.g. "next"
- `since_version` (string, required): Version the caller already has, e.g. "14.2.0". Changes strictly after this are returned.

Output parameters:

- `as_of` (string)
- `breaking` (array)
- `breaking_count` (integer)
- `covered` (boolean)
- `deprecations` (array)
- `deprecations_count` (integer)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `has_security_fix` (boolean)
- `ingestion_price_units` (integer)
- `ingestion_status` (string)
- `notable_features` (array)
- `notable_features_count` (integer)
- `overall_recommended_action` (string)
- `package` (string)
- `premium_feature` (object)
- `provider` (string): Present only when covered is false: which provider answered.
- `range_covered` (string)
- `reason` (string): Present only when covered is false: why the lookup failed.
- `retry_after_seconds` (integer)
- `security` (array)
- `security_count` (integer)
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.
- `to_version_deprecated` (string)
- `truncated` (boolean)
- `truncated_count` (integer)

### `check_breaking_changes` (~158 tokens)

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.

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `from_version` (string, required): Version being upgraded from, e.g. "14.2.0"
- `package` (string, required): npm package name, e.g. "next"
- `to_version` (string, required): Version being upgraded to, e.g. "15.0.0"

Output parameters:

- `breaking` (array)
- `covered` (boolean)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `overall_recommended_action` (string)
- `package` (string)
- `provider` (string): Present only when covered is false: which provider answered.
- `reason` (string): Present only when covered is false: why the lookup failed.
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.

### `get_package_updates_batch` (~117 tokens)

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.

Input parameters:

- `packages` (array, required): Packages to check, e.g. derived from a package.json diff.

Output parameters:

- `blocking_packages` (array)
- `overall_recommended_action` (string)
- `results` (array)

### `get_updates_since` (~166 tokens)

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.

Input parameters:

- `category` (string): Restrict the feed to one category, e.g. 'security' for a security-only digest.
- `cursor` (string): Cursor from a previous call. Omit to get everything currently known.

Output parameters:

- `changes` (array)
- `cursor` (string)
- `error` (string)
- `upgrade_url` (string)

### `get_security_digest` (~148 tokens)

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.

Input parameters:

- `cursor` (string): Cursor from a previous call. Omit to get everything currently known.

Output parameters:

- `changes` (array)
- `cursor` (string)
- `error` (string)
- `upgrade_url` (string)

### `get_maintenance_status` (~202 tokens)

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.

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `package` (string, required): npm package name, e.g. "next"

Output parameters:

- `covered` (boolean)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `last_release_at` (string)
- `package` (string)
- `reason` (string)
- `status` (string)
- `suggested_alternatives` (array)

### `list_covered_packages` (~170 tokens)

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.

Input parameters:

- `ecosystem` (string): Limit the result to one ecosystem, e.g. "npm". Omit to list every covered ecosystem.

Output parameters:

- `ecosystems` (array)

### `check_compatibility` (~206 tokens)

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

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `packages` (array, required): Packages (and their versions) to check pairwise against each other.

Output parameters:

- `checks` (array)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `overall` (string)

### `get_vulnerabilities` (~169 tokens)

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.

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `package` (string, required): npm package name, e.g. "axios"

Output parameters:

- `advisories` (array)
- `covered` (boolean)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `package` (string)
- `provider` (string): Present only when covered is false: which provider answered.
- `reason` (string): Present only when covered is false: why the lookup failed.
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.

### `get_eol_status` (~182 tokens)

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.

Input parameters:

- `cycle` (string): A specific release cycle, e.g. "18". Omit to get the most recent cycle.
- `product` (string, required): Product/runtime name as tracked by endoflife.date, e.g. "node"

Output parameters:

- `covered` (boolean)
- `cycle` (string)
- `eol_date` (string)
- `is_eol` (boolean)
- `package` (string): Present only when covered is false, in place of product.
- `product` (string)
- `provider` (string): Present only when covered is false: which provider answered.
- `reason` (string): Present only when covered is false: why the lookup failed.
- `source_url` (string)
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.

### `get_package_health` (~155 tokens)

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.

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `package` (string, required): npm package name, e.g. "express"

Output parameters:

- `covered` (boolean)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `is_external_signal` (boolean)
- `package` (string)
- `provider` (string): Present only when covered is false: which provider answered.
- `reason` (string): Present only when covered is false: why the lookup failed.
- `scorecard_checks` (array)
- `scorecard_score` (number)
- `source_url` (string)
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.

### `get_migration_recipes` (~236 tokens)

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.

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `from_version` (string, required): The version to migrate from, e.g. "14.2.0".
- `package` (string, required): npm package name, e.g. "next"
- `to_version` (string, required): The version to migrate to, e.g. "15.0.0".

Output parameters:

- `covered` (boolean)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `package` (string)
- `provider` (string): Present only when covered is false: which provider answered.
- `reason` (string): Present only when covered is false: why the lookup failed.
- `recipes` (array)
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.

### `get_api_diff` (~320 tokens)

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.

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `from_version` (string, required): Version being upgraded from, e.g. "3.23.8"
- `max_tokens` (integer): Soft budget for the response size; least important changes are dropped first if exceeded.
- `package` (string, required): npm package name, e.g. "zod"
- `to_version` (string, required): Version being upgraded to, e.g. "4.0.5"

Output parameters:

- `changes` (array)
- `covered` (boolean)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `flags` (array)
- `package` (string)
- `provider` (string): Present only when covered is false: which provider answered.
- `reason` (string): Present only when covered is false: why the lookup failed.
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.
- `truncated` (boolean)
- `truncated_count` (integer)

### `check_model_status` (~204 tokens)

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.

Input parameters:

- `model_id` (string, required): Exact API model identifier, e.g. "claude-3-opus-20240229", "gpt-4-turbo", or "gemini-2.5-pro"

Output parameters:

- `covered` (boolean)
- `deprecated_on` (string)
- `model_id` (string)
- `package` (string): Present only when covered is false, in place of model_id.
- `provider` (string): Present only when covered is false: which provider answered.
- `reason` (string): Present only when covered is false: why the lookup failed.
- `recommended_successor` (string)
- `retirement_date` (string)
- `source_url` (string)
- `status` (string)
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.
- `vendor` (string)

### `plan_upgrade` (~228 tokens)

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.

Input parameters:

- `ecosystem` (string): Package ecosystem to look in. Defaults to "npm".
- `from_version` (string, required): Version being upgraded from, e.g. "14.2.0"
- `package` (string, required): npm package name, e.g. "next"
- `related_packages` (array): Other project packages to verify against the new version.
- `to_version` (string, required): Version being upgraded to, e.g. "15.0.0"

Output parameters:

- `api_changes_count` (integer)
- `compatibility` (object)
- `covered` (boolean)
- `ecosystem` (string): Package ecosystem this result is from. Absent means "npm".
- `from_version` (string)
- `overall_recommended_action` (string)
- `package` (string)
- `provider` (string): Present only when covered is false: which provider answered.
- `reason` (string): Present only when covered is false: why the lookup failed.
- `steps` (array)
- `suggested_alternatives` (array): Present only when covered is false: packages/products to try instead.
- `to_version` (string)

### `submit_feedback` (~213 tokens)

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.

Input parameters:

- `missing_info` (string): Information that was needed but the tool didn't return
- `package` (string): npm package the feedback relates to, if applicable
- `rating` (integer, required): 1 (unhelpful) to 5 (exactly what was needed)
- `reason` (string): Why this rating - what worked or didn't
- `tool_name` (string, required): Name of the DepFeed tool this feedback is about, e.g. "get_package_updates"

Output parameters:

- `recorded` (boolean)

### `register_webhook_subscription` (~182 tokens)

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

Input parameters:

- `package` (string): Limit to one npm package, e.g. "next" - omit for every package
- `target_url` (string, required): HTTPS endpoint to receive deliveries, e.g. "https://example.com/hooks/depfeed"

Output parameters:

- `error` (string)
- `id` (integer)
- `package` (string)
- `registered` (boolean)
- `secret` (string): Only ever returned here, at creation - store it now.
- `target_url` (string)

### `list_webhook_subscriptions` (~96 tokens)

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.

Output parameters:

- `error` (string)
- `subscriptions` (array)

### `delete_webhook_subscription` (~108 tokens)

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.

Input parameters:

- `id` (integer, required): Subscription id, e.g. 42

Output parameters:

- `deleted` (boolean)
- `error` (string)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/dev-depfeed-depfeed/depfeed#diagnostics

## Score history

- 2026-08-03: 64
- 2026-08-02: 23

## Links

- Remote endpoint: https://depfeed.dev/
- Authorisation metadata: https://depfeed.dev/.well-known/oauth-protected-resource
- Repository: https://github.com/nokhiz/depfeed
- Website: https://depfeed.dev/
- Changelog RSS feed: https://verifymcp.io/servers/dev-depfeed-depfeed/depfeed/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/dev-depfeed-depfeed/depfeed/changelog.json
- HTML version of this page: https://verifymcp.io/servers/dev-depfeed-depfeed/depfeed