Apify MCP Server: Wiring Thousands of Scrapers Into an MCP Client
The Apify MCP server enables your AI agents to extract data from social media, search engines, maps, e-commerce sites, or any other website using thousands of ready-made scrapers, crawlers, and automation tools available on the Apify Store.
At a glance
- What is it?
- The Apify MCP server exposes Apify Store Actors as tools an AI agent can call over the Model Context Protocol. It is a thin bridge, not a scraper: the value and the cost both live in the Actors behind it.
- Who is it for?
- Adopt it if your agent already needs to pull structured data from sites you do not want to maintain scrapers for, and you are willing to run each call as a paid Apify Actor. Skip it if you need a self-contained scraper, offline operation, or a fixed, auditable tool list.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: agents that need live web data
An agent with only a shell and an HTTP client can fetch a page, but it cannot reliably render JavaScript, rotate proxies, or survive an anti-bot challenge. The Apify MCP server takes that problem and hands it to Apify Store, where the README says thousands of ready-made scrapers, crawlers, and automation tools already exist. The server itself does not scrape anything. It translates between the Model Context Protocol and the Apify platform, so a client such as Claude Desktop, Cursor, or VS Code can call an Actor as if it were a local function.
The intended audience is narrow and specific. It is for teams already building on MCP clients who want web extraction without writing and maintaining per-site scrapers. The README's own examples name Facebook Posts Scraper, Google Maps Email Extractor, Google Search Results Scraper, Instagram Scraper, RAG Web Browser, and Web Fetch. That list tells you what the project assumes: you have an Apify account, you accept that extraction runs on Apify infrastructure, and you want the agent to choose among tools rather than call one hardcoded endpoint.
How the Actor-as-tool mechanism actually works
The architecture is a relay. Your MCP client speaks the protocol to the server, the server maps a tool call onto an Apify Actor run, and the Actor returns a dataset or key-value output that the server passes back. The README describes the server as letting an AI assistant use any Apify Actor as a tool to perform a specific task, which means tool discovery is dynamic rather than a fixed catalog compiled into the binary.
That dynamic discovery is the design decision worth noticing. A conventional MCP server ships a stable list of tools, and the model sees the same schema every session. Here the tool surface depends on which Actors are available and, per the README, on the client's own capabilities, since support for dynamic tool discovery varies between clients. The README notes that the server uses mcp-client-capabilities to detect client capabilities and adjust behavior, though that line is commented out in the supplied text, so treat capability adaptation as documented intent rather than a confirmed runtime path.
The hosted server adds one thing the local stdio mode does not. The README states that output schema inference for structured Actor results is available on mcp.apify.com and not when running locally via stdio. If your agent needs to reason over typed fields rather than raw JSON blobs, that difference matters more than transport convenience.
Getting it running: hosted URL or npx
There are two supported paths. The hosted endpoint is https://mcp.apify.com over streamable transport, and the README recommends it for most use cases. Because it supports OAuth, clients like Claude.ai or Visual Studio Code can connect with just the URL. Alternatively you send an Authorization: Bearer <APIFY_TOKEN> header.
The local path is stdio, aimed at command-line tools and the Claude for Desktop client. You set the client's server command to npx @apify/actors-mcp-server and supply the APIFY_TOKEN environment variable with your Apify API token. The README points to npx @apify/actors-mcp-server --help for additional options, so the flag surface is discoverable from the binary rather than enumerated in the README.
One migration note is stated bluntly: the legacy SSE transport is removed. The https://mcp.apify.com/sse endpoint no longer exists, and existing configurations should drop the /sse suffix. If you have an older client config pointing at that path, it will fail until you edit it. The README also mentions agentic payments, including buying a token from AGI, paying per request via direct x402 for Pay Per Event Actors only, and Skyfire, but it does not document the configuration keys for those flows in the supplied text.
Where it breaks down or is the wrong choice
The most concrete limitation is stated by the project itself: structured output schema inference is not available over local stdio. Running the server locally is the lighter setup, but it is also the reduced-capability mode. If your agent depends on typed Actor results, stdio is the wrong transport.
The second limitation is the dependency chain. Every tool call is an Apify Actor run on Apify infrastructure, billed and rate-limited by your account. The server is MIT-licensed, but the license covers the bridge, not the Actors it invokes, and the README's payment section implies that some Actors require a purchased token or per-request payment. An agent that decides to call a scraper in a loop can spend money without a human in the loop.
Third, capability variance across clients is acknowledged rather than solved. The README says support for dynamic tool discovery and other features may vary between clients. A client with weak discovery support may see a different, smaller tool surface than another, which makes behavior hard to reproduce across a team. If you need a fixed, auditable set of tools with deterministic schemas, a hand-written MCP server wrapping one or two endpoints is a better fit.
The alternative: a hand-rolled MCP server over your own fetch layer
The closest alternative is writing your own MCP server that wraps a small set of HTTP endpoints or a self-hosted crawler. The difference is where the work lives. With Apify MCP Server, you inherit thousands of maintained Actors but you also inherit Apify's runtime, billing, and account model, and the tool list is discovered at runtime. With a hand-rolled server, you own the extraction code, the schemas are fixed and versioned in your repository, and nothing leaves your infrastructure. You also own every anti-bot regression and every site redesign.
A second alternative is calling the Apify API directly from your agent's code instead of through MCP. You get the same Actors and the same billing, but you skip the protocol layer and its client-compatibility variance. The tradeoff is that you lose the drop-in integration with MCP clients, which is the entire reason this project exists. The choice is between a managed, broad, dynamic tool surface and a narrow, static, self-owned one.
Maintenance, versioning, and licence implications
The repository is TypeScript, MIT-licensed, and not archived. Recent releases in the supplied material are v0.15.6, v0.15.5, and v0.15.4, dated September 2026, with a cadence of roughly weekly patches. A 0.x version line means the maintainers have not declared API stability, and the removal of the /sse endpoint is a concrete example of a breaking change landing in that line. Pin the version you run and read release notes before upgrading, because a transport change can silently break every client config in your team.
Upgrade cost is mostly configuration, not code, if you use the hosted endpoint: the server updates on Apify's side and your client keeps pointing at https://mcp.apify.com. If you run stdio via npx, you are pulling whatever version npx resolves unless you pin it, so an unpinned setup can change behavior between sessions. The MIT licence covers this server's source. It does not cover Apify Store Actors, which are separate workspaces with their own terms, and it says nothing about how the hosted service handles your data. The README links a privacy policy section but the supplied text does not include its contents, so read that page before sending sensitive URLs through the hosted server.
Who should adopt it, and what to check first
Adopt it if your agent already lives in an MCP client, you need extraction from sites you have no intention of maintaining scrapers for, and you are comfortable with calls running as paid Apify Actors. The hosted endpoint is the version to start with, both because the README recommends it and because it is the only path with output schema inference for structured results.
Do not adopt it if you need offline operation, a fixed and auditable tool list, or extraction that never leaves your own infrastructure. Do not adopt it as a general-purpose scraper library either; it is a protocol bridge, and the scraping is somebody else's Actor.
What to verify first: confirm your client supports streamable HTTP and drop any /sse suffix, decide between the hosted URL and npx @apify/actors-mcp-server with APIFY_TOKEN, and check how your Apify account is billed for the Actors your agent picks. The README's agentic payments section lists AGI, direct x402 for Pay Per Event Actors, and Skyfire, but does not spell out the config keys, so that is the gap to close before you let an agent spend.
Editorial conclusion
Adopt it if your agent already needs to pull structured data from sites you do not want to maintain scrapers for, and you are willing to run each call as a paid Apify Actor. Skip it if you need a self-contained scraper, offline operation, or a fixed, auditable tool list. Before wiring it in, verify which transport your client supports (the /sse endpoint is gone), whether the hosted server at mcp.apify.com is acceptable for your data, and how your Apify account will be billed for the Actors your agent decides to invoke.
Community notes