Wisco Labs: developer tools MCP Server

by wiscolabs Your server? Claim it

answering

Wisco Labs: developer tools is answering right now. Last checked 12 min ago. It exposes 9 tools.

Check PyPI and npm upgrades: known vulnerabilities, the safe version, and what each upgrade breaks.

Uptime history 6 days of history

6 days agonow

100.0%

Uptime 24h

91 of 91 checks

Tools

read from the server

499 ms

Response time

average over 24h

open, no key

Access

streamable-http

Nothing serious here today

Today is the operative word: we check Wisco Labs: developer tools every 15 minutes and re-read its code on every release. Watch it and you find out the day that stops being true.

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 12 min ago.

Claude Code Claude Desktop Codex Cursor VS Code

run in your terminal

claude mcp add developer-tools --transport http https://api.wiscolabs.dev/mcp/dev

Settings → Connectors → Add custom connector, then paste this address

https://api.wiscolabs.dev/mcp/dev

~/.codex/config.toml

[mcp_servers.developer-tools]
url = "https://api.wiscolabs.dev/mcp/dev"

.cursor/mcp.json

{
  "mcpServers": {
    "developer-tools": {
      "url": "https://api.wiscolabs.dev/mcp/dev"
    }
  }
}

.vscode/mcp.json

{
  "servers": {
    "developer-tools": {
      "type": "http",
      "url": "https://api.wiscolabs.dev/mcp/dev"
    }
  }
}

Available tools 9

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

native

native_check

Before building on Alpine, Linux ARM, Windows ARM, a Mac or Lambda, checks which npm dependencies contain native code and whether a prebuilt binary exists for the target platform. For those that would compile from source (needing a C/C++ toolchain and Python) or fail, gives the nearest newer version that ships a prebuilt for that platform, with that upgrade's risk.

node

node_check

Before moving a project to a new Node.js version (e.g. off Node 20 to 22 or 24), checks each npm dependency's declared Node support (its engines field). For each that doesn't support the target, gives the smallest newer release that does, with that upgrade's risk. Works from a package-lock.json without installing anything.

package

package_info

Latest and latest stable version, repository, release count, and where its release notes come from.

peer

peer_check

Before upgrading a core npm package (react, typescript, eslint, vite...), checks every dependency in the project that declares it as a peer dependency: does the installed version accept the new version, and if not, the smallest release that does, with that upgrade's risk. Also checks the new version's own peer requirements against what's installed. Answers the questions behind npm's ERESOLVE errors without running npm.

types

types_check

For a TypeScript project: which dependencies ship their own type declarations, which need a DefinitelyTyped @types package (and the version that matches the installed library), and which installed @types packages describe a different major version than the library.

upgrade

upgrade_check

Give it a project's dependencies: a requirements.txt or pip freeze output for Python, or a package-lock.json, package.json, or name@version lines for npm. Flags malicious packages and versions with known vulnerabilities (with the smallest safe version to move to, preferring a low-risk patch), then reports what each upgrade breaks, removes, or deprecates, ranked into remove_now / fix_now / no_fix_available / upgrade_first / safe / review / needs_care.

vulnerabilities

vulnerabilities

Is this exact version of a package affected by known security advisories? Returns each vulnerability (with CVE ids and severity), the versions that fix it, and the smallest safe upgrade.

what

what_changed

What breaks, gets removed, is deprecated, or gains a security fix when upgrading one package between two versions, with an overall upgrade risk.

wheel

wheel_check

For each pinned Python package, whether a prebuilt wheel exists for a target Python version and platform (Windows ARM, Alpine/musl, Linux ARM, macOS, a new Python version). Without one, pip builds from source, which usually fails without a compiler for packages with C extensions. For each that's missing, gives the nearest newer version that has a wheel, with that upgrade's risk.

Endpoints

URL	Transport	State	Latency	Checked
https://api.wiscolabs.dev/mcp/dev	streamable-http	answering	495 ms	12 min ago

Alternatives to Wisco Labs: developer tools

same job, measured the same way

Vigía

by coredls-vigia

What breaks between versions, vulnerabilities, compatible versions, EOL dates: npm, PyPI, Rust, PHP.

12 tools answering

Dependency Vulnerability Check (OSV)

by brunckel

Known vulnerabilities and fixed versions for npm, PyPI, Go, Maven packages from OSV.dev via Apify.

answering

Dependency check

by ladanyin

Check a package version for known vulnerabilities and Packagist release facts.

2 tools answering

UK Data: Software packages and vulnerabilities

by co-reliness

Package versions, licences and known vulnerabilities for npm, PyPI, crates, Go, Maven, NuGet

2 tools answering

Depcheck

by kaneky

Known vulnerabilities for exact package versions from OSV, with fixes. Paid per call, x402.

1 tools answering

OSV Advisories

by basitalisandhu

Query OSV.dev for known vulnerabilities by package and version, and scan lockfiles in batch.

local only

OSV Dependency Vulnerability Check

by fairquery

Check npm, PyPI, Go and Maven packages or lockfiles against OSV.dev: CVEs, CVSS, fixed versions.

answering

Package Health Check

by openkrill

Check an npm or Python package, or a package.json, for vulnerabilities and upkeep.

6 tools answering

Wisco Labs: developer tools — questions

Answers built from our own checks of this server.

What can Wisco Labs: developer tools do?

It exposes 9 tools, read directly from the server on our last check. Among them: native_check, node_check, package_info, peer_check, types_check, upgrade_check and 3 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →

Is Wisco Labs: developer tools working right now?

We send a real MCP handshake every 15 minutes. Over the last 24 hours 91 of 91 checks got a reply (100.0%), average response time 499 ms. The bar chart above shows every period we have measured.

How do I connect Wisco Labs: developer tools?

Copy the ready config from this page. We generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each in the form that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.

Does Wisco Labs: developer tools need an API key?

No. Wisco Labs: developer tools completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 9 of them are readable on this page. This is what we observed, not what the docs claim.

How fast is Wisco Labs: developer tools?

It answers our handshake in 499 ms on average, which is faster than 24% of all working MCP servers we measure. That is on the slow side — worth knowing if the tool sits inside an interactive loop. The comparison comes from our own checks across the whole registry, every 15 minutes.