how to sell mcp servers on apify (19 live, the honest version)

elisabeth hitz · july 27, 2026 · 9 min read

selling an MCP server means publishing it as a paid actor on apify: AI agents and developers call your tools over HTTP, apify meters every call, bills the buyer a few cents per result, takes a 20% cut, and pays you out. no stripe integration, no auth system, no invoicing. that's the promise. i have 19 MCP servers on the platform, so this is the version with the traps, the architecture that actually survives, and the revenue numbers nobody leads with.

an MCP server, if you're new here, is a set of tools any AI agent can call through anthropic's model context protocol, the open standard claude and a growing list of agents speak. i've written before about how AI systems decide what to cite and why every AI workflow needs a verification layer. this post is the other side of the counter: being the person selling the tools the agents use.

what selling an mcp server actually means

on apify, an MCP server ships as an actor: a container that runs on their infrastructure. it runs in two modes at once. in standby mode it's a live HTTP server that agents call at a fixed URL. in batch mode anyone can run it once from the store and get results in a dataset. the buyer authenticates with their own apify token, their account gets charged per event, you get paid, apify keeps 20%.

the part that sold me: the billing is the platform's problem. i price a tool call at ten cents, and metering, invoices, fraud, refunds, payouts, all of it belongs to apify. as a one-person business, that trade is worth the 20% many times over. i wrote about the same logic in apify vs self-hosting your MCP server.

what i shipped: 19 servers, just over 100 tools

my catalog is all B2B sales, compliance, and creator tools, because that's the decade of work i can actually stand behind. thirteen are live in the store today; the newest six are rolling out this week (apify caps publications at five actors per day, one of the traps below).

  • deal qualification: MEDDIC coach, mutual action plans, CRM pipeline hygiene, multi-threading gaps
  • account intelligence: real SEC 10-K excerpts, tech-stack interpretation, SaaS pricing benchmarks, buyer signals, SMB sales intelligence
  • compliance: global employment law scaffolding for EOR sales across EMEA, APAC, LATAM, plus the EU AI act
  • creator economy: viral hook formulas, rate calculators, DM scripts

the full catalog with tool counts and prices is in the sales-team MCP catalog post, and the store profile is at apify.com/elisabethhitz.

the architecture that survives (and the one that doesn't)

my first mental model was wrong and it cost me three broken build cycles: "an MCP server is a stdio binary, apify is a docker host, ship it." apify's platform has opinions, and the actors that ignore them get deprecated automatically.

what actually survives, condensed:

  • streamable HTTP, not stdio, not SSE. apify removed SSE support in april 2026. the server speaks streamable HTTP at /mcp.
  • a readiness probe. standby mode never marks your actor ready unless it answers the platform's probe header. miss this and your server simply never starts.
  • dual mode. apify runs an automated test on public actors roughly daily. the test runs your actor in batch mode with the default input. if that run produces an empty dataset, a deprecation clock starts. every server i ship has a batch branch that runs one tool and pushes the result.

the step-by-step build, with the dockerfile and the exact probe code, is in the deployment guide.

the platform traps i hit so you don't have to

trap what happens
pricing cooldownonce you set or change a price, it's locked for one month. your first price is a commitment, not an experiment.
paid actors can't unpublishan actor with paid pricing can't be made private until you first schedule it free and wait. going paid is close to a one-way door.
5 publications per daythe store caps how many actors you can make public in 24 hours. batch launches need a calendar.
daily automated testsfail the default run and a multi-week countdown to deprecation starts silently.
schema strictnessinput schemas need a schemaVersion field, every property needs a description and editor, and the store caps you at 3 categories. builds fail on any miss.

the rule that matters more than architecture: sell real outputs

one of my early drafts had a tool that "simulated" parsing SEC filings. it returned the same three invented initiatives for any ticker you gave it. plausible looking, completely fabricated. it never went live in that state. i rebuilt it to fetch actual filings from SEC EDGAR and return verbatim quoted excerpts with source URLs, and only then did it get a price tag.

if you sell fabricated outputs to AI agents, the agent quotes your fabrication to a real buyer and your name is on it. the same discipline i apply to verification in my own workflows applies double to anything with a price. framework tools are fine to sell, my MEDDIC coach sells structured methodology, but the listing says exactly what it is. simulated data dressed as live data is the one thing that should never ship.

the honest revenue reality

here's the paragraph most "i sell AI tools" posts skip. my servers show hundreds of runs. nearly all of those runs are apify's own automated daily tests, not customers. organic usage on my catalog so far is close to zero, and so is the revenue.

the listings are necessary, not sufficient. a priced, verified, discoverable server earns nothing until people find it, which makes distribution the actual product: posts like this one, MCP directories, and the audience i already talk to. i'd rather tell you that plainly than write the fantasy version. if the catalog starts producing real numbers, i'll publish them, the same way i publish my pilot study data.

should you do this?

yes, if: you have real expertise that compresses into tools, you already have or are building an audience, and you treat the store listing as one distribution channel among several. the marginal cost of my catalog was low precisely because the expertise already existed; the servers are my sales career expressed as callable tools.

no, if: you're hoping the marketplace does the marketing. it won't. zero distribution means zero revenue, no matter how good the server is.

frequently asked questions

can you make money selling mcp servers?

the billing infrastructure exists and works: pay-per-event pricing, a few cents per call, 20% platform cut. but a listing alone earns nothing. revenue follows distribution, not publication.

why apify and not my own hosting?

apify bundles metering, billing, payouts, hosting, and store discovery. self-hosting means building all of that around stripe yourself. the full comparison is in apify vs self-hosting.

how long does one server take to build?

once the template existed, hours, not weeks. the first one took the longest because every platform opinion had to be learned the hard way. that template is documented in the deployment guide.

do i need to be a programmer?

i build with claude code doing the heavy lifting and verify everything end to end before it ships. you need judgment about what the tools should do and the discipline to test them; the typing is increasingly optional. that's the whole thesis of ai engineer vs ai builder.

the skills, templates, and verification workflows i used to build all 19 servers are the same ones in my AI builder toolkit at closermethod.com/skills. value first: the brand voice skill runs free on the page before you pay anything.

go deeper

sources: anthropic model context protocol documentation; apify actor, standby mode, and monetization documentation; all catalog counts, prices, and platform-limit behaviors verified directly against the live apify account and API on july 27, 2026, including the 20% margin, the 1-month pricing cooldown, and the 5-per-day publication limit as returned by the platform itself. written by elisabeth hitz, certified in anthropic's ai fluency program (framework & foundations, and ai capabilities & limitations), plus claude 101 and claude cowork.