Wisco Labs: developer tools

dev.wiscolabsPublished by wiscolabs.devOfficial publisherv1.0.1Updated Nov 5, 2026

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

VerifiedStreamable HTTPWeb executableDeveloper ToolsSecurity & Monitoring

Overview

AI-generated overview

Answers questions about PyPI and npm package upgrades: known vulnerabilities, the smallest safe version, and what each upgrade breaks.

What you can do
  • Check a project's dependency file (requirements.txt, pip freeze, package-lock.json, package.json) for malicious packages, vulnerable versions and breaking upgrades, ranked by priority
  • Look up whether one exact package version is affected by known advisories, with CVE ids, severity and the smallest safe upgrade
  • Compare one package between two versions to see what breaks, is removed or deprecated, plus an overall upgrade risk
  • Check npm peer dependencies, Node.js engine support, native binaries per platform, and Python wheel availability for a target version or platform
  • Inspect TypeScript type declarations and @types packages, and get latest versions, repository and release-note sources
When to use it
Useful when planning dependency upgrades or audits for Python or JavaScript projects, especially before moving to a new Node.js or Python version, a new platform such as Alpine, ARM or Lambda, or a major framework release.
Requirements
A remote streamable HTTP endpoint; no package, environment variables or headers are declared. The assistant supplies dependency file contents or package names and versions.
Before you install
Results come from a third party's collected release, release-note and OSV data, so treat upgrade and vulnerability advice as advisory and verify before applying. Dependency file contents you paste are sent to that remote service.

Installation

In SourceWeft

  1. Open Wisco Labs: developer tools in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/dev.wiscolabs%2Fdeveloper-tools/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

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

Tools

9

vulnerabilities

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.

Parametersnamerequiredversionrequiredecosystem

upgrade_check

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.

Parameterslimitecosystemrequirementsrequired

what_changed

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.

Parameterstorequiredfromrequirednamerequiredlimitecosystem

peer_check

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.

Parameterslimitupgraderequiredrequirementsrequired

wheel_check

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.

Parameterslimitpythonrequiredplatformrequiredrequirementsrequired

node_check

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.

Parametersnoderequiredlimitrequirementsrequired

native_check

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.

Parameterslimitplatformrequiredrequirementsrequired

types_check

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.

Parametersrequirementsrequired

package_info

Basic facts about a package

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

Parametersnamerequiredecosystem

Version history

2
  1. v1.0.1LatestNov 5, 2026
  2. v1.0.0Nov 4, 2026

Score

83% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts

    Declare a GitHub repository with a README, or serve resource_documentation in the OAuth protected-resource metadata.

  • LicenseNot applicable

    A hosted service is used under its provider's terms, so no license is expected here. This check is left out of the percentage.