Apify MCP vs the API: setup, costs, and when to use each
Apify's MCP server lets an AI client run Apify Actors as tools. Point the client at https://mcp.apify.com, authorize with OAuth, and the assistant can search the Store, start a run, and read the dataset back inside the conversation. There is no MCP subscription; you pay the same compute and proxy usage you would pay through the API. The trade is throughput. The MCP server is capped at 30 requests per second per user, while the Apify REST API allows 60 per second per resource and 400 per second for starting runs.
Every number on this page was checked against Apify's own documentation and API on 2026-09-09. Where Apify's own pages disagree with each other, this page says so instead of picking a winner.
What does the Apify MCP server actually give an assistant?
The Model Context Protocol is, in its own words, "an open-source standard for connecting AI applications to external systems." The client fetches tool schemas — name, description, parameters — and the model decides when to call one.
Apify's server turns that into two things. First, a fixed set of platform tools: search the Store, fetch an Actor's details, call an Actor, search the docs. Second, any specific Actor you name, which arrives as its own tool with the Actor's input schema attached.
Apify publishes the Store as 70,000+ ready-to-run tools (apify.com/store, read 2026-09-09); the public Store API returns a narrower total of about 57,400, because the two count different things, so treat 70,000+ as the published figure rather than an exact inventory. That is the catalogue behind the search-actors tool. It is not a catalogue you want loaded as 70,000 tool definitions, which is why the server makes you choose.
Should you use MCP or the REST API?
This is the real decision, and most setup guides skip it. Both paths run the same Actors on the same platform and bill identically. What differs is who decides, and how much throughput you get.
Apify MCP (mcp.apify.com) | Apify REST API / SDK | |
|---|---|---|
| Rate limit | 30 requests/second per user, covering every operation: runs, storage reads, docs queries (Apify MCP docs) | 60 requests/second per resource; 400/second for Run Actor and Push items; 250,000 requests/minute globally per user (Apify API docs) |
| Who picks the inputs | The model, from the Actor's input schema | Your code, from a literal you wrote |
| Surface loaded up front | 8 tools marked enabled-by-default in the package README, 6 in Apify's hosted-server docs; 23 in total either way, though the two lists differ | Nothing. You call the endpoints you already know |
| Failure mode | The model mis-specifies an input and you pay for the run anyway | An HTTP 400 you can assert on in a test |
| Auth | OAuth browser flow, or Authorization: Bearer | API token in a header |
| Best for | Exploratory research, one-off extraction, a human reading the output as it lands | Scheduled jobs, CI, retries, anything you need to reproduce next quarter |
Use the API instead of MCP when the job runs unattended. A tool call that picks a slightly different maxItems on Tuesday than it did on Monday is a feature during research and a billing incident in a nightly pipeline. The Apify API tutorial covers the same operations with explicit inputs.
Use MCP when you are still deciding what to scrape. Discovery through search-actors genuinely beats reading the Store by hand, and the assistant reads the dataset for you instead of handing you 4,000 JSON rows.
The 30 req/s cap is per user, not per resource, and it is the ceiling that surprises people. If an agent fans out across a dozen Actors and then polls each run, the MCP path throttles well before the API path would. Agents that need to poll should start runs over MCP and read results over the API, or move to standby Actors so the run is already warm.
How do you connect a client to the hosted server?
- Add
https://mcp.apify.comas a remote MCP server in your client. The Apify CLI writes the config for you:apify mcp install cursor, withclaude-code,vscode,codex,kiro, andantigravityamong the supported targets. - Authorize with OAuth at the browser prompt. Apify documents OAuth as the recommended method, and the reason is practical: your API token never lands in a config file you might commit. Clients that cannot do OAuth send
Authorization: Bearer <APIFY_TOKEN>instead; grab the token from Console → Integrations. - Name your tools in the URL:
https://mcp.apify.com?tools=actors,docs,apify/rag-web-browser. You can mix categories, individual tool names, and Actor IDs in the same list. - Run one small job and watch it in the Console before you let the assistant loose on a crawl.
The endpoint uses Streamable HTTP. SSE was removed on 1 April 2026, so a client config written before then fails with an unhelpful transport error rather than a clear message.
Quick reachability check, no token needed: curl -s -o /dev/null -w "%{http_code}" https://mcp.apify.com/ returned 401 on 2026-09-09. A 401 means the endpoint is up and your network can reach it. A timeout means it cannot.
Apify's integrations page lists 22 coding agents and IDEs, Cursor, VS Code, Claude Code, Codex, Windsurf, Zed, JetBrains and GitHub Copilot among them, plus Claude Desktop, ChatGPT and Perplexity under LLMs (counted 2026-09-09). If you want the Claude Desktop walkthrough specifically, our Apify MCP with Claude Desktop guide has the screenshots.
How do you run the MCP server locally?
Run the npm package over stdio when the process has to live on your machine or inside your network:
APIFY_TOKEN=your_token npx -y @apify/actors-mcp-server --tools apify/rag-web-browser
The flag is --tools. Apify's current documentation shows only --tools, in examples such as --tools actors,docs,apify/web-scraper.
If you have an old config lying around, it will still start. Reading the published package (v0.15.5, released 2026-09-09), --actors is still parsed and its values are merged into tools for backward compatibility. It is undocumented rather than broken. Move to --tools anyway, because the merge is the only thing keeping it alive.
Two selectors that used to work now resolve to nothing at all: the add-actor tool, and the preview and experimental pseudo-categories. They do not error. They load no tools, which looks identical to a client that failed to connect.
Which tools load, and what does each category cost you?
Every tool definition you enable is serialized into the model's context on every turn, so this is a real budget, not a preference. The npm package v0.15.5 groups tools into six categories:
| Category | Tools | What it contains |
|---|---|---|
actors | 3 | search-actors, fetch-actor-details, call-actor |
docs | 2 | search-apify-docs, fetch-apify-docs |
runs | 4 | get-actor-run, get-actor-run-list, get-actor-log, abort-actor-run |
storage | 8 | dataset and key-value store reads, listing, and schema |
tasks | 5 | create, get, update, publish, unpublish Actor tasks |
dev | 1 | report-problem |
The default configuration is four entries — the actors and docs categories plus two Actors, apify/rag-web-browser and apify/web-fetch — and the package README marks 8 tools as enabled by default (one of them, report-problem, only when telemetry is on). Enabling everything is 23. That is the npm package. The hosted server ships a different default: Apify's MCP docs mark six tools as enabled by default — search-actors, fetch-actor-details, search-apify-docs, fetch-apify-docs, the apify/rag-web-browser Actor, and get-actor-output — and do not mark call-actor. Both lists come to 23 tools in total, but they are not the same 23: the docs table omits abort-actor-run and the dev category and adds the two above. Read on 2026-09-09. As with the concurrency numbers, we are not picking a side; we cannot see what the hosted server actually loads. storage alone is eight definitions, and most conversations use one of them.
The practical rule: add runs when the assistant needs to wait for or abort a job, add storage when it needs to read a dataset it did not just create, and leave tasks off unless you are managing saved tasks from chat. Naming a specific Actor, such as apify/rag-web-browser or apify/web-fetch, adds one tool each and keeps the model from guessing at the Store.
What does Apify MCP cost?
There is no MCP line item. You pay platform usage, the same as an API call would cost.
- The free plan includes $5/month subject to change · verified 2026-09-09 of usage credit, enough for real testing but not for an agent left running. See our Apify free plan breakdown.
- Starter is $19/month subject to change · verified 2026-09-09, or $17/month billed annually, with compute at $0.20 per compute unit on both Free and Starter. Full arithmetic in our Apify pricing guide.
- Actors with their own rental or per-result price bill on top of compute, whether the run started from a chat window or from
curl.
One conflict worth knowing about. Apify's own pages disagree on how many Actor runs a free account may run at once. apify.com/pricing says 5 concurrent runs on the free plan; docs.apify.com/platform/limits says 25. Both read on 2026-09-09. We have not picked a side, because we cannot verify which one the billing system enforces. Assume 5 when you design an agent that fans out tool calls in parallel — if the real limit is 25, you lose nothing, and if it is 5 you avoid a queue you did not plan for.
What changed, and when
| Date | Change | Where to check |
|---|---|---|
| 1 Apr 2026 | SSE transport removed; Streamable HTTP only | Apify MCP docs |
| 26 Jun 2026 | x402 pay-per-request settlement added across both the MCP server and the API | Apify changelog |
| by Sep 2026 | apify.com/apify/actors-mcp-server no longer serves a Store page. It 308-redirects to mcp.apify.com, and the API returns 404 for that Actor ID. The npm package still exists; only the Store listing is gone | Checked 2026-09-09 |
| v0.15.5 | --tools documented, --actors undocumented but still parsed; add-actor, preview, and experimental retired | @apify/actors-mcp-server on npm |
If you followed a tutorial written before April 2026, the SSE line and the actors-mcp-server Store link in it are both dead.
Open Apify, create a token, then add https://mcp.apify.com?tools=actors,docs,apify/rag-web-browser to your client. Start with the defaults: actors, docs, apify/rag-web-browser, and apify/web-fetch. Add runs and storage only once you hit something the assistant cannot do.
Worried about a runaway agent burning credit? Set an account spend limit in the Console before you connect anything, and keep the tool list short. A model that cannot see call-actor cannot start a run.
There is no separate MCP fee. You pay normal platform usage for whatever the assistant runs. The free plan includes $5 of monthly usage credit (apify.com/pricing, checked 2026-09-09), which covers testing but not a continuously running agent.
https://mcp.apify.com, over Streamable HTTP. Add a tools query string to pick what loads, for example https://mcp.apify.com?tools=actors,docs,apify/rag-web-browser. The SSE transport was removed on 1 April 2026.
Because it no longer exists. apify.com/apify/actors-mcp-server 308-redirects to mcp.apify.com, and api.apify.com returns 404 for that Actor ID (checked 2026-09-09). The npm package @apify/actors-mcp-server is unaffected and is still the local server.
It still parses in v0.15.5, where its values are merged into the tools list for backward compatibility, but Apify's documentation only shows --tools. Use --tools.
It depends which source you read. The package README (v0.15.5) says that with no tools parameter the server loads actors, docs, apify/rag-web-browser, and apify/web-fetch, and marks 8 tools as enabled by default. Apify's hosted-server docs mark six as enabled by default, swapping call-actor for the apify/rag-web-browser Actor and get-actor-output (both read 2026-09-09). Either way the full set is 23 tools, and every definition is sent to the model on each turn, so add runs and storage only when a task actually needs them.
For anything unattended: scheduled jobs, CI, ETL, or work with an SLA. The API gives you literal inputs, assertable errors, and a much higher rate ceiling (60 req/s per resource, 400 for starting runs) than the MCP server's 30 req/s per user.
The protocol does not weaken anything by itself; your token and tool list do. Prefer OAuth so the token never lands in a config file, enable only the Actors you need, and set a spend limit. A tool the model cannot see is a tool it cannot misuse.
Yes. Name any Actor you can run in the tools list and it loads with its input schema, private ones included, subject to the permissions of the token or OAuth grant behind the connection.