GitHub MCP Registry Servers Scraper

Search and export GitHub MCP Registry servers from the official public MCP Registry API. Get normalized server identity, publisher namespace, description, version, GitHub repository, package installation, remote endpoint, transport, and lifecycle metadata in an Apify dataset.

Use the Actor for MCP tool discovery, integration evaluation, version inventory, and scheduled ecosystem monitoring. It calls the stable public Registry API directly—no GitHub login, MCP Registry token, browser, or proxy is required.

What does this Actor do?

The Actor supports four practical workflows:

1. Search official registry names by substring.
2. Browse latest server versions with cursor pagination.
3. Retrieve exact servers by their reverse-DNS registry names.
4. Export records changed after an ISO timestamp for incremental monitoring.

Every accepted row is normalized into one stable dataset shape. Package options and remote endpoints remain structured, while compact installationMethods and transportTypes fields make spreadsheet analysis easy.

Who is it for?

• AI platform teams comparing available MCP integrations.
• Developer-relations teams tracking ecosystem adoption and new publishers.
• Security and procurement analysts locating repositories and authentication requirements before deeper review.
• Data teams building a recurring MCP catalog in a warehouse or spreadsheet.
• MCP client developers testing discovery and installation metadata across published servers.

This is a catalog exporter, not an MCP client or security scanner. It does not connect to a listed server or assert that third-party code is safe.

Why use this official registry catalog?

• Uses the official registry.modelcontextprotocol.io v0.1 JSON API.
• Supports both discovery and deterministic exact-name retrieval.
• Reuses opaque upstream pagination cursors correctly.
• Filters for GitHub-linked repositories when needed.
• Omits remote header values and exposes only header names/authentication indicators.
• Charges only records accepted and saved to the dataset.
• Needs only 256 MB of memory and no paid proxy traffic.

What data can you extract?

Field	Meaning
serverName	Official reverse-DNS server identity
title, description	Publisher-provided display metadata
version, isLatest	Published version and latest-version flag
publisher	Namespace before the / in serverName
repositoryUrl	Declared public source repository
repositorySource	Repository host identifier, such as github
repositorySubfolder	Server location inside a monorepo
websiteUrl	Project, documentation, or homepage URL
packages	Package registry, identifier, version, and transport
remotes	Remote URL, transport, and authentication indicator
installationMethods	Compact package and remote connection choices
transportTypes	Distinct stdio, SSE, or streamable HTTP transports
status, statusMessage	Official lifecycle state and explanation
publishedAt, updatedAt	Registry publication/update timestamps
canonicalUrl	Official API URL for the exact server version
scrapedAt	Time the Actor saved the row

The official API currently has no controlled category taxonomy. The Actor does not invent categories from descriptions.

How to get started

1. Open the Actor in Apify Console.
2. Enter a query, exact serverNames, or leave both empty to browse.
3. Choose whether to keep only GitHub-linked repositories.
4. Leave Latest versions only enabled for normal discovery.
5. Set maxItems to the number of accepted rows you need.
6. Click Start.
7. Open the Dataset tab to export JSON, CSV, Excel, XML, or RSS.

The prefilled github search is a low-cost first run and returns real public records.

Input parameters

query

Optional search, up to 200 characters after trimming surrounding whitespace. Omitted, empty, or whitespace-only values browse the catalog. Upstream discovery is name-substring search only; it does not discover description-only or link-only matches. The Actor additionally applies a case-insensitive substring filter across the returned name, title, description, publisher, repository URL, and website URL. It does not scan the full catalog to recover undiscovered text matches. With exact serverNames, only this local text filter applies.

serverNames

Up to 100 exact names, for example:

["io.github.github/github-mcp-server"]

Nonempty exact names override browse/search discovery. Query and repository/lifecycle filters still apply locally; updatedSince is ignored on this route. Exact-name mode avoids catalog pagination. If latestOnly is false, the official versions endpoint returns all versions for each supplied name, bounded by the global maxItems and spending limit.

repositorySource

• all — keep every matching server.
• github — keep only records whose repository source is GitHub.
• other — keep records linked elsewhere or without a GitHub repository declaration.

latestOnly

Defaults to true. Disable it when exact-name version history is the intended output. Large all-version catalog exports can contain several rows per server.

updatedSince

An ISO 8601 date-time with timezone, such as 2026-09-01T00:00:00.000Z. Forwarded upstream in browse/search mode for scheduled incremental exports; ignored in exact-name mode.

includeDeleted

Includes records carrying the official deleted lifecycle status on browse/search, exact latest, and exact all-version routes. When false, deleted rows are also excluded locally. This is most useful with updatedSince in browse/search mode.

maxItems

An integer from 1 to 5,000 (default 100). The global run limit counts saved server-version records after filters and deduplication, not raw upstream responses or records per name. Paging continues through filtered/duplicate rows. A spending limit may stop delivery earlier. Reaching either limit is a bounded snapshot, not proof of catalog exhaustion.

Example inputs

Search GitHub-related integrations:

{
  "query": "github",
  "latestOnly": true,
  "repositorySource": "all",
  "maxItems": 10
}

Retrieve the official GitHub MCP Server:

{
  "serverNames": ["io.github.github/github-mcp-server"],
  "repositorySource": "github",
  "latestOnly": true,
  "maxItems": 5
}

Export recent changes for downstream comparison:

{
  "updatedSince": "2026-09-01T00:00:00.000Z",
  "includeDeleted": true,
  "latestOnly": true,
  "maxItems": 25
}

Output example

A current exact-name run returns a row shaped like this:

{
  "serverName": "io.github.github/github-mcp-server",
  "title": "GitHub",
  "description": "Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.",
  "version": "1.12.0",
  "publisher": "io.github.github",
  "repositoryUrl": "https://github.com/github/github-mcp-server",
  "repositorySource": "github",
  "packages": [{
    "registryType": "oci",
    "identifier": "ghcr.io/github/github-mcp-server:1.12.0",
    "transportType": "stdio"
  }],
  "remotes": [{
    "type": "streamable-http",
    "url": "https://api.githubcopilot.com/mcp/",
    "authenticationRequired": true,
    "headerNames": ["Authorization"]
  }],
  "status": "active",
  "isLatest": true,
  "canonicalUrl": "https://registry.modelcontextprotocol.io/v0.1/servers/io.github.github%2Fgithub-mcp-server/versions/1.12.0"
}

Version numbers and metadata can change whenever publishers update the registry.

How much does it cost to export registry servers?

The Actor uses pay-per-event pricing:

• Start: $0.00005 once per run.
• MCP server record: $0.0009 per accepted record on the BRONZE plan.

At current BRONZE pricing, 10 records cost about $0.00905, 100 records cost about $0.09005, and 1,000 records cost about $0.90005, excluding any plan-specific platform usage arrangements. Higher plans receive the tier displayed in Apify Console. Failed, rejected, duplicate, and empty rows do not incur the per-record event.

These examples will be kept aligned with the applicable live Actor pricing.

Pagination, limits, and retries

The Actor requests up to 100 upstream rows at a time and passes the Registry's opaque nextCursor back unchanged. It keeps paging until maxItems accepted rows are saved or the API is exhausted.

Network errors, HTTP 429, and temporary 500/502/503/504 responses receive up to three total attempts with exponential backoff and jitter. HTTP 429 honors Retry-After, capped at 10 seconds per retry. Stable client errors, malformed JSON, and schema errors are not retried. An exact-name HTTP 404 is explicitly recorded as missing; other operational errors fail the run. Repeated cursors fail explicitly instead of scanning forever.

Records are saved through the SDK charged-persistence path in bounded batches of at most 100 useful records. Remaining budget is checked before source requests and each batch; batches are trimmed to affordability before writing. Failed writes are not charged; billing errors or uncertain writes are fatal and are never blindly retried. Persistence and charging are not atomic: a failed run may retain useful rows with an uncertain charge receipt. Do not treat it as a completed export.

Run completeness (OUTPUT)

The run key-value store contains OUTPUT, linked in the Output tab. It reports route mode, source requests/retries, raw received, accepted, rejected invalid rows, filtered, deduplicated, saved confirmed deliveries, actual persisted dataset count (null if verification is unavailable), confirmed item charged receipts, missingNames, operationalErrors, billing, stopReason, sourceExhausted, and complete.

• source-exhausted, no-match, or all-names-missing with complete: true means the selected route finished normally, subject to upstream scope and filters—not the whole registry when searching or looking up names.
• maxItems or budget means an intentionally bounded snapshot (complete: false); it is not evidence of deletions outside that snapshot.
• Operational, invalid-input/start, or nonadvancing-cursor failures are incomplete. Preserve useful partial rows, but do not advance checkpoints or infer missing records from them.
• billing: local-only identifies local simulation; production receipts are verified or, after an uncertain delivery, uncertain. Start is charged once after valid input and before source work when affordable, even for a legitimate empty export.

Monitoring ecosystem changes

Schedule an Apify Task with updatedSince and save each run's dataset to your data platform. Advance the checkpoint only after success and checking OUTPUT.complete; a bounded snapshot may need a larger result/spending limit. Include deleted records if lifecycle removal matters to your inventory.

The Actor exports snapshots. It does not persist cross-run state, calculate diffs, send alerts, or guarantee that a publisher's external repository remains unchanged. Use Apify schedules and integrations to implement those downstream steps.

Export and integration ideas

• Send new records to Google Sheets for a lightweight catalog.
• Load datasets into BigQuery, Snowflake, or PostgreSQL.
• Trigger a webhook when a scheduled run succeeds.
• Compare serverName, version, status, and updatedAt against the previous checkpoint.
• Feed GitHub-linked repositoryUrl values into a separate repository intelligence workflow.
• Review authenticationRequired before adding endpoints to an approved integration list.

Run with the Apify API

Replace YOUR_TOKEN with an Apify API token.

cURL

curl -X POST \
  "https://api.apify.com/v2/acts/automation-lab~github-mcp-registry-catalog/runs?token=YOUR_TOKEN&waitForFinish=120" \
  -H "Content-Type: application/json" \
  -d '{"query":"github","latestOnly":true,"maxItems":10}'

JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const run = await client.actor('automation-lab/github-mcp-registry-catalog').call({
  query: 'github',
  latestOnly: true,
  maxItems: 10,
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items);

Python

from apify_client import ApifyClient

client = ApifyClient('YOUR_TOKEN')
run = client.actor('automation-lab/github-mcp-registry-catalog').call(run_input={
    'query': 'github',
    'latestOnly': True,
    'maxItems': 10,
})
items = client.dataset(run['defaultDatasetId']).list_items().items
print(items)

Use through MCP

Claude Code

Add this exact Actor through Apify's MCP server:

$claude mcp add --transport http https://mcp.apify.com?tools=automation-lab/github-mcp-registry-catalog

Claude Desktop

Add an HTTP MCP server with the Actor-scoped URL shown below.

Cursor and VS Code

In Cursor or VS Code MCP settings, use the same HTTP server configuration:

{
  "mcp": {
    "servers": {
      "apify-github-mcp-registry": {
        "url": "https://mcp.apify.com?tools=automation-lab/github-mcp-registry-catalog",
        "headers": { "Authorization": "Bearer your-apify-token" }
      }
    }
  }
}

Claude Desktop clients that use the mcpServers key can use:

{
  "mcpServers": {
    "apify-github-mcp-registry": {
      "url": "https://mcp.apify.com?tools=automation-lab/github-mcp-registry-catalog",
      "headers": { "Authorization": "Bearer your-apify-token" }
    }
  }
}

Follow one run to its results

Use scoped tools/list to discover the Actor and helper schemas. The scoped URL also exposes run/data helpers; it is not exactly one tool. Start an authorized invocation once, retain its run/storage IDs, and use get-actor-run for that same run if pending. For example, poll at 2/4/8 seconds capped at 10 with a 120-second total deadline; on timeout report pending rather than starting another run. call-actor waits at most 45 seconds; set the client timeout above its selected wait plus transport margin.

After success, read OUTPUT with the key-value helper and page get-dataset-items using explicit dataset ID, offset, limit, and needed fields from the discovered schema. An example consumer budget is 20 rows/page, at most 100 rows and 64 KiB of serialized UTF-8 results admitted to model context. Enforce bytes host-side before injection, omit/summarize oversize content with disclosure, track source offsets, and report truncation/continuation. If your client cannot intercept oversized results, do not claim a hard byte limit. Keep full exports in storage; these consumer limits do not reduce Actor collection. Discovery/caching behavior is client-dependent; no numeric context-saving claim is made.

Example prompts

• “Search the official MCP Registry for GitHub integrations and return 20 latest records.”
• “Export the latest record for io.github.github/github-mcp-server.”
• “Find registry records updated since 2026-09-01 and include deleted entries.”

Storage and support

Public catalog rows, run input, and OUTPUT are stored in the run's Apify dataset/key-value store under your account retention settings; delete them through Apify when no longer needed. There is no named shared dataset, cross-run cache, or AI/model processing. The official Registry is the only extraction dependency; company-paid compute/storage and existing start/item pricing are unchanged. GitHub/MCP names describe the source and workflow, not endorsement or affiliation. Standard Apify terms apply. For help, open an issue in the Actor's Apify Issues tab and include the run link without credentials.

Diagnostics and privacy

Failed operations send sanitized diagnostic input, exceptions, and Actor/build/run IDs to our private GlitchTip service for repair. Secret fields and URL queries are removed; reports are retained for 30 days. OUTPUT and counters do not contain raw response bodies, header values, or credentials. Linked package, repository, and remote URLs are metadata only; the Actor never fetches or executes them.

Legality

The Actor reads public software catalog metadata. Follow the Registry API's terms and applicable laws. Repository links and remote endpoints are publisher-provided and may lead to third-party services with separate terms.

Do not treat presence in the registry as a security approval. Inspect source, package provenance, requested credentials, endpoint policies, and licenses before installation. The Actor intentionally does not return configured remote header values.

Limitations

• Metadata freshness depends on the official MCP Registry API.
• The registry does not expose a controlled category taxonomy.
• Descriptions, websites, repositories, packages, and endpoints are optional publisher-provided fields.
• Upstream discovery searches names, not descriptions or links; upstream semantics can change.
• Only confirmed exact-name HTTP 404 responses are skipped and listed as missing. Operational failures fail the run; partial rows remain available.
• The Actor does not test server availability, enumerate tools, scan source code, or verify publisher identity.
• repositorySource: github excludes records whose publishers omitted repository metadata even if their description mentions GitHub.

Troubleshooting

Why did my search return fewer rows than maxItems?

The upstream search may contain fewer matching records, or repositorySource and lifecycle filters may reject rows. Try repositorySource: all or a broader query.

Why is an exact server missing?

Check its full reverse-DNS name and Actor logs. Names must contain exactly one /. The record may have been removed or may not satisfy your query/repository filter.

Why did the run fail instead of returning an empty dataset?

A persistent API/network error is operationally different from a valid no-result search. The Actor fails after bounded retries so scheduled workflows do not mistake an outage for an empty registry.

Can I retrieve old versions?

Yes. Supply exact serverNames and set latestOnly to false. Limit the result with maxItems.

Related Automation Lab Actors

• GitHub Scraper for broader repository, issue, and contributor workflows after catalog discovery.
• GitHub Contributors Scraper for public contributor analysis on selected repositories.
• GitHub Trending Scraper for trending repository rankings rather than MCP Registry records.

FAQ

Is this the GitHub website search API?

No. It reads the official MCP Registry API. “GitHub” describes the demanded discovery workflow and the repository links exposed by many records; use repositorySource: github when only GitHub-linked entries are needed.

Does it require a GitHub token?

No. Neither the official public Registry API nor this Actor requires a GitHub login or token.

Does it install or call MCP servers?

No. It exports discovery and setup metadata only.

Are remote endpoints guaranteed to work?

No. Endpoint values are publisher-provided snapshots. Availability and authentication must be evaluated separately.

Can I export CSV or Excel?

Yes. Open the run dataset and select the desired export format, or use the dataset API with format parameters.

Can I monitor new or deleted servers?

Use a scheduled Task with updatedSince and includeDeleted. Store or compare successive datasets in your downstream system.