MCP server (Claude / Cursor)

The DevUpdate.io MCP server exposes your tracked sources, releases, available dependency upgrades, and open security issues as tools that any Model Context Protocol-compatible client can call. The most common uses: have your agent run a full dependency audit ("are we exposed to anything right now?"), ask "is this update safe?" and have the model check the actual diff analysis before answering, or have it work through your available upgrades and resolve the safe ones. The division of labor is deliberate: your agent brings the codebase, we bring verified dependency knowledge, and your code never reaches our servers.

There are two ways to connect:

• The hosted server (recommended): point your client at https://api.devupdate.io/mcp and sign in. No install, no config files.
• Local (stdio): run the server yourself with an API token, for air-gapped setups or if you'd rather no traffic flow through our hosted endpoint.

Both expose the same tools, on every tier including the free one: the free tier's single lockfile gets the full audit/upgrade surface; paid tiers extend it across unlimited lockfiles. The MCP-and-skills setup you commit to a repo works for every collaborator regardless of their plan.

What the server gives you #

Five tools for the model to call — kept deliberately few so a crowded MCP client (many connectors at once) doesn't ration DevUpdate's tools out of the audit path:

• list_sources: your tracked sources, with last release and risk band.
• get_updates: release intelligence across your sources — full summaries, risk scores, and breaking-change lists. Scope it with source_id (one source), query (search by term), since / min_risk (recent or high-risk only), or omit everything for "what changed lately".
• get_security_issues: the audit entry point, covering every OSV/GHSA advisory affecting a pinned version, independent of whether an upgrade exists. Includes the two cases upgrade tools structurally drop (vulnerable at the latest release; fix unreleased), a fix_status triage key (fix_available when a released fix is reachable — linking the upgrade that delivers it once ingested, fix_blocked naming the parent constraint in the way, fix_unreleased when no released fix is reachable above the pin — checked against the registry's published set, or kept conservatively when that lookup is unavailable), and the advisory's own workaround text, verbatim, when one is documented. No dismissal: unresolved issues keep listing by design.
• get_upgrades: available dependency upgrades in one call — a per-lockfile rollup (counts of upgradeable / direct vs. transitive / blocked-by-parent / major / security / high-risk / not-monitored) leads the per-package list (pinned → latest, major / security / breaking / direct / transitive / blocked flags, OSV/GHSA advisory ids with fix versions, the parent constraint behind blocked upgrades, each with its (id: N) tag), optionally filtered by lockfile, minimum risk level, or to include dismissed ones. Pass upgrade_ids instead for release-by-release detail across each upgrade's exact (pinned, latest] range — the call to make before taking a major or breaking upgrade.
• dismiss_upgrades: snooze upgrades you've decided to defer, until a newer version appears - by lockfile or specific upgrade ids.

Upgrade risk levels are priorities, most urgent first: critical means a registry advisory (OSV/GHSA, the same data npm audit / pip-audit read) affects your pinned version and its fix ships in the range, with the advisory ids included so an agent can verify; high means a confirmed breaking signal: a major jump or documented breaking changes; medium means suspicion without confirmation: undocumented changes detected via diff, security-flavored release notes with no matching advisory, an advisory whose fix is not in the range, or a release scoring 40+; low is routine catch-up. See Available upgrades for the full model, including how offered versions are validated against the package's registry and how parent-blocked upgrades are detected.

Every tool except dismiss_upgrades is read-only. The audit flow starts with get_security_issues (severity-first, fix_status decides the resolution path), then get_upgrades unfiltered — its rollup heads the list, so a filtered-empty list is never mistaken for "up to date"; pass upgrade_ids for release-by-release detail before anything major or breaking — then resolve the safe ones. After bumping a dependency you usually don't need dismiss_upgrades at all. The next sync auto-resolves the upgrade; use it only to snooze an upgrade you're deferring. The agent skills package these flows so you don't have to prompt them every time.

The hosted server (recommended) #

The hosted endpoint speaks streamable HTTP at:

https://api.devupdate.io/mcp

Authentication is standard MCP OAuth: your client discovers our authorization server automatically, opens a browser window, and you approve the connection on a consent screen, with no tokens to copy. Each connected client appears under Settings → Connected AI Clients, where you can revoke it at any time.

Prefer not to do the browser dance (CI, scripts)? The endpoint also accepts your API token directly as a bearer header: Authorization: Bearer du_….

claude.ai and Claude Desktop #

Add a custom connector (Settings → Connectors → Add custom connector) and paste https://api.devupdate.io/mcp. Claude walks you through the OAuth sign-in; the DevUpdate tools then show up in the tools menu.

Claude Code #

One command, then authenticate via /mcp:

claude mcp add --transport http devupdate https://api.devupdate.io/mcp

To share the server with everyone working in a repository, check this .mcp.json into the project root instead, where each developer authenticates once via /mcp:

{
  "mcpServers": {
    "devupdate": {
      "type": "http",
      "url": "https://api.devupdate.io/mcp"
    }
  }
}

For non-interactive use, skip OAuth and pass an API token:

claude mcp add --transport http devupdate https://api.devupdate.io/mcp \
  --header "Authorization: Bearer du_<your-token>"

Claude Code on the web #

Web sessions run in a sandboxed cloud container, but the hosted server needs nothing from the container: add DevUpdate.io as a connector in the web UI (paste the URL above, complete the OAuth sign-in) and it's available to your sessions. If you instead commit the .mcp.json above to the repo, the container itself talks to api.devupdate.io. That works too, but requires allowing api.devupdate.io in the environment's network policy. The connector route avoids the network-policy step entirely.

Cursor #

Cursor's MCP config lives at ~/.cursor/mcp.json:

{
  "mcpServers": {
    "devupdate": {
      "url": "https://api.devupdate.io/mcp"
    }
  }
}

Cursor opens the OAuth consent flow on first use.

Running the server locally (stdio) #

The same server ships as an npm package and runs over stdio with an API token from Settings → API tokens. The config shape is identical for Claude Desktop (claude_desktop_config.json), Claude Code (.mcp.json), and Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "devupdate": {
      "command": "npx",
      "args": ["-y", "@devupdate/mcp-server"],
      "env": {
        "DEVUPDATE_TOKEN": "<your-token>"
      }
    }
  }
}

In a shared repo, use "DEVUPDATE_TOKEN": "${DEVUPDATE_TOKEN}" and have each developer export the variable, so the raw token never lands in version control. Restart the client to pick up the new server.

Security model #

• OAuth connections are scoped. A connected client gets exactly two scopes, shown on the consent screen: mcp:read (your sources, release analyses, available upgrades, and security issues) and mcp:alerts:write (dismiss upgrade notices). The issued tokens cannot reach any other API surface, not settings, not billing, not account data beyond your basic profile.
• The tool surface is deliberately narrow in both modes: read your sources, releases, upgrades, and security issues, plus dismiss_upgrades. No client can upload lockfiles, add or remove sources, or touch billing.
• Everything is revocable. OAuth clients are listed under Settings → Connected AI Clients and can be disconnected individually, and their tokens stop working immediately. API tokens are revoked from the API tokens page with the same effect.
• Each tool call is logged on our side for audit, and consent grants and revocations land in your account's security audit trail.
• OAuth access tokens are short-lived (1 hour) and refreshed automatically by your client; refresh tokens rotate on every use, and a replayed refresh token revokes the whole connection as a precaution.