Find where one dependency is constrained differently across a repository's manifests.
Runs on your machine from its package; the steps are below.

Not assessed yet.
Odel charges nothing per call. The publisher may charge for its own service.
Runs locally over stdio
This server isn't hosted — your MCP client launches it from a package registry. Use one of the commands below, or drop the config into your client (e.g. Claude Desktop).
Run
npx -y versions-le-mcp
MCP client config
{
"mcpServers": {
"versions-le": {
"command": "npx",
"args": [
"-y",
"versions-le-mcp"
]
}
}
}
Find where one dependency is constrained differently across a repository's manifests — and where no version can satisfy both
package.json · Cargo.toml · pyproject.toml · go.mod · GitHub workflows
Useful? A star or rating is how other developers find it — ★ GitHub · ★ Open VSX · ★ Marketplace
The build broke because api asks for regex = "1" and web asks for regex = "2", and no one version satisfies both. Or it did not break, and will: CI has built on Rust 1.80 since March while rust-version says 1.88.
Run Versions-LE: Compare Versions and every manifest in the workspace is compared as one set — or every manifest under a folder, from the Explorer. The report opens beside the editor: each problem by severity with every file, key and constraint that produced it, then what was deliberately not compared and why. Works in VS Code and in VS Code–based editors like Cursor and VSCodium (installable from Open VSX).
serde 0.9 while the rest moved to 1.0It never edits a manifest, and never guesses: a constraint it does not model is named and left out of every comparison.
| Where | What you get | Install |
|---|---|---|
| VS Code | The comparison, in your editor, on a keystroke | Marketplace |
| Cursor, VSCodium, Windsurf | The same extension | Open VSX |
| A terminal or a CI step | A whole tree, with an exit code | cargo install versions-le · crates.io |
| Any MCP agent, via Node | compare_versions over stdio | npx versions-le-mcp · npm |
| Code | Severity | What it means |
|---|---|---|
disjoint-constraint | error | Two constraints for one dependency that no single version satisfies. The strongest claim this tool makes. |
malformed-constraint | error | Shaped like a constraint of its own ecosystem, and broken. |
constraint-conflict | warning | One dependency, two or more different requirements across sites. |
msrv-mismatch | warning | rust-version differs across manifests, or a CI toolchain pin is below the declared minimum. |
prerelease-in-production | warning | An -rc or -alpha constraint outside dev or build dependencies. |
floating-pin | info | latest, *, a caret on a 0.x version, or an unpinned CI tool version. |
Different and unsatisfiable are two findings. constraint-conflict
is a smell; disjoint-constraint is a build that cannot resolve. They
are never conflated.
Disjointness is decided by interval arithmetic over the modelled
ranges, not by string comparison — which is also why >=20 and
>=20.0.0 are not reported as a conflict. They are one requirement typed
twice.
One finding per drifted dependency, carrying every site. A dependency constrained four ways is one problem with four sites, and four findings would read as four problems.
It never guesses. A constraint in a grammar this tool does not model
is named in the report's refusals and takes part in no comparison —
never approximated into a range.
| Reason | When |
|---|---|
unknown_grammar | The value is a constraint in a syntax this tool does not model: PEP 440 ~=, !=, ===, ==1.2.*; npm workspace:, npm:, file:, link:, a git or https URL, an owner/repo shorthand, a dist tag; a Cargo dependency table with no version; a commit-SHA or branch action ref; a CI channel name (stable, latest, lts/*). |
cross_ecosystem | The same name appears under two ecosystems. Named once, with a site in each, and the two are never compared. |
ambiguous_version_string | A <tool>-version: value in a workflow that is not evidently a version — ${{ matrix.node }}, a list, a filename. No entry is created at all: there is nothing to compare and nothing was invented. |
per_job_tool_version | One CI tool installed at two versions — python-version: 3.9 in the test job, 3.12 in the publish job. A tool version belongs to the job that installs it, so the two are never compared. |
malformed-constraint is a finding, not a refusal, and the
difference is deliberate: it is the narrower verdict that the value is
shaped like a constraint of its own ecosystem and is broken. The tool
blames the manifest only when it is sure; everything else it blames on
itself. ^^1.0.0 is malformed. latest is not — it is a syntax with a
meaning this tool chose not to model.
Comparison never crosses an ecosystem. An npm semver and a Cargo
semver are unrelated packages that share a word — and a bare
"1.0.200" means exactly 1.0.200 in npm and anything below 2.0.0 in
Cargo. One bridge exists, msrv-mismatch, and it is built by naming both
keys rather than by matching a name.
| Manifest | Keys |
|---|---|
package.json | the four dependency sections, engines.*, packageManager |
Cargo.toml | dependencies, dev, build, the workspace and target variants, rust-version |
pyproject.toml | PEP 621 dependencies, optional-dependencies, requires-python |
go.mod | require (single and block form), the go directive |
.github/workflows/*.yml | uses: action refs, <tool>-version: inputs, toolchain: |
That last row is why this exists as much as the first: a CI toolchain drifting away from the floor a manifest declares is exactly the failure nobody notices until a release.
node_modules, vendor and .git are never read. .github always
is — a workflow lives in a hidden directory by definition.
--fix, no --pin, no --update.
The right version for a drifted dependency is a decision, not a
derivation.The same engine runs as an MCP server, so an agent can call it directly instead of diffing manifests by eye.
| Editor | How |
|---|---|
| VS Code 1.101+ | Nothing to install — the extension registers compare_versions with agent mode |
| Claude Code | claude mcp add versions-le -- npx -y versions-le-mcp |
| Cursor, Windsurf, anything else | point it at npx versions-le-mcp |
compare_versions(files: [{ path, content }], maxResults?)
It returns the report the editor renders, as data — findings capped at 500 by default with meta.truncated. It reads no files and makes no network requests. Published as versions-le-mcp on npm and as io.github.nolindnaidoo/versions-le in the MCP registry. It answers exactly as the Rust CLI's server does: one corpus runs against both, and a differential test feeds both thousands of generated manifest sets — broken JSON and TOML included — and compares every answer.
{
"mcpServers": {
"versions-le": {
"command": "npx",
"args": ["-y", "versions-le-mcp"]
}
}
}
Or install it once with npm install -g versions-le-mcp and point at versions-le-mcp. It needs no environment variables, no API key and no configuration of its own. To check it:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y versions-le-mcp
The same comparison runs over a tree from a terminal or a CI step: a Rust CLI in crate/, sharing one corpus with the extension — crate/fixtures/ — so the two can never read a constraint differently.
versions-le . # every manifest in the tree, as one JSON report
versions-le --ecosystem cargo . # one ecosystem
versions-le --fail-on any . # floating pins fail the build too
versions-le --strict . # an unanalysed corner exits 2
versions-le mcp # compare_versions and versions_le_check over MCP on stdio
The exit code is the product — 0 nothing above info, 1 findings, 2 the question was malformed. No manifests at all is 0: nothing can conflict with nothing.
| Command | Description |
|---|---|
Versions-LE: Compare Versions | Compare every manifest in the workspace, or under the folder picked in the Explorer |
Versions-LE: Open Settings | Open Versions-LE settings |
Versions-LE: Help & Troubleshooting | Built-in documentation |
No command is bound to a key by default. Give any of them one under Keyboard Shortcuts in the editor.
| Setting | Default | Description |
|---|---|---|
versions-le.exclude | [] | Glob patterns for manifests to leave out; node_modules, .git and vendor are always left out |
versions-le.openResultsSideBySide | true | Open the report beside the current editor |
versions-le.showPositions | true | Show the line each constraint is written on |
versions-le.copyToClipboardEnabled | false | Also copy the report to the clipboard |
versions-le.clipboardIncludesPositions | true | Include the line number in that copy |
versions-le.notificationsLevel | silent | all = every notification, important = warnings + errors, silent = errors only |
versions-le.statusBar.enabled | true | Show the status bar item |
versions-le.telemetryEnabled | false | Local-only event log (see Privacy) |
Twelve languages besides English:
German · Spanish · French · Indonesian · Italian · Japanese · Korean · Portuguese (Brazil) · Russian · Ukrainian · Vietnamese · Chinese (Simplified)
Both halves are covered — the manifest (command titles, setting names and descriptions) and everything shown while the extension runs (notifications, the status bar and the report's headings). A finding's message is the engine's English, identical to the CLI's.
telemetryEnabled setting only writes events to a local Output Channel you can inspect (Versions-LE).notificationsLevel to important or silent yourself turns it off. The counts are kept in VS Code's extension storage and nothing is sent anywhere; Rate opens the listing you installed from — the VS Code Marketplace or Open VSX — in your browser.| What | Where |
|---|---|
| What the tool is allowed to say — checks, refusals, the output contract, non-goals | crate/SPEC.md |
| How the extension is built and held together — architecture, invariants, toolchain, release | AGENTS.md |
| How the CLI is built and held together | crate/AGENTS.md |
| What changed | CHANGELOG.md · crate/CHANGELOG.md |
| The tool's page, and the other fifteen | letools.dev/tools/versions-le |
| Input | Size | Found | Time | Rate | Scan speed |
|---|---|---|---|---|---|
| 50 crates, 50 packages | 0.01 MB | 450 | 2.37 ms | 189,660/sec | 6.1 MB/s |
| 500 crates, 500 packages | 0.15 MB | 4,500 | 19.25 ms | 233,818/sec | 7.6 MB/s |
| 2,000 crates, 2,000 packages | 0.58 MB | 18,000 | 197.84 ms | 90,983/sec | 3 MB/s |
Median of 7 runs after warmup, on Apple M5 Pro, 24 GB RAM, Node 24.3.0. Inputs are generated
by scripts/benchmark.ts rather than checked in, so the sizes above are
exactly what was measured. Reproduce with bun run benchmark.
These are machine-specific and are not asserted in CI — a benchmark that gates a build only tells you how busy the runner was.
| Metric | Coverage |
|---|---|
| Statements | 87.78% |
| Branches | 80.08% |
| Functions | 95.25% |
| Lines | 91.54% |
304 test cases across 16 files, plus an integration suite that runs
in a real VS Code extension host and an end-to-end test that installs the
built .vsix into a clean profile.
Generated from a real run — coverage/coverage-summary.json and
coverage/test-results.json — by scripts/coverage-readme.js; CI fails if
this section drifts. Reproduce with bun run test:coverage, and the case
count is the one vitest prints.
Sixteen single-purpose tools for the work in front of every model. Each ships a Rust CLI and an MCP server. One page: letools.dev
Get it out
Check it
Guard it
Each stands on its own: no shared crate, no published core. Where two of them agree, it is because the same answer was right twice.
Contact — nolindnaidoo.com · GitHub · LinkedIn
Rust — pixelcoords and pixelactions are one loop: pixelcoords answers where, pixelactions acts there. Their own tools, their own voice — not part of the LE family.
MIT © nolindnaidoo