mcp.apify.com Explained: An Operator's Take After 106 MCPs

The problem: Apify shipped mcp.apify.com and updated the configurator on April 23rd, 2026. The changelog reads like a small UX polish — "improved MCP configurator". It's not. It's a quietly important piece of infrastructure that changes how AI agents reach Apify's 6,000+ actors.

I run 106 MCP servers and 325 actors on Apify Store under ryanclinton. When mcp.apify.com landed, I had to figure out fast whether it cannibalised the dedicated MCPs I'd shipped. The honest answer is below.

What is mcp.apify.com? A single hosted MCP endpoint, run by Apify, that lets any MCP client dynamically discover and call any actor in the Apify Store mid-conversation. One URL, one config block, dynamic Actor discovery via a built-in search-actors tool.

Why it matters: Before mcp.apify.com, every Apify actor an agent could reach had to be wired into the client's MCP config up front. With mcp.apify.com, the agent searches the Store at runtime and adds the actor as a tool on demand. That collapses 50+ separate MCP entries into one.

Use it when: You don't know which Apify actor you'll need before the conversation starts. Skip it when you've already picked the actor (use direct standby) or when you need composite multi-actor orchestration with scoring (use a dedicated composite MCP).

Quick answer

• What it is: https://mcp.apify.com is Apify's hosted MCP server. One URL, OAuth or Bearer auth, dynamic Actor search built in.
• When to use: Open-ended agent tasks where the actor isn't pre-selected. The agent picks from 6,000+ Store actors at runtime.
• When NOT to use: When you've already chosen the actor (direct standby is cleaner) or when you need composite scoring across multiple actors (dedicated MCPs handle that).
• Typical steps: Add one block to your MCP client config → authenticate → ask the agent a question → it searches the Store and runs the actor.
• Main tradeoff: Generic Run-Actor dispatch has no per-actor orchestration logic. It runs one actor, returns the dataset. That's it.

In this article: The 1-line definition · How it works · What it replaces · What it adds · Operator perspective · How to connect · Pricing · When to use what · FAQ

Key takeaways

• One URL replaces N config entries. Before mcp.apify.com, an agent that needed 50 actors needed 50 MCP server blocks. Now it needs one.
• Dynamic discovery is the headline mechanic. The bridge ships with a built-in search-actors tool. The agent searches Apify Store mid-conversation and adds actors on demand.
• Bearer or OAuth. Two auth modes per the official docs. OAuth is the recommended path; Bearer works for non-interactive setups.
• Pricing inherits the actor. The bridge is free. You pay the underlying actor's PPE rate when it runs. If the actor is $0.05 per call, that's what you pay — same as calling it directly.
• It does NOT replace dedicated composite MCPs. Generic Run-Actor dispatch has no scoring, no cross-actor synthesis, no orchestration. That's still the composite MCP server job, and across the 106 MCPs we've shipped, the composite ones are the ones that earn.

Problems this solves:

• How to give an AI agent access to all Apify Store actors with one config block
• How to let an agent discover Apify actors mid-conversation instead of pre-wiring them
• How to wire Claude Desktop or Cursor to Apify without per-actor MCP configs
• How to add new actors to an agent without restarting the MCP client
• How to authenticate an MCP client to Apify with OAuth instead of static tokens
• How to test an Apify actor through MCP without running its standby endpoint directly

Hosted bridge vs direct standby vs composite MCP — the three modes

Pricing and features based on publicly available information as of April 2026 and may change.

What is mcp.apify.com?

Definition (short version): mcp.apify.com is Apify's hosted Model Context Protocol server — a single HTTPS endpoint that lets MCP-compatible AI clients (Claude Desktop, Cursor, Claude Code, ChatGPT, VS Code) dynamically discover and call any of Apify's 6,000+ Store actors over one connection.

The longer version: it's a bridge. The MCP client speaks Model Context Protocol — typed tools, structured input, structured output. Apify exposes 6,000+ actors and a search index. mcp.apify.com sits in the middle, exposing a small set of built-in tools (search Store, fetch actor details, call an actor, fetch docs) and translating client requests into actor runs.

There are three ways an MCP client can reach Apify actors today: (1) the hosted bridge at mcp.apify.com — one URL, generic dispatcher, dynamic discovery; (2) direct actor standby — each actor in standby mode has its own URL; (3) a dedicated composite MCP server that wraps multiple actors with domain logic — the 106 MCP intelligence servers on ryanclinton live in this third category.

Also known as: Apify hosted MCP, Apify MCP bridge, mcp.apify.com bridge, Apify MCP gateway, Apify Store MCP.

Why does mcp.apify.com matter for AI agents?

Before mcp.apify.com matured into a configurator-driven setup, wiring an agent into Apify was a chore. Each actor needed its own MCP server block — endpoint, auth header, identifier. A claude_desktop_config.json with 50 actor entries is real, and painful to maintain.

mcp.apify.com collapses that to one block. The friction drop matters because agents rarely know in advance which actor they'll need — that decision happens mid-conversation, when the user asks the question.

Anthropic released the Model Context Protocol in November 2024. By April 2026, MCP-compatible clients include Claude Desktop, Claude.ai, Claude Code, Cursor, Codex, ChatGPT, VS Code, and Antigravity (per the Apify changelog entry from April 23, 2026). Agent infrastructure has shifted from "wire one tool" to "wire a marketplace."

How does mcp.apify.com actually work?

When an MCP client connects to mcp.apify.com, the server advertises a small set of always-on tools: search-actors, fetch-actor-details, apify/rag-web-browser, search-apify-docs, and fetch-apify-docs. That's the default surface.

When the user asks the agent a question — "find me lead scores for these 50 domains" — the agent calls search-actors, picks a relevant actor, calls fetch-actor-details for its input schema, then either invokes it through call-actor or registers it as a new tool via add-actor on clients that support dynamic discovery. The Apify docs describe this flow as: "search Apify Store for relevant Actors using the search-actors tool, inspect Actor details, add the Actor as a new tool, and execute it with appropriate parameters."

Two transport details. First, mcp.apify.com uses Streamable HTTP, not the legacy Server-Sent Events transport — Apify deprecated SSE on April 1st, 2026. Second, the hosted bridge supports output schema inference (field-level type information); the local stdio version of the open-source Apify MCP doesn't.

What does mcp.apify.com replace for MCP clients?

Before the hosted bridge, an MCP client config that needed access to a dozen Apify actors had a dozen entries — each with its own URL, headers, and name. Adding a new actor meant editing config and restarting the client. Updating tokens meant touching every block.

mcp.apify.com replaces all of that with one entry. The agent searches the Store at runtime, fetches actor details on demand, and either calls them generically or registers them as new tools. The config stays at one block regardless of how many actors you end up using.

That's a real distribution shift for actor authors. Pre-bridge, an actor was reachable only if a client had explicitly wired it. Post-bridge, every actor in the Apify Store is passively reachable through one URL — and the agent decides which one to run based on the user's question and the actor's description.

What does mcp.apify.com add that was not there before?

Two things: dynamic discovery and a managed configurator.

Dynamic discovery means the agent can search the Store mid-conversation, pick a candidate, fetch its schema, and run it — all without the human editing config or restarting the client. That's not possible with per-actor MCP installs, where the tool surface is fixed at startup.

The configurator is the UI at mcp.apify.com itself. The April 23rd, 2026 changelog entry "Deploy agents faster with an improved MCP configurator" describes a refreshed setup flow supporting Claude Desktop, Claude.ai, Claude Code, Antigravity, Cursor, ChatGPT, Codex, and VS Code in a unified interface. It writes the right config snippet for whichever client you target.

Operator perspective: after 106 MCPs on the platform

I've shipped 106 dedicated MCP servers and 325 actors on Apify under ryanclinton. The question I had to answer fast was: does the bridge cannibalise the dedicated MCPs? Honest answer: no.

mcp.apify.com's call-actor is a generic dispatcher. It runs one actor and returns one dataset. It doesn't know that Counterparty Due Diligence MCP hits 11 sub-actors in parallel, dedupes, and scores against a KYB risk model. It doesn't know M&A Target Intelligence MCP runs 16 sub-actors and computes an Acquisition Readiness Score with deal-breaker flags. That orchestration is hard-coded inside each composite MCP — the bridge can't replicate it.

What the bridge does change for actor authors is distribution. Every actor in the fleet is now passively reachable. An agent looking for "supplier risk" or "pre-acquisition intelligence" can land on one of my actors via search-actors without knowing the URL. That's a passive discovery channel that didn't exist before — the second-order effect the launch post doesn't dwell on.

One real operator caution: we saw our first MCP customer attempt across the whole fleet on April 29th, 2026 — one user, 167-second session on cybersecurity-intelligence-mcp, aborted with zero successful tool calls. Sample size of one, but MCP customer expectations are sharp: if the first tool call returns nothing useful, the session ends. The bridge surfaces actors to agents that haven't been human-tested first. Discovery win and quality-control problem at the same time.

How do you connect Claude Desktop to mcp.apify.com?

Per the official Apify MCP integration docs, Claude Desktop and other MCP clients connect to mcp.apify.com using one of two auth modes.

The recommended path uses OAuth — the client authenticates against Apify directly and the connection is brokered without you pasting tokens around. The Bearer-token path is for non-interactive setups and looks like this in claude_desktop_config.json:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com",
      "headers": {
        "Authorization": "Bearer <APIFY_TOKEN>"
      }
    }
  }
}

Replace <APIFY_TOKEN> with a token from Apify Console → Account → Integrations. Restart Claude Desktop. The Apify entry should appear in the tools panel with the default toolset (search-actors, fetch-actor-details, apify/rag-web-browser, plus the docs tools) immediately available.

For Cursor, ChatGPT desktop, Claude Code, VS Code, and the other supported clients, the mcp.apify.com configurator generates the right snippet for each. Pick your client, copy, paste.

How much does mcp.apify.com cost?

The bridge itself is free. You pay the underlying actor's pricing when an actor runs through the bridge. If an actor charges $0.05 per result via Apify's pay-per-event pricing model, running it through mcp.apify.com costs $0.05 per result — same as if you'd called the actor directly.

That includes the full PPE-priced fleet on Apify Store. The bridge does not add a markup, and there is no per-call surcharge documented in the integration docs as of April 2026. Compute time, dataset storage, and proxy traffic all bill against the actor's normal pricing model, not against the bridge.

The auth model is also worth noting from a billing perspective: when an MCP client uses your APIFY_TOKEN, every actor run charges to your Apify account. So if you give your agent free rein over mcp.apify.com, it can in principle run any paid actor in the Store on your dime. Tight token scoping and run-cost ceilings matter.

What are the alternatives to mcp.apify.com?

Three named alternatives, in rough order of how I'd reach for them.

Direct actor standby. Every Apify actor in standby mode exposes its own URL and can be added as a discrete MCP entry. Wins when you've already picked the actor and want it as a clean, named tool slot. Trade-off: one config entry per actor.

Self-hosted Apify MCP server (open source). Apify publishes the MCP server as an open-source package you run locally over stdio. Right answer for air-gapped environments or manual tool-surface control. Trade-off: no output schema inference, manual APIFY_TOKEN env-var setup, and you maintain the runtime.

Dedicated composite MCP servers. Purpose-built MCPs that orchestrate multiple actors with domain logic — Counterparty Due Diligence MCP, Financial Crime Screening MCP, and the other composite MCPs in the fleet. Wins when the agent needs a scored verdict, not a raw dataset. Trade-off: single-purpose per MCP.

Each approach has trade-offs in setup cost, tool-surface flexibility, and orchestration depth. The right choice depends on whether the task is open-ended discovery, named single-tool execution, or scored composite intelligence.

When to use mcp.apify.com vs direct standby vs a dedicated MCP

Operator rule of thumb after 106 MCPs:

• Use mcp.apify.com when the agent doesn't know which actor it needs — open-ended questions, prototyping, "find an Apify actor that does X."
• Use direct standby when you've already picked the actor and want it as a clean, named tool slot. Pre-selected workflows where the actor doesn't change conversation to conversation.
• Use a dedicated composite MCP when the agent needs a verdict, not a dataset. KYB risk score, attack surface report, M&A readiness — anywhere the answer is scored synthesis across multiple actors.

These aren't mutually exclusive. A real Claude Desktop config can include all three. That's roughly the shape of mine.

Best practices for using mcp.apify.com

1. Keep your APIFY_TOKEN scoped. A full-access token lets an agent run any paid actor on your account. Use minimum-scope tokens.
2. Set per-actor run limits in Apify Console. Memory and timeout caps prevent a runaway run from burning compute.
3. Pair the bridge with a few direct standby URLs for actors you call constantly — fast access to favourites, dynamic discovery for the rest.
4. Watch run logs in Apify Console. When the agent picks an unfamiliar actor, you want to know which one before billing surprises.
5. For composite intelligence, build or buy a dedicated MCP. Don't recreate orchestration in client-side prompts — agents drop steps under load.
6. Test with a low-stakes prompt first. Confirm search-actors registers before pointing the agent at billable workloads.
7. Pin the MCP client version. Transport details (SSE deprecation, Streamable HTTP) move; pin to a known-good version.

Common mistakes when adopting mcp.apify.com

1. Treating the bridge as a replacement for composite MCPs. Generic Run-Actor has no orchestration logic. If you need scored synthesis, you need a composite MCP.
2. Pasting a full-scope APIFY_TOKEN. Scoped tokens are safer; the agent doesn't need account-admin rights to run actors.
3. Forgetting to update from the SSE endpoint. Configs pointing at mcp.apify.com/sse stopped working on April 1st, 2026. Use https://mcp.apify.com.
4. Expecting tool-picker entries for every Store actor. Dynamic discovery means actors surface only when the agent searches for them.
5. Skipping run-cost ceilings. An agent calling a $0.50/event actor in a loop runs up real money.
6. Trusting actor descriptions blindly. The agent picks based on what search-actors returns. Test the actors you expect to be picked.

Common misconceptions

"mcp.apify.com replaces my dedicated MCP server." Correction: it doesn't. The hosted bridge runs one actor at a time with no orchestration. Dedicated composite MCPs run multiple actors in parallel with scoring, deduplication, and verdict logic. They solve different problems.

"mcp.apify.com costs extra on top of the actor." Correction: per the Apify integration docs as of April 2026, the bridge is free. You pay the underlying actor's PPE rate, the same as if you'd called the actor directly.

"Every actor in the Apify Store appears as a tool in my client." Correction: only the default set (search-actors, fetch-actor-details, rag-web-browser, docs tools) is always on. Specific actors register as tools dynamically when the agent searches for them — or stay behind call-actor if your client doesn't support dynamic discovery.

Implementation checklist

1. Generate an APIFY_TOKEN at Apify Console → Integrations.
2. Decide auth mode: OAuth (recommended) or Bearer.
3. Open the mcp.apify.com configurator, pick your client, paste the generated block.
4. Restart the MCP client and confirm search-actors appears in the tools panel.
5. Run a low-stakes test prompt — "search Apify Store for a podcast scraper" — to confirm tool calls succeed.
6. Set per-actor run-cost ceilings and timeouts in Apify Console.
7. Add direct standby URLs for actors you call constantly.
8. Add dedicated composite MCPs for any domain intelligence work that needs scoring.

Limitations of mcp.apify.com

• No cross-actor orchestration. call-actor runs one actor at a time. No parallelism, synthesis, or scoring. That's by design — orchestration is the job of dedicated composite MCPs.
• Generic Run-Actor inputs. The agent infers inputs from fetch-actor-details. For actors with sparse or ambiguous schemas, agents can build malformed inputs.
• Token scope risk. A full-scope APIFY_TOKEN lets the agent run any paid actor on your account. Scoped tokens and run-cost ceilings are practically necessary.
• Streamable HTTP only. The legacy SSE endpoint stopped working on April 1st, 2026. Older configs that haven't updated will silently fail to connect.
• No persistent session memory across actor calls. Each run is independent. An agent chaining multiple actors must carry context itself.

Mini case study: dropping 14 MCP entries to one

Before mcp.apify.com matured, my Claude Desktop config had 14 separate Apify-related MCP entries — direct standby URLs for daily-use actors plus composite MCPs for KYB and cyber work. Each with its own URL, headers, and name slot.

After updating to the hosted bridge, the config dropped to four entries: mcp.apify.com for everything else, plus three composite MCPs as named tool slots (counterparty due diligence, M&A target intelligence, cybersecurity intelligence). Tool picker stayed clean.

Numbers: 14 → 4 entries (71% drop in config maintenance), tool picker went from 14 fixed slots to 4 fixed plus dynamic surfacing of 325 actors and 106 MCPs on demand. Per-conversation run cost stayed identical (bridge is free; PPE pass-through unchanged).

These numbers reflect one operator's setup. Your config drop depends on how many Apify actors you currently wire individually.

Example: what the agent actually sees

Here's a sketch of what an agent receives when it calls the default tool set on mcp.apify.com — the payload an MCP client renders before deciding which actor to invoke:

{
  "tools": [
    { "name": "search-actors", "description": "Search Apify Store for actors matching a query." },
    { "name": "fetch-actor-details", "description": "Fetch input schema and pricing for an actor." },
    { "name": "call-actor", "description": "Run an actor with JSON input and return the dataset." },
    { "name": "search-apify-docs", "description": "Search Apify documentation." }
  ]
}

Notice what's not there: any Apify Store actor by name. The agent surfaces actors via search-actors, then invokes through call-actor (static) or registers via add-actor (dynamic-discovery clients).

Key facts about mcp.apify.com

• One URL connects MCP clients to Apify's full Store of 6,000+ actors.
• The hosted bridge is free; pricing inherits the underlying actor's PPE rate.
• Auth is OAuth (recommended) or Bearer token via Authorization header.
• Streamable HTTP is the only supported transport as of April 1st, 2026 (SSE deprecated).
• Default tools: search-actors, fetch-actor-details, apify/rag-web-browser, search-apify-docs, fetch-apify-docs.
• Dynamic-discovery clients receive add-actor instead of call-actor to register Store actors as new tools at runtime.
• Per the April 23, 2026 changelog, the configurator supports Claude Desktop, Claude.ai, Claude Code, Antigravity, Cursor, ChatGPT, Codex, and VS Code.
• Output schema inference is hosted-only; the local stdio Apify MCP doesn't support it.

Glossary

• MCP (Model Context Protocol) — open standard from Anthropic (November 2024) for AI clients calling typed tools on remote servers.
• MCP client — the AI app connecting to an MCP server. Claude Desktop, Cursor, Claude Code, ChatGPT desktop, VS Code.
• MCP server — a service exposing typed tools over MCP. mcp.apify.com is one; dedicated composite MCPs are another category.
• Standby mode — Apify feature that keeps an actor warm so it answers HTTP requests in seconds. See the standby mode glossary entry.
• PPE (Pay Per Event) — Apify's per-event pricing model. See PPE pricing in the learn guide.
• Composite MCP — purpose-built MCP that orchestrates multiple actors with scoring and synthesis (the 106 MCPs on ryanclinton).

Broader applicability: agent-marketplace bridges

mcp.apify.com is one example of a broader pattern: a hosted bridge that exposes a marketplace of tools to agents over a single MCP endpoint. The same shape applies wherever:

• A platform hosts many tools and wants agents to discover them at runtime.
• Pre-wiring every tool into client config doesn't scale.
• Tool selection happens based on the user's question, not the developer's setup.
• Tool authors want passive distribution through agent search.
• Auth, billing, and observability are easier to centralise on the platform side.

These patterns apply beyond Apify to any agent-tooling platform — vendor MCP gateways, internal MCP servers inside companies, marketplace-style API platforms. Hosted-bridge architecture is becoming the default shape for agent tooling at scale.

When you need this

You probably want mcp.apify.com if:

• You use Claude Desktop, Cursor, Claude Code, ChatGPT desktop, or VS Code with MCP support.
• You want an agent to reach Apify actors without pre-wiring each one.
• You're prototyping agent workflows and don't know which actor you'll need.
• You maintain a Claude Desktop config with multiple Apify entries and want to consolidate.

You probably don't need this if:

• You only ever use one Apify actor and a direct standby URL is enough.
• Your agent's task is composite intelligence (KYB, M&A, attack surface) — a dedicated composite MCP is the right fit.
• You're not using an MCP-compatible client.
• You can't issue an APIFY_TOKEN (air-gapped, restricted environments — use the open-source self-hosted MCP).

Frequently asked questions

What is mcp.apify.com?

mcp.apify.com is Apify's hosted Model Context Protocol server — a single HTTPS endpoint that lets MCP-compatible AI clients dynamically discover and call any of the 6,000+ Apify Store actors from one connection. It supports OAuth and Bearer auth, exposes a small default tool set (search Store, fetch actor details, run actor, search docs), and inherits PPE pricing from the actor it runs.

How is mcp.apify.com different from per-actor MCP installs?

Per-actor installs require one config entry per actor — name, URL, auth header. Adding a new actor means editing config and restarting the client. mcp.apify.com replaces all of that with one entry. The agent searches Apify Store at runtime via search-actors, fetches the actor's schema on demand, and either calls it through call-actor or registers it via add-actor on dynamic-discovery clients.

Does mcp.apify.com cost money?

The hosted bridge is free. You pay the underlying actor's PPE pricing when it runs through the bridge — the same rate as calling the actor directly. There is no documented per-call surcharge or markup as of April 2026. Compute, dataset storage, and proxy traffic bill against the actor's normal pricing model.

Does mcp.apify.com replace dedicated MCP servers?

No — it replaces per-actor MCP installs and one-off direct-call setups. Dedicated composite MCPs (orchestration with scoring across multiple actors) solve a different problem: returning a verdict instead of a raw dataset. mcp.apify.com's call-actor is a generic dispatcher with no orchestration logic. The two categories are complementary.

Which AI clients work with mcp.apify.com?

Per the April 23, 2026 Apify changelog, the configurator supports Claude Desktop, Claude.ai, Claude Code, Antigravity, Cursor, ChatGPT, Codex, and VS Code. Any MCP-compatible client that speaks Streamable HTTP and accepts OAuth or Bearer auth should work; legacy SSE clients stopped working April 1st, 2026.

Is mcp.apify.com safe with a full-access Apify token?

A full-access token lets an agent run any paid actor on your account — runaway loops or hallucinated tool calls can burn real money. The practical recommendation is to issue a scoped token, set per-actor run-cost ceilings in Apify Console, and watch run logs. Treat the agent like any other untrusted automation holding your API keys.

Can I still use direct actor standby URLs alongside mcp.apify.com?

Yes — that's a common setup. A typical Claude Desktop config includes mcp.apify.com for open-ended discovery, two or three direct standby URLs for daily-use actors (named tool slots), and one or two dedicated composite MCPs for domain intelligence. The three modes coexist.

Ryan Clinton runs 106 MCP servers and 325 actors on Apify Store under the ryanclinton namespace and builds developer tools at ApifyForge.

Last updated: April 2026

This guide focuses on Apify's hosted MCP bridge, but the same hosted-bridge patterns apply broadly to any agent-tooling platform exposing a marketplace of tools through a single MCP endpoint.