# Wisco Labs: developer tools (remote · api.wiscolabs.dev)

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

- Trust score: 66/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `api.wiscolabs.dev`: 66/100 (this document), [markdown](https://verifymcp.io/servers/dev-wiscolabs-developer-tools/mcp-dev.md), [page](https://verifymcp.io/servers/dev-wiscolabs-developer-tools/mcp-dev)

## Channel facts

- Endpoint: `https://api.wiscolabs.dev/mcp/dev`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.1`

## 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-11-05.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS enforcement could not be verified: the plaintext port answered with HTTP 406, which proves neither a plaintext path nor enforcement.
  - 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**: 68/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 1444 tokens (~160/item across 9 items; 9 tools + 0 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.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 10 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Wisco Labs: developer tools MCP server?

Wisco Labs: developer tools is a hosted endpoint at https://api.wiscolabs.dev/mcp/dev, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

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

### Cursor

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

### VS Code

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

### Codex

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

### opencode

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

### OpenClaw

```bash
openclaw mcp add dev-wiscolabs-developer-tools --url 'https://api.wiscolabs.dev/mcp/dev' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  dev-wiscolabs-developer-tools:
    url: "https://api.wiscolabs.dev/mcp/dev"
```

### Netclaw

```json
{
  "McpServers": {
    "dev-wiscolabs-developer-tools": {
      "Transport": "http",
      "Url": "https://api.wiscolabs.dev/mcp/dev"
    }
  }
}
```

### Vellum

```bash
assistant mcp add dev-wiscolabs-developer-tools -t streamable-http -u 'https://api.wiscolabs.dev/mcp/dev'
```

### Other

```json
{
  "mcpServers": {
    "dev-wiscolabs-developer-tools": {
      "type": "http",
      "url": "https://api.wiscolabs.dev/mcp/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-11-05 (score 66, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-11-04 (score 65)

First indexed and scored.

## MCP tools (9)

### `vulnerabilities` (~78 tokens)

Known vulnerabilities in a package version

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.

Input parameters:

- `ecosystem` (string): Package ecosystem (OSV naming)
- `name` (string, required): Package name
- `version` (string, required): The exact version you're using

### `upgrade_check` (~199 tokens)

Check a whole project's dependencies

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.

Input parameters:

- `ecosystem` (string): PyPI or npm. A package.json or package-lock.json is recognized as npm automatically.
- `limit` (string): Max items shown per category for each package
- `requirements` (string, required): Python: requirements.txt contents, one 'package==version' per line. npm: the contents of package-lock.json (best), package.json, or one 'name@version' per line. Lines without one exact version are li…

### `what_changed` (~120 tokens)

What changed between two versions of a package

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

Input parameters:

- `ecosystem` (string): PyPI or npm
- `from` (string, required): The version you're on now
- `limit` (string): Max items shown per category
- `name` (string, required): Package name, e.g. flask (PyPI) or express or @babel/core (npm)
- `to` (string, required): The version you want to upgrade to (use latest_version from package_info if unsure)

### `peer_check` (~178 tokens)

Will my npm packages accept this upgrade? (peer dependencies)

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.

Input parameters:

- `limit` (string): Max breaking changes shown for each suggested fix
- `requirements` (string, required): The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line
- `upgrade` (string, required): The package and version to upgrade to: react@19 (newest stable 19.x), react@19.1.0 (exact), or react (latest stable)

### `wheel_check` (~247 tokens)

Will pip find prebuilt wheels for this platform?

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.

Input parameters:

- `limit` (string): Max breaking changes shown for each suggested upgrade
- `platform` (string, required): Target platform: manylinux_x86_64 or manylinux_aarch64 (glibc Linux, e.g. Debian/Ubuntu; assumes glibc 2.36, or give an exact tag like manylinux_2_28_x86_64), musllinux_x86_64 or musllinux_aarch64 (A…
- `python` (string, required): Target Python version, e.g. 3.13
- `requirements` (string, required): requirements.txt contents or pip freeze output, one 'package==version' per line

### `node_check` (~159 tokens)

Will my npm dependencies run on this Node.js version?

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.

Input parameters:

- `limit` (string): Max breaking changes shown for each suggested fix
- `node` (string, required): Target Node.js version: a major like 24 (means the latest 24.x) or an exact 22.11.0
- `requirements` (string, required): The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line

### `native_check` (~205 tokens)

Will my npm dependencies install on this platform without compiling?

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.

Input parameters:

- `limit` (string): Max breaking changes shown for each suggested fix
- `platform` (string, required): Target platform: os-cpu[-libc], e.g. linux-x64-glibc, linux-arm64-musl, darwin-arm64, win32-arm64; or alpine, alpine-arm64, linux, linux-arm64, lambda, lambda-arm64, windows, win-arm64, mac, mac-intel
- `requirements` (string, required): The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line

### `types_check` (~93 tokens)

Which npm dependencies need @types packages, and which version?

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.

Input parameters:

- `requirements` (string, required): The project's dependencies, including any @types packages: the contents of package-lock.json (best), package.json, or one 'name@version' per line

### `package_info` (~47 tokens)

Basic facts about a package

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

Input parameters:

- `ecosystem` (string): PyPI or npm
- `name` (string, required): Package name

## Diagnostics

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

## Score history

- 2026-11-05: 66
- 2026-11-04: 65

## Common questions

### What is the Wisco Labs: developer tools MCP server?

Wisco Labs: developer tools is an MCP server listed in the public MCP registry as dev.wiscolabs/developer-tools. Check PyPI and npm upgrades: known vulnerabilities, the safe version, and what each upgrade breaks. This page covers its hosted endpoint (https://api.wiscolabs.dev/mcp/dev).

### Is the Wisco Labs: developer tools MCP server safe to use?

Wisco Labs: developer tools scores 66 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Wisco Labs: developer tools MCP server expose?

Wisco Labs: developer tools exposes 9 tools: vulnerabilities, upgrade_check, what_changed, peer_check, wheel_check, and 4 more. Their descriptions and schemas cost roughly 1,326 tokens of context every time the server is loaded.

### Does the Wisco Labs: developer tools MCP server require authentication?

No. We connected to Wisco Labs: developer tools without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Wisco Labs: developer tools MCP server still maintained?

Wisco Labs: developer tools is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://api.wiscolabs.dev/mcp/dev
- Website: https://wiscolabs.dev/
- Changelog RSS feed: https://verifymcp.io/servers/dev-wiscolabs-developer-tools/mcp-dev.xml
- Changelog JSON feed: https://verifymcp.io/servers/dev-wiscolabs-developer-tools/mcp-dev.json
- HTML version of this page: https://verifymcp.io/servers/dev-wiscolabs-developer-tools/mcp-dev