Track new MCP servers, versions and remote endpoints

MCP Server Registry Tracker turns the official Model Context Protocol registry into an MCP server list for AI platform teams, agent builders, devtool vendors, security teams and directory publishers. Export server versions, remote transports, package coordinates and lifecycle signals, or schedule a watch that emits changed latest servers.

MCP server list: what data can you get?

Each dataset row describes one published server version. Default runs return latest active versions only.

Fields	What they contain
name, title, description, version	Registry identity and redacted product prose
isLatest, status	Latest marker and active, deprecated or deleted status
publishedAt, updatedAt, statusChangedAt	Registry timestamps
repositoryUrl, repositorySource, websiteUrl	Published links, without credentials or query parameters
remotes	Transport type and sanitized endpoint URL
packages	Registry type, identifier, version, transport and runtime hint
Package input lists	Environment variable and argument names with isRequired and isSecret flags
requiredEnvironmentVariableCount, requiredArgumentCount	Required input occurrences across packages
namespaceOwnerType	github for io.github.*, otherwise custom_domain
signals, changes, collectedAt	Deterministic flags, monitoring differences and observation time

Package types can include npm, PyPI, OCI, NuGet and MCPB. Other registry types are preserved when published. Positional arguments without names have a null name. No argument values, environment defaults, examples, headers or publisher extension metadata are emitted.

How to use the MCP registry API tracker

1. Run with the prefilled maximum of 25 rows for a quick preview.
2. Optionally enter search, a substring of a server name, or a namespacePrefix.
3. Set maxResults for the required export size, up to 5,000 rows.
4. Download the dataset as JSON, CSV or Excel, or use its Apify API endpoint.
5. Enable monitoring and schedule the same input to receive changes over time.

Empty API input {} works and defaults to 200 rows. The registry page limit is 100. The Actor only requests the official registry API and its robots policy. Repository and package destinations are output evidence, with no requests to GitHub, npm or PyPI.

{
  "search": "filesystem",
  "latestOnly": true,
  "includeDeprecated": false,
  "maxResults": 25,
  "monitorMode": false
}

Input	Default	Purpose
search	Empty	Registry substring search on name
updatedSince	Empty	ISO timestamp with timezone
latestOnly	true	Latest registry version only
includeDeprecated	false	Include deprecated and deleted entries
namespacePrefix	Empty	Case-sensitive namespace prefix filter
onlySignals	[]	Include any matching signal
maxResults	200	Emitted row cap, 1 to 5,000; preview prefill is 25
monitorMode	false	Emit first observations and monitored changes
monitorKey	default	Separate a watch baseline
requestDelayMs	300	Minimum request interval, 100 to 30,000 ms

Local filters may require more pages than the number of rows returned. A run has a 45 second collection budget and a 100 page safety cap. Large watches continue across scheduled runs.

New MCP servers and deterministic signals

Signal	Meaning
new_server	First observation in this watch, or an inventory row without a baseline
new_version	Version differs from the previously observed latest version in monitor mode
deprecated, deleted	Registry lifecycle status
remote_only	At least one valid remote, with no packages
has_npm, has_pypi, has_oci	A package uses this registry type
requires_secrets	At least one package environment variable has isSecret: true

First observation does not establish that a server was just launched. Remote header authentication does not trigger requires_secrets, which specifically describes package environment variables. Flags describe published metadata, not security assessments or installation recommendations.

Sample output table from the live registry:

name	version	status	signals
ac.inference.sh/mcp	2.0.1	active	new_server, remote_only
com.pulsemcp/remote-filesystem	0.1.5	active	new_server, has_npm, requires_secrets

Abbreviated JSON row:

{
  "name": "com.pulsemcp/remote-filesystem",
  "title": "",
  "version": "0.1.5",
  "isLatest": true,
  "status": "active",
  "repositorySource": "github",
  "namespaceOwnerType": "custom_domain",
  "requiredEnvironmentVariableCount": 1,
  "requiredArgumentCount": 0,
  "signals": ["new_server", "has_npm", "requires_secrets"]
}

Incremental runs and monitoring

Set monitorMode: true and keep monitorKey stable. State is stored in the named key-value store mcp-registry-tracker-state. Monitor mode always requests latest versions, including when latestOnly is false. It emits a server when its version, status, sanitized remotes or normalized packages differ from the baseline. Title, description and timestamp-only edits do not emit rows.

The first scan establishes a baseline. If the row cap or deadline interrupts a scan, the next run resumes from the last completed page. Once pagination finishes, a saved updated_since watermark keeps later requests small. A one minute overlap and fingerprints suppress repeat observations. First observations and rows excluded by onlySignals still establish their applicable baseline. Default active-only filtering hides deprecations and deletions; enable includeDeprecated to monitor these events.

Changing matching filters starts a separate baseline. Changing maxResults or the request delay preserves it. Use a new monitor key to reset a watch. Avoid overlapping runs for one watch: state writes and dataset writes are not a single transaction, so a crash after delivery can cause a duplicate. If named storage is unavailable, the Actor uses memory for that run and reports statePersistence: memory_only; later runs may repeat observations. Purging named local storage resets monitoring.

Pricing

The planned price is $2.00 per 1,000 servers, with one server event per emitted dataset row. The final price is shown on the Store page. Pricing is not configured in this source project. Unchanged and filtered records are not emitted or billed as server rows. Apify platform usage charges may also apply. The Actor checks the spending allowance before requests and batch writes and stops gracefully when the event charge limit is reached.

Scheduling and integrations

Use Apify schedules for periodic watches, webhooks for run notifications, and the Apify API for dataset delivery. Connect results to Make, Zapier or n8n, or use Apify MCP tools to make the dataset available to AI agents. Inspect RUN_SUMMARY for stop reason, counts, scan completion and monitoring persistence health.

https://mcp.apify.com?tools=adastra-connect/mcp-registry-tracker

Is it legal?

This Actor reads an official public JSON endpoint published for programmatic consumption. It uses no login or cookies, identifies itself, respects robots.txt and applies a polite request delay. It sanitizes destination URLs and redacts emails, phone numbers and recognizable person references in titles and descriptions using automated rules. Redaction is best effort; review exports before redistribution. You are responsible for your use of published product metadata.

Limitations

Registry coverage and accuracy depend on publishers. A listing is not endorsement, vulnerability scanning or proof of namespace ownership. GitHub-style and custom-domain owner labels are derived from the name. The Actor does not install packages, test endpoints, enrich stars or fetch release dates. Endpoint path segments are preserved; URLs with credentials, query parameters or fragments lose those parts in output. Fingerprints compare sanitized configurations, so changes only to stripped fields are not reported.

Upstream outages finish successfully with zero rows and RUN_SUMMARY.status: upstream_unavailable when no page could be read. A partial failure keeps completed pages and reports partial_upstream_unavailable. Successful Actor completion alone does not prove a complete scan. Check the summary. Spending caps, time limits and row limits can stop a run early.

FAQ

Can I get all server versions? Set latestOnly: false with monitoring disabled. Rows represent versions, so one server name can appear more than once. Version ordering is textual, not semantic.

Does this return secrets? No published input values are copied. Package inputs expose names and requirement/secrecy flags only. Remote URLs lose credentials, queries and fragments. Remote authentication headers are omitted.

Why did a monitoring run emit zero rows? The watch may be unchanged, filtered, budget-limited or unable to reach the source. Check RUN_SUMMARY for the reason.

Can deleted servers be tracked? Yes. Enable includeDeprecated; the API supports deleted entries and includes them automatically in updated-since queries. Default output remains active-only.

Why are there fewer rows than maxResults? The source may have fewer matches, local filters can exclude records, or collection may have stopped at its time, page or spending limit. maxResults is a cap, not a promised count.

Step-by-step guides

• MCP Server Registry API: How to List New and Updated MCP Servers (2026)

Support

Use the Issues tab on this Actor's Apify Store page with the run ID and a minimal input example. Do not include credentials or private data.

Model Context Protocol and MCP, Apify, GitHub, npm, PyPI, OCI, NuGet, MCPB, Make, Zapier, n8n and Excel are names or trademarks of their respective owners. This Actor is not affiliated with, endorsed or sponsored by the Model Context Protocol project or any other named brand owner.