Wisco Labs: developer tools
REMOTE · API.WISCOLABS.DEV
Check PyPI and npm upgrades: known vulnerabilities, the safe version, and what each upgrade breaks.
Available components
Last scanned (2 hours ago)
Scores higher than 52% of remote servers
Reachable. Last reached 5 Nov 2026.
Category Security
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. How we score → Why this is hard to score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS enforcement could not be verified: the plaintext port answered with HTTP 406, which proves neither a plaintext path nor enforcement. View diagnostics → Unverified
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability68
- AI-judged instruction clarity (good).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management3
- Stability observed for 1 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 10 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 +1
- Stability: unverified → 0.03 ▲ functional
- 4 Nov 26 65
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://api.wiscolabs.dev/mcp/dev
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=wiscolabs.dev | CN=YE1,O=Let's Encrypt,C=US | 26 Oct 2026 | 24 Jan 2027 | ECDSA 256 | ECDSA-SHA384 | 594a881d149bab83c17ec4e0f4ce5e36f1f |
| SANs: *.wiscolabs.dev, wiscolabs.dev | ||||||
| CN=YE1,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 5ddd70dd31f801c85c186a7a04b80afe |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of api.wiscolabs.dev. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| dev. | present | 60074 | 8 | Verified |
| wiscolabs.dev. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://api.wiscolabs.dev/mcp/dev | Verified | 200 | |
| http (plaintext) | http://api.wiscolabs.dev/mcp/dev | Inconclusive | 406 |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
native_check Will my npm dependencies install on this platform without compiling? ~205
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | string | – | Max breaking changes shown for each suggested fix |
| platform | string | yes | 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 | yes | The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line |
No output schema declared.
No examples provided.
node_check Will my npm dependencies run on this Node.js version? ~159
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | string | – | Max breaking changes shown for each suggested fix |
| node | string | yes | Target Node.js version: a major like 24 (means the latest 24.x) or an exact 22.11.0 |
| requirements | string | yes | The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line |
No output schema declared.
No examples provided.
package_info Basic facts about a package ~47
Latest and latest stable version, repository, release count, and where its release notes come from.
| Name | Type | Req | Description |
|---|---|---|---|
| ecosystem | string | – | PyPI or npm |
| name | string | yes | Package name |
No output schema declared.
No examples provided.
peer_check Will my npm packages accept this upgrade? (peer dependencies) ~178
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | string | – | Max breaking changes shown for each suggested fix |
| requirements | string | yes | The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line |
| upgrade | string | yes | The package and version to upgrade to: react@19 (newest stable 19.x), react@19.1.0 (exact), or react (latest stable) |
No output schema declared.
No examples provided.
types_check Which npm dependencies need @types packages, and which version? ~93
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.
| Name | Type | Req | Description |
|---|---|---|---|
| requirements | string | yes | The project's dependencies, including any @types packages: the contents of package-lock.json (best), package.json, or one 'name@version' per line |
No output schema declared.
No examples provided.
upgrade_check Check a whole project's dependencies ~199
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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… |
No output schema declared.
No examples provided.
vulnerabilities Known vulnerabilities in a package version ~78
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.
| Name | Type | Req | Description |
|---|---|---|---|
| ecosystem | string | – | Package ecosystem (OSV naming) |
| name | string | yes | Package name |
| version | string | yes | The exact version you're using |
No output schema declared.
No examples provided.
what_changed What changed between two versions of a package ~120
What breaks, gets removed, is deprecated, or gains a security fix when upgrading one package between two versions, with an overall upgrade risk.
| Name | Type | Req | Description |
|---|---|---|---|
| ecosystem | string | – | PyPI or npm |
| from | string | yes | The version you're on now |
| limit | string | – | Max items shown per category |
| name | string | yes | Package name, e.g. flask (PyPI) or express or @babel/core (npm) |
| to | string | yes | The version you want to upgrade to (use latest_version from package_info if unsure) |
No output schema declared.
No examples provided.
wheel_check Will pip find prebuilt wheels for this platform? ~247
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | string | – | Max breaking changes shown for each suggested upgrade |
| platform | string | yes | 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 | yes | Target Python version, e.g. 3.13 |
| requirements | string | yes | requirements.txt contents or pip freeze output, one 'package==version' per line |
No output schema declared.
No examples provided.
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.
remote · api.wiscolabs.dev
claude mcp add --transport http dev-wiscolabs-developer-tools 'https://api.wiscolabs.dev/mcp/dev'
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.