One connector for a very large tool catalog
Apify MCP Server turns Apify Actors into tools that an AI client can discover and call. Actors are hosted scraping, crawling, extraction, and automation jobs. Instead of giving a model one fixed browser command, the server can search the Apify Store, inspect an Actor's documentation and input schema, run it, then retrieve results from the associated dataset or key-value store. The same connection can cover a Google Maps lead search, social-media extraction, web research, or a custom Actor owned by your team.
That breadth is the main advantage over a single-purpose crawler MCP server. The model can find a specialist Actor and receive a generated tool schema rather than forcing every website into one generic scraping API. Helper tools also expose run status, logs, storage, and Apify documentation. Calls return run metadata and a suggested next step instead of dumping an entire dataset into the first response, which is a sensible design for keeping model context under control.
The downside is that the server inherits the marketplace's complexity. Actors have different owners, prices, quality, inputs, runtimes, and output shapes. Dynamic discovery is convenient, but a production agent should not be free to select any paid Actor based only on a search result. Review the Actor, pin its identifier, inspect pricing, and test output before granting it to an unattended workflow.
Hosted setup is the version to beat
For most users, installation is little more than adding https://mcp.apify.com to a compatible client and completing OAuth. The project lists tested support for Claude Desktop, Claude on the web, ChatGPT, Cursor, VS Code, OpenCode, Kiro, and Apify's tester. Bearer-token authentication works when OAuth is not appropriate. Streamable HTTP is the current transport; the old /sse endpoint has been removed.
The hosted server is also the favored product. It has output schema inference for structured Actor results and can dynamically access rental Actors, features the README says local stdio does not match. Stdio remains useful for desktop and command-line clients: run the npm package with an Apify token in the environment. Current release 0.14.3 raises the Node.js floor to 22. This is local protocol plumbing, not local execution. Requests and Actor inputs still go to the Apify API, and scraping runs on Apify infrastructure.
Tool selection is a security and cost control
The default configuration exposes Actor discovery and calling, Apify documentation, and the RAG Web Browser Actor. Several run and storage tools are injected when Actor execution is present. This is practical for exploration, yet too broad for many deployed agents. call-actor can reach external resources, start paid work, and produce data that must be fetched in later calls. Tool annotations advertise read-only and open-world behavior, but clients and models do not all enforce annotations the same way.
Apify recommends specifying tools explicitly because the default set may change. Follow that advice. A research assistant that only needs one approved crawler should receive that Actor and the minimum result tools, not store-wide discovery. Explicit selection also prevents a future default from changing the agent's interface without an application release.
Costs need similar boundaries. Actor pricing varies. Normal Apify accounts use tokens and platform billing, while agentic payment options can fund prepaid balances through AGI, direct x402, or Skyfire. Those methods are interesting for autonomous software, but introduce wallets, payment tokens, refund rules, and minimum funding. Most teams should start with an ordinary spend-capped Apify token and monitor runs before handing payment decisions to an agent.
Long runs and large outputs need engineering
Short jobs fit the conversational tool model well. Long Actors expose a protocol mismatch. An open issue describes 20-to-60-minute runs that cannot remain inside one tool call because several clients impose a roughly 60-second ceiling and the server caps waiting at 45 seconds. The documented legacy task path can lose result retrieval when a quiet run outlives its task record. Work is deferred until the server supports the newer MCP Tasks extension. For now, test polling and retention with the exact client, or trigger long work outside chat and collect it later through run and storage tools.
Storage retrieval has another concrete edge. One open bug says get-key-value-store-record downloads a whole record before deciding whether it is small enough to return inline. A multi-gigabyte value can therefore exhaust server memory even though the eventual response should be a link. Avoid using that tool for unknown or unbounded binary records until the fetch is capped. Dataset pagination is safer than asking an assistant to pull an entire large result set.
Schema adaptation can also lose detail. The README says field descriptions and combined enum text are truncated for client compatibility, and special handling repairs schemas that some clients interpret poorly. This tradeoff is reasonable, but complex Actor inputs should be validated against the Actor's own documentation rather than trusting the model-visible schema alone.
Strong documentation, fast protocol movement
The repository was pushed on August 13, 2026, one day after release 0.14.3. Issues and pull requests are updated throughout the day, and the open count of 125 combines both. Recent work covers newer MCP transports, structured output, client behavior, payments, tests, and storage. This is healthy activity, but the pre-1.0 version and rapid protocol work explain why transport, capability, and task behavior continues to shift.
Documentation is excellent. It states hosted and local differences, enumerates tools, explains output retrieval, warns about changing defaults, documents telemetry opt-out, and names schema limits. Telemetry is enabled by default, with Sentry added for stdio errors; both can be disabled together. Code contributions are generally limited to maintainer-invited issues, though bug reports and documentation fixes are welcomed.
Apify MCP Server is an easy recommendation for an Apify customer who wants controlled assistant access to known Actors. It is less convincing as an unrestricted marketplace gateway. Pin tools, cap spend, disable telemetry when policy requires it, and test slow and large runs before trusting an autonomous workflow.