Thousands of Actors become callable tools
Apify MCP Server lets an AI client discover and run Apify Actors. Actors are hosted jobs for scraping, crawling, extraction, and other automation. The server can search Apify Store, inspect an Actor's input schema, start it, then retrieve results from its dataset or key-value store. One connection can cover web research, map leads, social posts, ecommerce pages, or a custom Actor owned by the user's team.
That range is the advantage over a single crawler server. A model can find a specialist Actor and receive a generated tool schema instead of forcing every site through one generic scraper. Helper tools expose run status, logs, storage, and Apify documentation. Calls return run metadata and a suggested next action rather than placing a whole dataset in the first model response.
Actors have different owners, prices, inputs, runtimes, and output shapes. Dynamic discovery is convenient during exploration, but an unattended agent should not select any paid Actor based on a store search. Review the Actor, pin its identifier, check pricing and data handling, and test its output before exposing it to a production workflow.
What happened when we ran it
Our run at commit 91ee491 installed 788 pnpm packages in 43 seconds and used 707 MB on disk. The build succeeded in 23 seconds, and the supplied tests passed in 43 seconds. Nothing in those steps reported an install, compiler, or test failure. The unprivileged Debian container had 3 CPUs, 8 GB of RAM, Node.js 22, and no secrets.
The 3.4 MB checkout contained 374 files and about 49,608 lines of source. Our scan found a workspace monorepo, 14 CI workflow files, a Dockerfile, and a tests directory. Those are reassuring repository controls. The run did not authenticate with Apify, execute a paid Actor, assess scraped data, or measure a long remote job, so the passing 109 seconds of install, build, and tests should not be read as an end-to-end service benchmark.
Hosted OAuth is easier than local stdio
The recommended path is to add https://mcp.apify.com to a compatible client and complete OAuth. The README lists Claude Desktop, Claude on the web, ChatGPT, Cursor, VS Code, OpenCode, Kiro, and Apify's tester. Bearer tokens work when OAuth is unsuitable. Streamable HTTP is current; the former /sse endpoint has been removed.
Hosted service also gets output-schema inference and access to rental Actors that local stdio does not fully match. Stdio requires Node.js 22, npx @apify/actors-mcp-server, and an APIFY_TOKEN environment variable. It only moves the protocol process onto the user's machine. Requests and Actor inputs still reach the Apify API, and the jobs still execute on Apify infrastructure.
That distinction rules the project out for offline work or policies that prohibit sending target URLs and input data to a third party. Telemetry is enabled by default, and stdio uses Sentry for errors; the README documents how to disable both. Teams should decide that setting before rollout rather than inherit a developer default.
An explicit tool list limits cost and exposure
The default set includes Actor discovery and calling, Apify documentation, and 2 configured Actors, with run and storage helpers injected when execution is present. call-actor can contact external resources, start paid work, and create data that later calls must retrieve. Tool annotations describe behavior, but clients and models do not enforce every annotation identically.
Apify warns that defaults may change and recommends an explicit tools list. A research assistant that needs one approved crawler should receive that Actor plus the minimum result tools, not unrestricted store discovery. Pricing varies by Actor. AGI, direct x402, and Skyfire provide agentic payment routes, but they add balances, wallets, tokens, refund terms, or provider accounts. An ordinary spend-capped Apify token is easier to govern for an initial deployment.
Runs lasting 20 to 60 minutes do not fit every client
Open issue 1119 describes Actors that run for 20 to 60 minutes while several clients impose a roughly 60-second tool-call ceiling. The server caps waiting at 45 seconds. A quiet legacy task can outlive its stored task record, leaving the completed Actor run without retrievable task results. The issue is deferred until the server adopts the MCP Tasks extension, so users should test polling and retention with their exact client or collect long jobs outside chat.
Open issue 1067 documents a separate memory risk. get-key-value-store-record can fetch an entire value before applying its 256 KB inline decision. The report says a multi-GB record could exhaust server memory. Avoid that tool for unbounded binary values until retrieval is capped, and prefer paginated datasets for large results. These are specific reasons to walk away if jobs are routinely long or outputs are uncontrolled.
A same-day release shows active protocol work
GitHub showed 5,055 stars, 142 combined issues and pull requests, and a last push on August 26, 2026. Release v0.15.3 was published the same day with a structured-output schema fix. Issue 1121, previously about output schemas converting poorly to TypeScript, also closed on August 26. The activity is current, though a pre-1.0 server moving with MCP clients still needs version pinning and regression tests.
The README covers hosted and local differences, tool selection, output retrieval, payment, privacy, telemetry, and schema limits in unusual detail. Code contributions are generally restricted to maintainer-invited work, while bug reports and documentation fixes are welcomed. Apify customers get the clearest value: one tested connection to known Actors. Everyone else should compare the 707 MB local dependency footprint and marketplace governance work with a smaller crawler or direct browser tool.