MCP Server Change and Health Monitor

Check MCP servers for changes and health

check_mcp_servers

Read-only

Check MCP servers for availability, response speed, exposed tools, and changes since the last run, with breaking changes marked.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_mcp_servers"
  }
}

Input Schema

Name	Required	Description
`max_servers`	No	Most servers to check per registry search term, up to 200. Default 25.
`server_urls`	No	HTTP endpoints of MCP servers. Streamable HTTP is tried first, then the older HTTP plus SSE transport.
`auth_headers`	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.
`npm_packages`	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.
`snapshot_key`	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.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount. Free rows are always returned.
`registry_search`	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.
`timeout_seconds`	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.
`previous_snapshot`	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.
`include_resources_prompts`	No	Also list the server's resources and prompts and report what changed in them. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 6, 2026

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.

Deploy Server

Other Tools

check_mcp_serversA