mcpbeat Sign in

Vigía MCP Server

by coredls-vigia Your server? Claim it
answering

Vigía is answering right now. Last checked 11 min ago. It exposes 12 tools. Last commit 1 Nov 2026.

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

Uptime history 43 days of history · worst day 87%
43 days agonow
100.0%
Uptime 24h
91 of 91 checks
12
Tools
read from the server
737 ms
Response time
average over 24h
1
Stars
last commit 1 Nov 2026

What changed 39

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 1 October 2026. No other catalogue keeps this.

11 Oct a tool appeared changes_since_cutoff
11 Oct a tool changed version
9 Oct 9 tools changed the parameters they ask for check_dependencies, eol_status, find_compatible_version and 6 more
9 Oct 9 tool descriptions were rewritten check_dependencies, eol_status, find_compatible_version and 6 more
9 Oct 2 tools appeared list_versions, model_status
9 Oct a tool changed version
9 Oct a tool disappeared model_info
8 Oct 6 tools changed the parameters they ask for check_dependencies, find_compatible_version, find_package and 3 more
8 Oct 3 tool descriptions were rewritten find_compatible_version, package_status, version_status
8 Oct a tool appeared eol_status
and 5 more, back to 1 October 2026

What the code does

We read the source, 2 h ago · tools taken from the live server · rules 995398eba69f

Capabilities

What this server is able to do. For an MCP server this is often the job itself — a terminal server runs commands because that is what it is for. Listed so you know what you are plugging in, not as an accusation.

Reads files and sends them to the network action/check.mjs:2
import { readFileSync, existsSync, readdirSync, appendFileSync } from 'node:fs';

Is this your server and something here is wrong? Tell us — corrections are free and do not require a plan.

This code can reach further than it looks

We found places where it runs commands, builds paths or queries from values it is given. None of that is a flaw by itself — it becomes one when the code changes, and code changes quietly between releases. We re-read it on every one.

Three servers free · no card

Connect this server

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

run in your terminal
claude mcp add vigia --transport http https://vigia.coredls.cloud/mcp
Settings → Connectors → Add custom connector, then paste this address
https://vigia.coredls.cloud/mcp
~/.codex/config.toml
[mcp_servers.vigia]
url = "https://vigia.coredls.cloud/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "vigia": {
      "url": "https://vigia.coredls.cloud/mcp"
    }
  }
}
.vscode/mcp.json
{
  "servers": {
    "vigia": {
      "type": "http",
      "url": "https://vigia.coredls.cloud/mcp"
    }
  }
}

Available tools 12

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

package
find_package
Searches the catalog of tracked packages and AI models by case-insensitive name prefix and returns up to 15 matches ordered by popularity, each with its ecosystem, name and popularity rank. Read-only and requires no authentication. It matches only the beginning of the name (not descriptions or keywords) and covers tracked packages only, about 34,000 across npm, PyPI, crates.io and Packagist. Use it when you do not know the exact package or model name before calling package_status, list_versions or model_status; it is not a way to discover packages by what they do.
package_status
Returns the current state of one package: latest stable version and its publish date, status (active / deprecated / yanked / not_found_in_registry), the deprecation message if any, runtime requirements (npm engines and peerDependencies, PyPI Requires-Python, Rust rust-version, PHP require.php), license, known security advisories on the latest version, a release-activity summary (active / slowing / dormant) and the sources with their last verification time. Read-only and requires no authentication. A package Vigia does not track yet is fetched live from its registry on the first call (a few seconds); if the name does not exist the result has status not_found_in_registry plus similar-name suggestions. Use it to decide whether to add or recommend a package, or to learn its newest version. For a specific version you already have use version_status; for what breaks when moving between two versions use upgrade_impact; to find a release that fits an older runtime use find_compatible_version; to find a package whose exact name you do not know use find_package.
changes
changes_since_cutoff
Returns what happened in software after a given date, so an agent can patch the gap between its training data and today: packages among the most popular on npm, PyPI, crates.io and Packagist that shipped a NEW MAJOR VERSION after the date (with the version that existed at that date, the new majors and their first release dates, the latest version, and an upgrade-guide link when one exists), runtimes, frameworks and platforms released or ended since (Python, Node.js, PHP, Java, Django, Laravel, Ubuntu, PostgreSQL and about 35 more), runtimes ending within 180 days, and AI models released since by the main providers with their prices. Read-only and requires no authentication. Results are computed from registry publication dates and cached for an hour. Coverage is the most popular packages (not every package), 0.x-to-0.y changes and calendar-versioned packages are not reported as major versions, and deprecations that happened before Vigia started tracking are not listed. Use it once at the start of a coding session, passing the month your training data ends, or when you suspect a library you know has changed a lot. To dig into one package use upgrade_impact (npm) or package_status; for one runtime use eol_status.
compatible
find_compatible_version
Finds the newest stable, non-withdrawn version of a package whose own declared requirements admit the runtimes you give it: npm engines and peerDependencies, PyPI Requires-Python, Rust rust-version (minimum Rust), PHP require.php and required packages. Returns the best version with the per-constraint checks, the newest release that is incompatible together with the reason it fails, and a list of unverified constraints (a version that declares nothing for a constraint is not counted against it but is flagged). Read-only and requires no authentication. If per-version requirement data for a package is still being loaded, the result has status "requirements_not_synced_yet" and retry_after_s. Use it when a project is pinned to an older Node, React, Python, Rust or PHP and the latest release may not support it. For the plain latest version use package_status; to check whether the runtime itself is still supported use eol_status.
dependencies
check_dependencies
Audits a whole manifest in one call. For every dependency in a package.json (dependencies and devDependencies) or a requirements.txt it returns the latest version, whether the declared range includes it (up_to_date / outdated / outdated_major / unpinned / unsupported_spec), how many major versions behind it is, whether the package is deprecated, and the OSV vulnerability IDs of the lowest version the range allows; a summary with counts comes first. Read-only and requires no authentication. Nothing is stored. Up to 300 dependencies are handled per call; packages Vigia does not track yet are resolved live (up to 40 per call), and the rest come back as not_resolved_yet with retry_after_s. Only npm and PyPI manifests are supported. Use it when opening a project or before upgrading its dependencies. For a single package use package_status; for one exact version use version_status.
eol
eol_status
Tells whether a language, runtime, framework, database or operating-system version is still supported and when it reaches end of life. Covers about 480 products (Python, Node.js, PHP, Java, Ruby, Go, Rust, Django, Laravel, Rails, React, Angular, PostgreSQL, MySQL, Ubuntu, Debian, Kubernetes and more). With product and version it returns that version's status (supported / security_only / end_of_life / upcoming), its release, active-support and end-of-life dates, days remaining or elapsed, and the cycles that are still supported; with only product it returns every release cycle; with neither it lists the product identifiers. Read-only and requires no authentication. Status is computed on every call from today's date; the dates come from endoflife.date and are refreshed every 12 hours. Use it before choosing a runtime or base image, when writing a Dockerfile or CI matrix, or when auditing an old version. It concerns the language, runtime or platform itself; for a library's own versions use package_status.
model
model_status
Looks up AI models in the OpenRouter catalog: price per million input and output tokens in USD, context window, maximum output tokens, knowledge cutoff, supported modalities and announced retirement date, with a status of available / retiring / removed_from_catalog. With model_id it returns that one model (if the id is unknown, a list of similar ids); with provider and/or query it returns up to 40 matching models. Read-only and requires no authentication. Prices are OpenRouter reference prices and may differ from a provider's direct pricing; the catalog is refreshed every 15 minutes. Use it before writing a model ID in code, choosing between models, estimating costs, or checking whether a model is being retired. It does not call, run or benchmark models.
recent
recent_changes
Lists the changes Vigia detected recently, newest first: new package releases (with old and new version), deprecations, yanks and removals, runtime-requirement changes, AI model price changes and model retirement announcements. Each item has the entity, the kind of change, the old and new values and the detection time. Without a name it returns the global feed; with ecosystem and name it returns the change history of that one package or model. Read-only and requires no authentication. History only goes back to when Vigia started tracking the entity, so it is not a package's full release history (use list_versions for that). Use it to find out what happened after your training data ends, or whether a dependency or model has just changed.
symbol
symbol_status
Checks whether an exported function, class, type or constant (or a Class.member) exists in a specific version of an npm package, using the package's TypeScript declarations. Returns whether it was found, its kind, its exact signature, the module path to import it from, whether it is deprecated (with the deprecation message) and, when it is not found, close-name suggestions. Read-only and requires no authentication. The first lookup for a package version can take up to about 25 seconds while its types are analyzed; a result with status "pending" and retry_after_s means call again after that delay. Limits: npm packages with TypeScript types only; exports that exist at runtime but have no type declaration are not visible. Use it before writing code that calls a library API you are not sure exists, or has the same signature, in the installed version, especially after a major upgrade. For a complete list of what changed between two versions use upgrade_impact.
upgrade
upgrade_impact
Reports what changes between two versions of an npm package by diffing the public TypeScript API of both releases (only the type declarations are analyzed; package code is never executed): removed exports and import paths, changed function signatures and class or interface members, newly deprecated APIs, changed engines and peerDependencies, and the changelog sections published in between. Returns a summary with counts and a likely_breaking flag, followed by the before/after detail of each change. Read-only and requires no authentication. The first request for a version pair can take up to about 25 seconds while the analysis runs; if it is still running the result has status "pending" and retry_after_s, and you should call again after that delay. Limits: only npm packages that ship TypeScript types (or have @types) can be analyzed, and behavior changes that do not alter types (for example new caching defaults) are invisible, so also read the returned changelog. Use it BEFORE upgrading a dependency across a major version, or when code written for an old version fails on a new one. For one API in one version use symbol_status; for vulnerabilities use version_status; to choose a version that fits an older runtime use find_compatible_version.
version
version_status
Reports on one exact version of an npm, PyPI, crates.io or Packagist package: whether that version exists, when it was published, whether it is withdrawn (npm deprecated, PyPI and crates.io yanked, Packagist abandoned), how many stable releases and major versions it is behind the latest, and its known vulnerabilities from OSV with severity, summary, the version that fixes each one, and the single nearest version that fixes all of them (null if any has no fix). Read-only and requires no authentication. Vulnerability data is cached for up to 6 hours, and the response states when OSV could not be reached. Use it before keeping, pinning or recommending a specific version, or when auditing one lockfile entry. For the latest version and general package health use package_status; to audit a whole manifest at once use check_dependencies.
versions
list_versions
Lists the published versions of one package, newest first, each with its publish date, a prerelease flag and whether it is withdrawn (npm: deprecated; PyPI and crates.io: yanked; Packagist: abandoned), plus a maintenance summary: last release date, releases in the last 12 months and an activity label (active / slowing / dormant). Read-only and requires no authentication. A package Vigia does not track yet is fetched live on the first call. Use it to judge release cadence, to see which version was current at a given date, or to check whether a version was ever withdrawn. For only the latest version use package_status; for the vulnerabilities of one version use version_status.

Tools removed

Tools this server used to expose. Anything built against them stopped working on the day they went.

model_info
removed 9 Oct 2026

Endpoints

URLTransportStateLatencyChecked
https://vigia.coredls.cloud/mcp streamable-http answering 728 ms 11 min ago

Alternatives to Vigía

same job, measured the same way
Wisco Labs: developer tools
by wiscolabs

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

9 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
Dependency Vulnerability Check (OSV)
by brunckel

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

answering
npm Plus
by ofershap

npm MCP — search packages, bundle sizes, vulnerabilities, compare downloads.

61 installs/wk local only
Cve Intel MCP
by robertoyanguas-ops

Queries live Google OSV.dev vulnerability intelligence for any PyPI, npm, Go, or Rust crate and re

2 tools answering
Reachvuln
by cloudcorprecords

Rank vulnerabilities by whether the vulnerable code path is reachable in your code.

299 installs/wk 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
Promptrejectormcp
by revsmoke

Security gateway for AI agents: detects prompt injections, jailbreaks, and common vulnerabilities.

81 installs/wk local only

Vigía — questions

Answers built from our own checks of this server.

What can Vigía do?
It exposes 12 tools, read directly from the server on our last check. Among them: changes_since_cutoff, check_dependencies, eol_status, find_compatible_version, find_package, list_versions and 6 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 Vigía 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 737 ms. The bar chart above shows every period we have measured.
Did Vigía ever remove tools?
Yes. model_info is no longer exposed — we recorded the date each one disappeared. A tool vanishing usually means a breaking change for anything that depended on it.
How do I connect Vigía?
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 Vigía need an API key?
No. Vigía completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 12 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Vigía?
It answers our handshake in 737 ms on average, which is faster than 12% 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.
Is Vigía open source?
The code is open source: it is published under the AGPL-3.0 licence, written in TypeScript and 1 stars on GitHub. The licence covers the code in the repository, not the hosted service at vigia.coredls.cloud, which runs on its operator's own terms.