You can connect Apify to Claude using the Model Context Protocol (MCP), and once it’s connected, Claude can run one of Apify’s scraping and automation actors directly — pull structured data from a website, a social platform, or a maps listing without you writing a scraper or exporting a CSV by hand. This guide covers what Apify’s MCP server does, the part of its setup that looks like OAuth but isn’t quite the one-click flow most servers in this series have, and how to connect it directly or through a gateway.
What the Apify MCP server actually does
Apify publishes a remote MCP server at mcp.apify.com that exposes its catalog of “actors” — thousands of pre-built scrapers and automations covering specific sites and platforms — as tools Claude can call. Instead of you finding the right actor in Apify’s store, configuring its inputs, and copying the output back into the conversation, Claude can pick one, run it, and work with the result directly. Prompts like these are the kind of thing it’s built for:
- “Run a Google Maps scraper for coffee shops in this neighborhood and list the ones with 4.5+ stars.”
- “Pull the last 20 posts from this public social profile and summarize the themes.”
- “Scrape this e-commerce category page and give me prices as a table.”
- “Find an actor that extracts job listings from this site and run it.”
That makes it meaningfully broader than a single-purpose scraping tool like Firecrawl: Apify is a platform of many actors built by many different authors, not one server with a fixed scrape/search tool set. See the Apify server page in gate’s directory for the current tool list and connectivity status.
The part that’s different: OAuth that lands on an API key
Apify’s listing marks its auth as OAuth, but the connect path gate has verified for it resolves through an API key rather than a one-click consent screen — closer to GitHub’s personal-access-token setup than to a server like Notion or Airtable where any client can register itself and send you straight through a standard OAuth prompt. In practice that means you’ll generate an API token from your Apify account settings and supply it when you connect, instead of clicking “Allow” on a consent screen. It’s the same gap covered in MCP OAuth scopes explained: a provider supporting OAuth in principle doesn’t guarantee every client can walk through it the same way today.
Option 1: Connect Apify to Claude directly
The short version of the setup:
- Generate an API token from your Apify account’s integrations settings.
- Open Claude’s connector or MCP settings and add a remote server pointing at
mcp.apify.com. - Supply the token when prompted for credentials.
That’s workable for one person on one client. The tradeoff is the same one every token-based server in this series runs into: a second AI client or a second teammate needs its own copy of that token, and rotating it later means updating it everywhere it was pasted.
Option 2: Connect it once, through a gateway
If you’re already connecting more than one MCP server, or using more than one AI client, wiring each pair in directly gets old fast — the connection sprawl covered in what an MCP gateway is. The idea is to connect Apify (and everything else you use) to one gateway URL, then point every AI client at that single URL instead of reconfiguring each one.
With gate specifically, connecting Apify looks like this: add gate’s gateway URL to Claude once, then pick Apify from the Apify server page in the directory and supply the token there instead of in each client separately. From then on, its actors are available in every client connected to your gate URL, with the same per-tool allow, ask, or block rule applied everywhere instead of set up separately in each one. See the full list on the MCP servers page.
What to check before you run an actor
Running an actor is different from calling a fixed, single-purpose tool, and it’s worth being deliberate about a few things before you let Claude pick one on its own:
- You’re trusting whoever built the actor, not just Apify. Apify hosts a marketplace of actors built by many different, mostly third-party authors. Running one means executing their code against your account and your target data, which is the same supply-chain question we cover in MCP server supply chain risk, just inside a platform rather than on your own machine via
npx. - Scraped output is untrusted content once it comes back. Whatever an actor pulls from a page, a profile, or a listing can contain text written by whoever owns that source, and Claude reads it as part of the conversation — the same pattern behind the confused deputy problem in MCP. Treat scraped content as data to read, not instructions to follow.
- Runs cost money and can run long. Unlike a read-only lookup, an actor run consumes Apify platform credits and can take real time to finish on a large target — worth a glance at an actor’s expected cost and runtime before you let an agent queue one up unsupervised.
- Scope the token narrowly. An API token tied to your Apify account can typically run actors, read your stored datasets, and spend your usage credits — broader than it looks like when you’re pasting it into a settings field. Check what the token you generate is actually scoped to before you hand it to an AI client.
You can run a quick, no-signup check on any server’s tool list with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.
The bottom line
Connecting Apify to Claude with MCP takes a few extra minutes compared to a server with true one-click OAuth, because you’re generating and supplying an API token instead of clicking “Allow.” Do it directly if you’re on one client, or once through a gateway if you want the same token and the same actor catalog available in every AI client you use. Either way, remember an actor run isn’t a fixed, reviewed tool — it’s someone else’s code running against a target you pick, so treat its output as untrusted and its cost as real.