Skip to main content
Glama
Sign In
MCP Server Change and Health Monitor

MCP Server Change and Health Monitor

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

MCP Server Change and Health Monitor MCP Server

npm version license

An MCP server for the Mamba Labs MCP Server Change and Health Monitor actor on Apify. Check any list of MCP servers and get one row per server: did it answer, what it exposes, and what changed.

What's Inside

Related MCP server: mcp-audit

What it does

Give it MCP server URLs, npm packages, or a search of the official MCP Registry. It speaks the MCP protocol to each server and returns whether the server answered, how fast, the tools it exposes now, and what changed since the last run. Changes are marked breaking, warning, or info.

All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer and an Apify account with an API token.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-mcp-server-change-health-monitor": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-server-change-health-monitor"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The check_mcp_servers tool appears.

Prerequisites

Example prompts

  • "Are these three MCP servers up, and did any of their tools change since last week?"

  • "Check every server in the official MCP Registry that matches github and list which ones answer."

  • "Did the tool descriptions on this MCP server change since my last check?"

Tool

check_mcp_servers. One tool. Example arguments:

{
  "server_urls": [
    "https://mcp.deepwiki.com/mcp"
  ]
}

Inputs

Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.

Input

Type

Required

Description

server_urls

array

no

HTTP endpoints of MCP servers. Streamable HTTP is tried first, then the older HTTP plus SSE transport.

npm_packages

array

no

npm package names, optionally with a version, such as @modelcontextprotocol/server-everything. Each is installed and started inside your run. The code in a package you list runs in your run, so list only packages you trust. No environment variables are passed to it.

registry_search

array

no

Search terms for the official MCP Registry. The HTTP endpoints of matching servers are checked. Packages found this way are listed but never run, because running code picked by a keyword is not safe.

max_servers

number

no

Most servers to check per registry search term, up to 200. Default 25.

snapshot_key

string

no

Name of the memory that holds the last run's results, so a scheduled run finds changes on its own. Use a different name per list. Default default.

previous_snapshot

string

no

Optional. The JSON of a SNAPSHOT record from an earlier run, or an https link to that record. It takes the place of the saved snapshot for this run.

timeout_seconds

number

no

How long one request to a server may take before it counts as no answer, 3 to 60. Default 20. A package gets 60 more seconds to install.

include_resources_prompts

boolean

no

Also list the server's resources and prompts and report what changed in them. Default true.

auth_headers

string

no

Optional, for servers you are allowed to check. JSON keyed by site, for example {"https://mcp.example.com":{"Authorization":"Bearer abc"}}. Each header goes only to its own site. Encrypted by Apify, never logged, never saved in a snapshot.

max_charge_usd

string

no

Optional. The run stops before a charge that would pass this amount. Free rows are always returned.

Pricing

Pay per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

server-check, one MCP server checked

$0.005

$0.00475

$0.0045

$0.00425

package-check, one npm package installed and checked

$0.02

$0.019

$0.018

$0.017

apify-actor-start, per run start

$0.002

$0.002

$0.002

$0.002

Servers that need credentials or refused the request, invalid entries, registry rows, and refused input are free. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.

Full actor documentation

apify.com/mambalabs/mcp-server-change-health-monitor

License

MIT. See LICENSE.

Available Tools

1 tool
check_mcp_serversCheck MCP servers for changes and healthA
Read-only

Check MCP servers by URL, npm package, or official registry search. Returns one row per server: whether it answered, how fast, the tools it exposes now, and what changed since the last run, with breaking changes marked. Runs on Apify, pay per event.

NameRequiredDescriptionDefault
max_serversNoMost servers to check per registry search term, up to 200. Default 25.
server_urlsNoHTTP endpoints of MCP servers. Streamable HTTP is tried first, then the older HTTP plus SSE transport.
auth_headersNoOptional, for servers you are allowed to check. JSON keyed by site, for example {"https://mcp.example.com":{"Authorization":"Bearer abc"}}. Each header goes only to its own site. Encrypted by Apify, never logged, never saved in a snapshot.
npm_packagesNonpm package names, optionally with a version, such as @modelcontextprotocol/server-everything. Each is installed and started inside your run. The code in a package you list runs in your run, so list only packages you trust. No environment variables are passed to it.
snapshot_keyNoName of the memory that holds the last run's results, so a scheduled run finds changes on its own. Use a different name per list. Default default.
max_charge_usdNoOptional. The run stops before a charge that would pass this amount. Free rows are always returned.
registry_searchNoSearch terms for the official MCP Registry. The HTTP endpoints of matching servers are checked. Packages found this way are listed but never run, because running code picked by a keyword is not safe.
timeout_secondsNoHow long one request to a server may take before it counts as no answer, 3 to 60. Default 20. A package gets 60 more seconds to install.
previous_snapshotNoOptional. The JSON of a SNAPSHOT record from an earlier run, or an https link to that record. It takes the place of the saved snapshot for this run.
include_resources_promptsNoAlso list the server's resources and prompts and report what changed in them. Default true.

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, non-idempotent, and non-destructive, so the safety bar is lowered. The description adds real value beyond them: the 'pay per event' cost model and the fact that breaking changes are marked in results. It does not disclose two notable behaviors that only the schema carries - that listed npm packages are installed and executed inside the run, and that snapshot state is written between runs (only hinted at by 'since the last run').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the action and inputs, then the return contract, then the cost/deployment note. No filler, no restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a ten-parameter tool with no output schema, the description supplies the return contract and change-detection semantics, while the schema fully documents every parameter. What is missing is the side-effect story (npm code execution in your run, snapshot persistence) at the description level, which matters for a tool an agent may schedule.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the mapping of the three input modes to server_urls, npm_packages, and registry_search but adds no syntax, defaults, or constraints beyond what the schema already documents for all ten parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check MCP servers') and enumerates the three accepted input modes (URL, npm package, official registry search). It also states the return shape ('one row per server: whether it answered, how fast, the tools it exposes now, and what changed'), so an agent knows both what goes in and what comes out without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (health/change auditing of MCP servers) and names the three modes, but never says which mode to pick or when not to use the tool. There are no siblings to route against, so the missing guidance is mostly about mode selection, which is deferred entirely to the schema descriptions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedcheck_mcp_servers
Deploy Server
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A4/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of misselection between overlapping tools. Its purpose—health-checking and diffing MCP servers—is clearly stated.

Naming Consistency5/5

The single name check_mcp_servers follows a clear verb_noun snake_case convention. With one tool there is no inconsistency to introduce.

Tool Count3/5

A single tool is thin even for a narrow monitoring scope; the three input modes (URL, npm package, registry search) could arguably be distinct tools. Still, one 'check' operation is a defensible minimal surface.

Completeness3/5

The core action—probe a server, report latency, exposed tools, and diffs with breaking changes marked—is covered. However, there's no way to manage a watchlist, batch-check multiple servers, or retrieve historical results beyond 'since the last run'.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Related MCP Servers

  • freshdeps-mcp

    SolvoHQ
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server that checks npm and PyPI package health, providing maintenance signals, version info, CVE counts, and alternative suggestions.
    MIT

  • mcp-audit

    andreolf
    A
    license
    Not graded
    quality
    B
    maintenance
    npm audit for MCP servers. Point it at an MCP server and get a security grade (A–F) covering missing auth, SSRF surface, high-privilege tools, prompt-injection-prone tool descriptions, and leaked secrets.
    4 npm
    MIT

  • mcpcost

    actions-marketplace-validations
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables agents to look up and search servers from the official MCP registry, probe any server live for availability, protocol, auth, tools and context-token cost, and retrieve registry-wide statistics. Also supplies a CLI and GitHub Action that measure how many tokens your own configured servers' tool definitions consume against a budget.
    MIT