When I started researching MCP marketplaces to monetize my Korean data scrapers, I assumed the hard part would be the registration form. It wasn't.
The form took 5 minutes. Understanding what "Remote MCP server" actually means — and finding the path that actually works — took most of a day.
Here's what I learned, so you don't have to repeat it.
The Setup
I have 13 public Apify Actors for Korean data: Naver Place reviews, Naver news, Musinsa rankings, Bunjang listings, and more. They've been running on Apify for about a month — 14,000+ runs, 100+ users, ~$47/month revenue.
MCP marketplaces like MCPize and MCP-Hive are promising a new channel: instead of users running your scraper directly, AI agents call it as an MCP tool. The market data is real — 11,000+ MCP servers exist, fewer than 5% are monetized. There's a window.
So I opened the MCP-Hive registration dashboard and hit my first wall.
What I Tried First (And Why It Didn't Work)
Apify has a hosted MCP gateway at mcp.apify.com. You can point it at specific actors:
https://mcp.apify.com?tools=username/actor-name
I assumed I could paste this into the "Remote endpoint" field on MCP-Hive and call it done.
Wrong.
The Apify gateway requires OAuth or a Bearer token. Every user connecting through MCP-Hive would need their own Apify API key. That breaks the entire model — if users need Apify accounts, why would they pay MCP-Hive?
For a shared marketplace to work, the MCP server needs to be self-contained. No external auth dependencies.
The Actual Path: Apify Standby Mode
Apify has a feature called Standby mode. When an Actor is deployed with usesStandbyMode: true, it runs as a persistent web server — always on, responding instantly.
Apify also provides a TypeScript MCP Server template that uses this:
apify create my-mcp-server --template ts-mcp-server
Deploy it, and you get a stable endpoint:
https://your-username--your-actor-name.apify.actor/mcp
This endpoint is:
- Public (no OAuth required for the MCP connection itself)
- Persistent (Standby mode keeps the container warm)
- A proper MCP server (tools, resources, the whole protocol)
That's the URL you paste into MCP-Hive. That's what makes it work.
One More Wrinkle: SSE Is Gone
If you've been following MCP server tutorials from late 2025, they probably used Server-Sent Events (SSE) as the transport. Some marketplaces still list "HTTP/SSE endpoint" in their docs.
Apify dropped SSE support on April 1, 2026. The new standard is Streamable HTTP (aligned with MCP spec version 2025-03-26). The /mcp endpoint on Standby actors uses Streamable HTTP.
Before registering anywhere, confirm the marketplace supports Streamable HTTP. Most are updating, but some may still expect SSE.
What This Means In Practice
To go from "Apify Actor" to "MCP marketplace listing," the path is:
- Build a new Standby-mode Actor using the TypeScript MCP Server template
- Wrap your existing scraper logic as MCP tools inside it
- Deploy to Apify with
usesStandbyMode: true - Register the
*.apify.actor/mcpendpoint on MCP-Hive or MCPize
The existing Actor stays as-is. The MCP server Actor is a thin wrapper that calls your scraper's logic (or the Apify API for your existing Actor) and exposes it as tools.
It's not a 5-minute job. Building and deploying the wrapper is probably 1-2 hours for a simple single-tool server. But it's a documented, supported path — not a hack.
Why This Matters
Most Apify developers with popular Actors are sitting on MCP-ready infrastructure and don't know it. The hosting is there (Standby mode), the compute is there (your Actor's logic), and the marketplace demand is building.
The gap is awareness — and a few hours of TypeScript.
If you have an Apify Actor that solves a real data problem, the MCP marketplace channel is opening up. The technical path is now clear. The window for early positioning is now.
I build Korean data tools on Apify. If you're working on MCP server monetization or have questions about the Standby mode setup, drop a comment — happy to share what I've found.
Top comments (0)