Koskamo

Wisco Labs MCP

An MCP server providing AI agents with data on open-source package upgrades, security vulnerabilities, and compatibility checks. It leverages OSV and GitHub Advisory Database to identify safe upgrade paths, detect malicious packages, and analyze breaking changes for Python and npm ecosystems.

Endpoint and access

No sign-in to connect and list tools. Individual tools may still need a vendor account, credentials, or permissions; check the documented prerequisites.

Wisco Labs MCP logo, by Wisco LabsVendor evidenceStreamable HTTPNo sign-inEndpoint checked 2026-11-07Operated by Wisco Labs
MCP endpoint (Streamable HTTP)
https://api.wiscolabs.dev/mcp/dev
Vendor documentation

What its tools do

9 tools, grouped by the hints the server advertises. Hints are self-declared, not verified behavior.

9 of 9 have a description · 9 of 9 declare behavior hints · 9 of 9 with parameters document them all

Checks and signals

Each line is separate evidence, not a trust score.

  • Passed Endpoint answered the live check ·
  • Passed Official MCP Registry namespace is tied to wiscolabs.dev ·
  • Passed Endpoint is on the registry namespace domain ·
  • Availability 1 of 1 checks passed in 30 days

What you can do with it

  • Check for known vulnerabilities in specific package versions
  • Analyze project dependencies to find safe upgrade paths
  • Check peer dependency compatibility before upgrading core packages
  • Verify prebuilt wheel availability for specific platforms

Source and maintenance

Vendor evidenceRegistry 1.0.1

Protocol and capabilities

Server
wisco-labs 0.3.1
MCP protocol negotiated in check
2025-11-25
Tools
9 advertised
Resources
Not advertised
Resource templates
Not advertised
Prompts
Not advertised
Server-advertised capabilities
{
  "tools": {
    "listChanged": false
  }
}

Server-provided instructions

Untrusted server output shown for inspection. It is not Koskamo guidance and is excluded from knowledge search.

Wisco Labs answers questions about open-source package upgrades and security from a continuously collected history of releases, release notes, and OSV vulnerability data. Covers Python (PyPI) and JavaScript (npm). Use upgrade_check with a project's requirements.txt, package-lock.json, or package.json to find malicious packages, versions with known vulnerabilities (with the smallest safe version to move to), and what each upgrade would break, ranked by what to do first. Use vulnerabilities for one exact version, what_changed for one package between two versions, and package_info for latest versions and basics.

Tools

9 advertised

vulnerabilities — Known vulnerabilities in a package version
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

vulnerabilities input schema
{
  "type": "object",
  "required": [
    "name",
    "version"
  ],
  "properties": {
    "name": {
      "type": "string",
      "examples": [
        "urllib3"
      ],
      "description": "Package name"
    },
    "version": {
      "type": "string",
      "examples": [
        "1.26.18"
      ],
      "description": "The exact version you're using"
    },
    "ecosystem": {
      "type": "string",
      "default": "PyPI",
      "description": "Package ecosystem (OSV naming)"
    }
  }
}
vulnerabilities annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
upgrade_check — Check a whole project's dependencies
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

upgrade_check input schema
{
  "type": "object",
  "required": [
    "requirements"
  ],
  "properties": {
    "limit": {
      "type": "string",
      "default": "5",
      "description": "Max items shown per category for each package"
    },
    "ecosystem": {
      "type": "string",
      "default": "PyPI",
      "description": "PyPI or npm. A package.json or package-lock.json is recognized as npm automatically."
    },
    "requirements": {
      "type": "string",
      "examples": [
        "flask==2.3.3\nrequests==2.31.0\npydantic==1.10.13"
      ],
      "description": "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 listed but can't be assessed."
    }
  }
}
upgrade_check annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
what_changed — What changed between two versions of a package
Advertised by the server during the last successful anonymous check.
Advertised read-only

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

what_changed input schema
{
  "type": "object",
  "required": [
    "name",
    "from",
    "to"
  ],
  "properties": {
    "to": {
      "type": "string",
      "examples": [
        "3.1.3"
      ],
      "description": "The version you want to upgrade to (use latest_version from package_info if unsure)"
    },
    "from": {
      "type": "string",
      "examples": [
        "2.3.3"
      ],
      "description": "The version you're on now"
    },
    "name": {
      "type": "string",
      "examples": [
        "flask"
      ],
      "description": "Package name, e.g. flask (PyPI) or express or @babel/core (npm)"
    },
    "limit": {
      "type": "string",
      "default": "15",
      "description": "Max items shown per category"
    },
    "ecosystem": {
      "type": "string",
      "default": "PyPI",
      "description": "PyPI or npm"
    }
  }
}
what_changed annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
peer_check — Will my npm packages accept this upgrade? (peer dependencies)
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

peer_check input schema
{
  "type": "object",
  "required": [
    "upgrade",
    "requirements"
  ],
  "properties": {
    "limit": {
      "type": "string",
      "default": "5",
      "description": "Max breaking changes shown for each suggested fix"
    },
    "upgrade": {
      "type": "string",
      "examples": [
        "react@19"
      ],
      "description": "The package and version to upgrade to: react@19 (newest stable 19.x), react@19.1.0 (exact), or react (latest stable)"
    },
    "requirements": {
      "type": "string",
      "examples": [
        "react@18.3.1\nreact-dom@18.3.1\nreact-redux@8.1.3"
      ],
      "description": "The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line"
    }
  }
}
peer_check annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
wheel_check — Will pip find prebuilt wheels for this platform?
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

wheel_check input schema
{
  "type": "object",
  "required": [
    "requirements",
    "python",
    "platform"
  ],
  "properties": {
    "limit": {
      "type": "string",
      "default": "5",
      "description": "Max breaking changes shown for each suggested upgrade"
    },
    "python": {
      "type": "string",
      "examples": [
        "3.13"
      ],
      "description": "Target Python version, e.g. 3.13"
    },
    "platform": {
      "type": "string",
      "examples": [
        "win_arm64"
      ],
      "description": "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 (Alpine), win_amd64, win_arm64, win32, macosx_arm64, macosx_x86_64"
    },
    "requirements": {
      "type": "string",
      "examples": [
        "numpy==1.26.4\npsycopg2==2.9.9\nrequests==2.31.0"
      ],
      "description": "requirements.txt contents or pip freeze output, one 'package==version' per line"
    }
  }
}
wheel_check annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
node_check — Will my npm dependencies run on this Node.js version?
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

node_check input schema
{
  "type": "object",
  "required": [
    "node",
    "requirements"
  ],
  "properties": {
    "node": {
      "type": "string",
      "examples": [
        "24"
      ],
      "description": "Target Node.js version: a major like 24 (means the latest 24.x) or an exact 22.11.0"
    },
    "limit": {
      "type": "string",
      "default": "5",
      "description": "Max breaking changes shown for each suggested fix"
    },
    "requirements": {
      "type": "string",
      "examples": [
        "express@4.18.2\nnext@13.5.6"
      ],
      "description": "The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line"
    }
  }
}
node_check annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
native_check — Will my npm dependencies install on this platform without compiling?
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

native_check input schema
{
  "type": "object",
  "required": [
    "platform",
    "requirements"
  ],
  "properties": {
    "limit": {
      "type": "string",
      "default": "5",
      "description": "Max breaking changes shown for each suggested fix"
    },
    "platform": {
      "type": "string",
      "examples": [
        "alpine-arm64"
      ],
      "description": "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": {
      "type": "string",
      "examples": [
        "sharp@0.32.6\nbcrypt@5.1.1"
      ],
      "description": "The project's dependencies: the contents of package-lock.json (best), package.json, or one 'name@version' per line"
    }
  }
}
native_check annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
types_check — Which npm dependencies need @types packages, and which version?
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

types_check input schema
{
  "type": "object",
  "required": [
    "requirements"
  ],
  "properties": {
    "requirements": {
      "type": "string",
      "examples": [
        "express@4.21.2\n@types/express@5.0.0\nlodash@4.17.21"
      ],
      "description": "The project's dependencies, including any @types packages: the contents of package-lock.json (best), package.json, or one 'name@version' per line"
    }
  }
}
types_check annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
package_info — Basic facts about a package
Advertised by the server during the last successful anonymous check.
Advertised read-only

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

package_info input schema
{
  "type": "object",
  "required": [
    "name"
  ],
  "properties": {
    "name": {
      "type": "string",
      "examples": [
        "flask"
      ],
      "description": "Package name"
    },
    "ecosystem": {
      "type": "string",
      "default": "PyPI",
      "description": "PyPI or npm"
    }
  }
}
package_info annotations
{
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}

Prompts

Not advertised

No prompt definitions available.

Resources

Not advertised

No resource definitions available.

90-day uptime

A lightweight connection check about every six hours, sampled on hosts with many listings. It shows the server answered, not that its tools work.

Too few checks for a percentage yet (1 of 1 answered).

  1. 2026-11-07: 1 of 1 checks answered

30-day availability

Aggregated from read-only remote checks; this is not a tool-execution or security guarantee.

Successful checks
1 of 1 (100%)
Average latency
762 ms
95th percentile latency
762 ms

Maintenance history

Public check and source-refresh events. Editorial and ownership records remain private.

  • · probe · passed · 762 ms · metadata changed · 9 tool(s)

Connect from your client

Each snippet registers the same endpoint; pick the client you use.

This server is operated by the named third party. Listing and endpoint checks are not an endorsement or a security audit. Review the operator's permissions, terms, and data handling before connecting. How listings are checked and corrected.

Claude Code

Run this once in a terminal. It registers the remote server. Use --scope project to write .mcp.json for the repo.
Claude Code configuration
claude mcp add --transport http wisco-labs-mcp https://api.wiscolabs.dev/mcp/dev

Codex

Run this once. Codex stores MCP servers in ~/.codex/config.toml (or .codex/config.toml in a trusted project).
Codex configuration
codex mcp add wisco-labs-mcp --url https://api.wiscolabs.dev/mcp/dev

Cursor

Merge this server into .cursor/mcp.json in your project, then enable wisco-labs-mcp in your MCP settings.
Cursor configuration
{
  "mcpServers": {
    "wisco-labs-mcp": {
      "url": "https://api.wiscolabs.dev/mcp/dev"
    }
  }
}

Cline

Merge this into cline_mcp_settings.json (Cline → MCP Servers → Configure).
Cline configuration
{
  "mcpServers": {
    "wisco-labs-mcp": {
      "type": "streamableHttp",
      "url": "https://api.wiscolabs.dev/mcp/dev",
      "disabled": false
    }
  }
}

VS Code

Merge this server into .vscode/mcp.json. Use MCP: List Servers to start wisco-labs-mcp and inspect its tools.
VS Code configuration
{
  "servers": {
    "wisco-labs-mcp": {
      "type": "http",
      "url": "https://api.wiscolabs.dev/mcp/dev"
    }
  }
}

Gemini CLI

Run this once. It writes .gemini/settings.json in the current project; pass --scope user for ~/.gemini/settings.json.
Gemini CLI configuration
gemini mcp add --transport http wisco-labs-mcp https://api.wiscolabs.dev/mcp/dev

Claude Desktop

Open Claude Settings > Connectors > Add custom connector, enter this server URL and enable it for the conversation. This is a manual remote-connector handoff, not a desktop JSON configuration.
Claude Desktop configuration
https://api.wiscolabs.dev/mcp/dev

Windsurf

Merge this into ~/.codeium/windsurf/mcp_config.json, then refresh MCP in Cascade. Windsurf remote servers use serverUrl, not url.
Windsurf configuration
{
  "mcpServers": {
    "wisco-labs-mcp": {
      "serverUrl": "https://api.wiscolabs.dev/mcp/dev"
    }
  }
}

Let your agent find its tools

Find servers like Wisco Labs MCP from your agent. Add Koskamo once to search the index for endpoints, access requirements, and client setup. Public discovery needs no key.

Do you run Wisco Labs MCP?

Prove ownership with a DNS record, a well-known file, or your Official MCP Registry entry, and your edits publish immediately. Proofs are re-checked weekly; admins can still hide or remove a listing.

Claim this listing