# renovate-mcp [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/tibuntu/renovate-mcp  
**GitHub Stars:** 11  
**npm Downloads (last month):** 2011  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/renovate-mcp

## Description
An MCP server for designing Renovate configurations interactively

## Tools
Capabilities this server exposes over MCP:

- **check_setup** — Report whether the Renovate CLI and config validator are reachable, their versions, and any env overrides in effect. Pass an optional `repoPath` to also diagnose the target repo's environment: parses the `.git/config` origin remote, reads any `endpoint`/`platform` in the repo's renovate config, probes endpoint reachability (using the same `https://`-only public-host allowlist as `dry_run`), and cross-references all three with token presence — surfaces actionable hints like 'set GITHUB_TOKEN before running dry_run'. The probe sends no credentials. Call this first when other tools fail with a spawn error or unexpected validation output.
- **read_config** — Locate and parse the Renovate configuration in a repository. Searches for renovate.json, renovate.json5, .renovaterc(.json|.json5), .github/renovate.json, .gitlab/renovate.json, and the 'renovate' field of package.json — in that priority order.
- **resolve_config** — Expand every preset referenced by `extends` and return the fully resolved config. Built-in presets resolve offline against the committed catalogue. Pass `externalPresets: true` to fetch `github>` and `gitlab>` presets over HTTPS (with optional `RENOVATE_TOKEN` — or `GITHUB_TOKEN` / `GITLAB_TOKEN` as platform-specific fallbacks — for private repos). For GitHub Enterprise or self-hosted GitLab, pass `endpoint` (API base URL, e.g. `https://ghe.example.com/api/v3` or `https://gitlab.example.com/api/v4`); pass `platform` in addition to route `local>` presets through the same endpoint. `bitbucket>`, `gitea>`, and npm presets are structurally unsupported and remain in `presetsUnresolved` regardless. Endpoint and platform are **tool inputs only** — env vars like `RENOVATE_ENDPOINT` are not read, since the MCP server runs under Claude rather than in your shell. Pass either `repoPath` (reads the repo's config) or `configContent` (an inline config object). The response includes `mergeQuality` (`"faithful"` — presets are merged with Renovate's own mergeChildConfig in a worker thread; `"preview"` only if that worker was unavailable and a simplified in-process merge was used) plus a `disclaimer` and a `warnings` array. Handlebars expressions other than `{{argN}}` are left verbatim; run `dry_run` for full config resolution.
- **explain_config** — Inverse of resolve_config: walk the same preset tree, but annotate every leaf field with the chain of presets that touched it. Each leaf in `explanation` carries `{ value, setBy }` where `setBy` lists every contribution in merge order — last entry wins for scalars and overwritten (non-mergeable) arrays; for mergeable arrays each entry adds its own slice. The `<own>` source means the value came from the user's input config (siblings of `extends`); other sources are preset references as written in `extends`. Use this to trace surprises like "why is `prCreation` set to 'not-pending'?". Pure analysis: same offline-by-default behaviour as resolve_config, plus the same `externalPresets` / `endpoint` / `platform` opt-ins. Pass `repoPath` (reads the repo's config) or `configContent` (an inline config). For full-fidelity output, run dry_run instead.
- **resolve_config_diff** — Compute a structural diff between two *fully-resolved* Renovate configs — the `before` and `after` of a config refactor — entirely offline. This is the resolve-level counterpart to `dry_run_diff`: where `dry_run_diff` shows how the *proposed PRs* change (and collapses to a vacuous 0-vs-0 when the environment can't reach registries), this answers "does the new config produce the same effective settings as the old one, modulo the intended changes?". Each side accepts `repoPath` (locates the repo's config) OR `configContent` (an inline config object); both sides are resolved with `resolve_config`'s preset expansion + faithful merge. Non-array top-level keys are deep-compared and reported with before/after values; array-valued top-level keys (`packageRules`, `customManagers`, `matchManagers`, …) get an order-insensitive set diff (members only in `before` are `removed`, only in `after` are `added` — a tweaked rule shows as one of each). Shared `externalPresets` / `endpoint` / `platform` knobs apply to both sides. Returns a structured diff (`summary`, `fieldChanges`, `arrayChanges`) plus a human-readable `text` rendering and per-side `resolution` metadata (`mergeQuality`, `presetsUnresolved`, `warnings`).
- **suggest_presets** — Search Renovate presets by intent — fast, offline, no `renovate` invocation, no network. Given a free-text goal (e.g. "automerge patch and minor updates and group my dev dependencies"), it ranks matching presets from the committed built-in catalogue and, optionally, a local presets repo you point at. When no strong match exists it also sketches an unvalidated draft config from recognized intent.

Returns:
  - `builtIn` / `local`: ranked matches `{ name, namespace, description, score, matchedOn, body? }`. Scoring is lexical (field-weighted name>namespace>description>body, with IDF rarity weighting so ubiquitous tokens like "group" don't drown specific matches) — a recall aid, not a stemmed search engine.
  - `coverage` (strong | partial | weak) + `bestScore`: how well the best existing preset covers the intent.
  - `draft` (only when coverage is not strong, unless `includeDraft:false`): `{ config, unvalidated:true, hint, facets, notes }`. `config` is a pasteable Renovate config assembled from a small curated facet taxonomy.

This tool never validates the draft (that would require the Renovate CLI). Pass `draft.config` to `validate_config`, then `lint_config`, before adopting it — and fetch `renovate://preset/{name}` for a matched preset's full expanded body.
- **preview_custom_manager** — Preview a Renovate `customManagers` entry against a local repo — fast, offline, no `renovate` invocation. Designed for iterating on a regex or JSONata customManager: shows which files match `managerFilePatterns`, what each `matchStrings` entry extracts, and what dep info the template fields produce.

Limitations vs. a real Renovate run:
  - Supports `customType: "regex"` and `customType: "jsonata"` (the latter requires `fileFormat` to be "json", "yaml", or "toml").
  - For `customType: "jsonata"`: each `matchStrings` entry is a JSONata expression that may return EITHER an array of objects OR a single object (the single object is auto-wrapped to a one-element array, mirroring Renovate's own schema). Object keys map to dep fields (`depName`, `currentValue`, `datasource`, etc.).
  - Template substitution stringifies non-string primitive values (e.g. numeric `currentValue: 1.2` becomes the string "1.2"); null/undefined and nested objects/arrays are dropped from the substitution bag. Same `{{groupName}}` template gap as regex — full Handlebars helpers are not implemented.
  - `matchStringsStrategy` other than `any` (the default) is not implemented; a warning is emitted.
  - `.gitignore` (and `.git/info/exclude`, plus nested `.gitignore`s) is honored like `git` does. `node_modules/` and `.git/` are always skipped as a safety net, even without a `.gitignore`.

Run the `dry_run` tool afterwards for full-fidelity confirmation.
- **validate_config** — Validate a Renovate configuration against the official schema using renovate-config-validator. Pass either configPath (file on disk) or configContent (inline JSON object). Returns validation output and a boolean `valid`.
- **lint_config** — Run a semantic lint pass over a Renovate config. Complements validate_config: schema validation catches structural bugs, this catches Renovate-specific footguns schema validation misses — malformed '/…/' regex patterns in fields like matchPackageNames, matchDepNames, matchSourceUrls, matchCurrentVersion, plus unknown manager names in matchManagers / excludeManagers (typos that Renovate silently ignores). Each finding includes a severity ('error' | 'warn'). Offline; does not shell out. Pass either configPath (file on disk, JSON, JSONC or JSON5) or configContent (inline object).
- **dry_run** — Run Renovate in dry-run mode to preview what it would do — no PRs opened, no git pushes. Returns a structured JSON report plus a top-level `ok` boolean (false when the CLI failed OR the report records a validation/error-level problem, even if the exit code was 0). RE2 native-module fallback noise and Renovate's `Unsupported node environment` notice are filtered out of `reportErrors` — the former flows into `warnings` (still actionable, still surfaced), the latter into a separate `environmentWarnings[]` since the run still produced a usable report.

Effective platform = `platform` input → `RENOVATE_PLATFORM` env → `local`. The `platformSource` field on the result echoes which step won; preflight errors and the env-overrides-default advisory both reference it so callers don't have to read the source to find where a surprising `gitlab`/`github` came from.

The full structured report ships inline by default. For large repos that is bigger than most MCP clients' response-content cap (≈75 KB on Claude Desktop) and the middle of the JSON is silently truncated. Pass `reportOutputPath` to redirect the structured report to a file (mode 0600), in which case `summary.report` collapses to `{ reportPath, repoCount, updateCount }` and `dry_run_diff` can pick it up via `{ reportPath: … }`. `warnings`, `problems`, `reportErrors`, and `environmentWarnings` always stay inline regardless — those are the actionable bits.

**Custom base branches.** By default Renovate evaluates the repository's default branch. Pass `baseBranches` to evaluate other branches instead — this is how you dry-run a Renovate config change that lives on a feature branch before merging it. Entries are exact branch names; regex requires `/…/` wrapping (e.g. `/^renovate\/.+/`, negate with `!/…/`) — bare `^foo` is matched literally, not as regex. `$default` expands to the default branch. With `readConfigFromBaseBranch` (default true) Renovate also reads its config FROM those branches (`useBaseBranchConfig=merge`), so the branch's edited config is what gets evaluated; set it false to scan the branches' manifests using the default branch's config. Base-branch selection only applies to remote-platform runs (`platform: 'github'`/`'gitlab'`) — it is ignored (with a warning) under `platform=local`.

**Auth — prefer env vars.** Set `RENOVATE_TOKEN` (or `GITHUB_TOKEN` / `GITLAB_TOKEN`, auto-translated to `RENOVATE_TOKEN` for the spawned Renovate CLI) on the MCP server's env via `claude_desktop_config.json` / `.mcp.json`. This matches the precedence `resolve_config` uses, so a single `GITLAB_TOKEN` in `.mcp.json` works for both tools. The `token` input is retained as an ad-hoc / testing fallback — when supplied inline it is persisted in the MCP tool transcript that the client may share, replay, or feed back into the LLM, so an advisory entry is appended to the result `warnings` array steering callers toward env-var auth. For a remote-platform run, an actionable preflight error is returned before spawning Renovate when no token can be resolved at all.

Default mode runs `--platform=local` against the filesystem at `repoPath`. If your config extends `local>…` presets, pass `platform` (`github` or `gitlab`), `endpoint` (API base URL), `token`, and `repository` to run as a real platform client that can actually fetch those presets — Renovate still runs with `--dry-run`, so no PRs are opened. If you only need `gitlab>…` / `github>…` presets resolved against a self-hosted host (not a full remote run), pass just `endpoint` (and `token` if needed) while leaving `platform` unset — both flow through to Renovate in local mode too, which is enough to redirect those preset shortcuts away from the public defaults. The tool preflight-checks for `local>` presets under `--platform=local` (in `lookup` and `full` modes) and fails fast with remediation guidance rather than spawning a Renovate run that would fail opaquely with `config-validation`. The preflight is skipped for `dryRunMode=extract` so manifest-only extraction can be attempted regardless.

Credentials for private registries (e.g. `COMPOSER_AUTH` for Packagist/Satis proxies, `NPM_TOKEN` / `.npmrc` for npm, Docker registry creds, `RENOVATE_HOST_RULES` for anything else) must be set on the MCP server process itself — via the `env` key in `claude_desktop_config.json` / `.mcp.json`, not your shell, since the MCP server runs as a child of Claude and does not inherit shell env. Alternatively, encode credentials as `hostRules` in the Renovate config, or pass them per-call via the `hostRules` input on this tool (written to a mode-0600 temp file that is cleaned up after the run; token/password values — including the platform `token` input — are scrubbed from `logTail` and `problems`). Per-call `hostRules` are appended to any the repo's own config already declares. If a lookup can't auth to a registry, Renovate often reports 0 updates without a loud error; when that happens this tool surfaces detected auth failures under `problems` in the output so callers can distinguish a genuine "no updates" from a silent registry-auth failure.
- **dry_run_diff** — Compute a semantic diff between two `dry_run` reports — the proposed updates that were added, removed, or changed. Stateless: pass both reports as inputs. Each side accepts either the inline report (raw `{ repositories }` or a full `dry_run` summary with a `report` key) or `{ reportPath: "<absolute path>" }` pointing at a file produced by `dry_run`'s `reportOutputPath`. Mix and match freely. Updates are keyed by `(manager, packageFile, depName)`, so a version bump on the same dep shows up under `changed` rather than as `removed + added`. Compared fields per identity: `newValue`, `newVersion`, `updateType`, `branchName`, `groupName`, `schedule`. Returns a structured summary object plus a compact human-readable text rendering.
- **test_package_rules** — Offline "what-if": given a hypothetical dependency context and a config, report which `packageRules` match (in order), which matcher decided each, and what each matched rule contributes. Answers "why didn't my rule match?". Rules are evaluated with Renovate's REAL matchers in a worker thread (faithful), classified against the fields you actually supplied — a matcher that needs a field you didn't pass is reported as `unevaluatable`, never silently treated as a non-match. Matchers needing post-lookup data (matchUpdateTypes, matchCurrentVersion, matchNewValue, matchCurrentAge) or the merge-confidence API (matchConfidence) are unevaluatable offline; matchJsonata is advisory. Pass either `repoPath` (reads + expands the repo's config) or `configContent` (an inline config); `externalPresets`/`endpoint`/`platform` opt into external preset expansion so `extends`-provided rules are included (same semantics as resolve_config). Deprecated matcher keys (matchPackagePatterns, …) are warned about — run migrate_config first. Run dry_run for full-fidelity confirmation.
- **annotate_dry_run** — Given a `dry_run` report and a config, attribute EACH proposed update to the `packageRules` that matched it — answering "which of my rules produced these updates?". Stateless and offline: run `dry_run` first, then pass its report here (inline `report` or `reportPath`, same shapes as `dry_run_diff`) plus a config source (`repoPath` or `configContent`). Each update is matched with Renovate's REAL matchers in a worker thread against the facts present in the report; fields the report doesn't carry (e.g. datasource, depType) are reported under each update's `unevaluatable` and aggregated in `fieldGaps` rather than silently treated as non-matches. `rulesNeverMatched` flags likely-dead rules. Deprecated matcher keys are warned about — run migrate_config first. Run dry_run for full-fidelity confirmation.
- **explain_dependency** — Answer "why was/wasn't dependency X updated?" from an existing `dry_run` report — offline, no CLI. Finds every extracted occurrence of the dependency under `packageFiles` (matched case-insensitively against `depName` and `packageName`; exact by default, `partial: true` for substring) and returns per hit its `skipReason` / `skipStage`, proposed `updates`, and `warnings`, plus a one-line `verdict` (`not found in report`, `skipped: <reason>`, `up to date`, or `N update(s) available`), remedy `hints`, and `relatedProblems` (report/repo `problems` entries mentioning the dep). Pass the report inline (`report`, raw or a full `dry_run` summary) or via `reportPath` (pair with `dry_run`'s reportOutputPath). Optionally add a config source (`repoPath` or `configContent`) to attach `matchedRules` — the packageRules that matched each hit, evaluated with Renovate's real matchers in a worker thread.
- **migrate_config** — Apply Renovate's built-in config migrations (deprecated key renames, template-variable rewrites, packageRules consolidation, host-rules unification, etc.) to a config and return the migrated result. Pass either configPath (file on disk, JSON or JSON5) or configContent (inline JSON object). Returns { isMigrated, migrated, diff }. Does not write — chain with write_config to persist. First call has higher latency than other tools (Renovate's migration library cold-loads in a worker thread).
- **write_config** — Write a Renovate config to disk. Runs renovate-config-validator first — refuses to write if validation fails unless force=true (which additionally requires confirmForce).
- **get_version** — Report the renovate-mcp server version and whether it's a released build (running from node_modules) or a local/dev build (typically launched via `command: node` against a checkout). Useful when the user asks which version is wired up.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "renovate-mcp": {
    "command": "npx",
    "args": ["-y","renovate-mcp"]
  }
}
```

## Documentation

## What renovate-mcp does

renovate-mcp provides MCP tools for designing and maintaining Renovate configuration files. It can discover configuration in a repository, including supported Renovate filenames and the `renovate` field in `package.json`, then parse and inspect the result. Preset-related tools expand `extends` entries, show which presets contributed each field, compare two resolved configurations, and search built-in or local preset catalogues from a natural-language goal.

Configuration quality checks cover both structure and Renovate-specific behavior. `validate_config` invokes the official Renovate schema validator, while `lint_config` checks issues such as malformed regular expressions, unknown manager names, and deprecated matcher keys. `migrate_config` applies Renovate's built-in migrations without writing the result. `write_config` validates before saving and supports forced writes only with explicit confirmation.

The server also helps investigate behavior. Package-rule tools show which rules match hypothetical dependency data or each update in a dry-run report. Dependency explanations identify occurrences, skip reasons, proposed updates, warnings, and possible remedies. Custom-manager previews inspect regex or JSONata managers against a local repository.

## How it works

Install the package as an MCP server and point it at a repository through tool inputs. Most analysis tools operate offline. Built-in presets are expanded from the committed catalogue; external GitHub and GitLab presets require an explicit opt-in and can use an endpoint and token. Configurations may be supplied as an inline object or read from a repository, depending on the tool.

`dry_run` launches Renovate in dry-run mode, returning a structured report without creating pull requests or pushing commits. It defaults to local filesystem analysis, but can target GitHub or GitLab with platform, endpoint, repository, and authentication inputs. Reports can be kept inline or redirected to a mode-0600 file for large repositories. The diff tools compare either resolved configurations or the proposed updates in two dry-run reports.

The server uses Renovate's own matching and merging behavior in worker threads where supported. Results identify merge quality, warnings, unresolved presets, and fields that could not be evaluated from the supplied data.

## Setup and configuration

The runtime requirements are Node.js 24.11 or newer on Linux or macOS. Windows is not supported; WSL2 can provide a Linux environment. One installation route for Claude Code is:

```bash
npm install -g renovate-mcp
claude mcp add renovate -s user -- renovate-mcp
```

No token is needed for offline operations. For remote runs and external private presets, configure `RENOVATE_TOKEN`, or use `GITHUB_TOKEN` or `GITLAB_TOKEN` as supported fallbacks, in the MCP server environment. Registry credentials such as `NPM_TOKEN`, `COMPOSER_AUTH`, or `RENOVATE_HOST_RULES` must likewise be available to the server process or supplied through Renovate configuration and tool inputs. Environment settings belong in the MCP client's server configuration rather than only in an interactive shell.

## Tools and capabilities

- Discover and parse Renovate configuration files.
- Resolve, explain, search, and compare presets.
- Validate, lint, migrate, and write configuration.
- Preview regex and JSONata custom managers locally.
- Test package-rule matching and annotate dry-run updates.
- Run Renovate safely and compare its proposed updates.
- Diagnose setup, platform selection, endpoint reachability, and token coverage.
- Access resources listing presets, options, managers, and datasources.

## Limitations and notes

Preset resolution is offline by default. `bitbucket>`, `gitea>`, and npm presets remain unresolved in the standalone resolver. Handlebars expressions beyond `{{argN}}` are not expanded there, and full-fidelity resolution should use `dry_run`.

Custom-manager preview supports regex and JSONata managers with JSON, YAML, or TOML file formats. Strategies other than `any` are not implemented, and template substitution has limited handling for values and helpers. Package-rule analysis reports fields that are unavailable or require post-lookup data as unevaluatable rather than treating them as non-matches.

Large dry-run reports may exceed an MCP client's response limit, so `reportOutputPath` is available. Base-branch selection applies to remote GitHub or GitLab runs, not local-platform runs. Inline tokens can appear in client transcripts; environment-based authentication is preferred.

_Full upstream README: https://allmcps.com/mcp/renovate-mcp/readme_