The rise of the agentic economy on the shoulders of MCP

How does intelligence emerge in biological systems? Start with an individual neuron. It grows connections, communicates with other cells, and obtains the nutrients it needs. Zoom out, and the collective behavior becomes something much richer than the activity of an isolated cell. Jan Curn opens with this picture of intelligence emerging from smaller units pursuing their own interests.

Markets provide the next analogy: participants establish relationships, exchange information, and respond to one another. Companies offer a more familiar—and deliberately provocative—version: intelligence emerges through Slack, as employees interact and coordinate. Neither analogy guarantees wise decisions, but both shift attention from the capability of one participant to the behavior of a connected system.

Applied to computing, the question becomes whether general intelligence could emerge from multiple models pursuing goals and interacting, rather than from increasing model size alone. That is Curn’s hypothesis, not a demonstrated route to AGI. He proposes Model Context Protocol (MCP) as connective infrastructure for an agentic mesh. Introducing himself as Apify’s founder, he describes an economy in which agents find counterparties and purchase services from businesses, tools, and other agents: business-to-agent and agent-to-agent transactions.

Curn reports approximately 5,000 Actors in Apify’s marketplace at the time of the talk. Its origins are in web scraping: extracting social media and search data, supplying RAG pipelines, and finding leads. The catalog also includes data processing tools. Some Actors come from Apify; others come from community developers who earn money from their use.

An Actor is a self-contained, Docker-based piece of software with defined inputs and outputs. That boundary makes it a distributable product as well as a callable program. Google Maps Scraper illustrates the packaging: a listing combines the tool with its creator, description, statistics, and pricing. Curn says it extracts more data than the Google Places API provides; the talk does not establish a field-by-field comparison.

The same input/output contract supports several integration surfaces: TypeScript and Python SDKs, OpenAPI access, and a CLI for terminal use. Make, Zapier, Clay, and other automation platforms can also call Actors. The underlying software unit stays the same while the calling environment changes.

The Apify MCP server adds an agent-facing interface to that catalog. An agent connects using an Apify account and API key, then accesses Actors through the server. The crucial capability is dynamic tool discovery: the client can learn about tools during a workflow instead of starting with every callable definition already in context. Curn describes VS Code and Claude Desktop support as newly available at the time of the recording.

There are two layers here. Apify supplies catalog search and the ability to add Actors to the available tool set. MCP supplies the protocol for listing and invoking tools; its March 2025 tools specification also defines optional notifications when that list changes. A tool-list request has this JSON-RPC form:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Listing the server’s exposed tools is different from searching a marketplace for a suitable Actor. The latter is application behavior built on top of the protocol.

Expose tools as needed, rather than loading the entire catalog into context. Curn’s objection to his OpenAPI approach is the size and selection difficulty of presenting thousands of definitions at once. More available tools also create more opportunities to choose incorrectly. His claimed advantage for MCP is the ability to change the available set during the workflow—not a claim that OpenAPI cannot describe those services.

Curn points to a Google Trends comparison with OpenAPI and Google’s A2A as evidence of MCP’s momentum. Search interest is not protocol adoption share, but the proliferation of directories supplies another sign of activity: Mastra even published a registry of MCP registries.

Anthropic’s own registry was still being developed in this account. Curn also references A2A discovery at /.well-known/agent.json, which he characterizes as DNS-based. These are historical examples of how an agent might locate a counterpart. They lead to a separate question: once an agent finds a server, can it actually use the service?

Curn describes Zapier MCP as offering access to roughly 5,000 apps, while still requiring users to connect the individual services. A GitHub or Slack integration cannot supply access to the user’s account merely because a callable interface exists. The user must facilitate authorization.

That leaves the developer deciding which counterparties the agent can reach before the workflow begins. Calling an authorized tool and acquiring a new service are different capabilities. A person can find a provider and purchase its service; an agent constrained to prearranged credentials cannot do the equivalent independently. Curn connects that limitation back to his opening hypothesis: richer collective behavior will require agents that can acquire services, not just invoke the tools humans have already connected.

The first approach is to let agents register with each service themselves. Give the agent an email address and a credit card, then have it work through subscription forms, CAPTCHAs, and account creation. Phone verification and requirements for a real person behind an account make this more than a browser-automation problem.

The second approach is shared identity and payment infrastructure: fund an account that agents can use to identify themselves and buy services. Curn names Vertify, Coinbase’s x402, Stripe, Mastercard, and Visa in this discussion. These are not equivalent architectures; x402 is an open HTTP payment protocol using stablecoins, rather than a universal centralized identity provider.

A payment network needs providers willing to accept it and customers who want to spend through it. Curn invokes PayPal’s spending to acquire a market and the difficulty of establishing credit-card acceptance as analogies. The underlying problem is that buyers need accepting sellers, while sellers need buyers.

The third approach is a centralized marketplace of MCP services. The agent uses one marketplace account and authentication token. A tool publisher supplies the upstream service account, credentials, and payment method, then sets a price for using the Actor. The agent purchases the packaged capability without opening its own account with every underlying provider.

The Actor can execute its own code, wrap an external API, or expose an external MCP server. In the nested case, a parent server makes the downstream server’s tools available through its own interface. The request travels from agent to marketplace to Actor to upstream service; the user pays for Actor usage, the developer receives revenue, and the developer pays the upstream bill. Curn proposes that publishers can add these wrappers without the provider’s participation. Technical independence does not, by itself, establish permission or contractual compliance.

The demonstration is prerecorded because the venue’s internet connection is unreliable. It starts in Claude Desktop with the Apify MCP server connected and 18 tools available. The request asks for the venue of AI Engineer World’s Fair in San Francisco, preferably using Apify Actors.

The workflow proceeds through three operations:

1. Search the Actor catalog for a tool that can answer the question.
2. Select RAG Web Browser, which combines Google search with retrieval of page content.
3. Submit the venue query and parse the resulting page.

The recorded result identifies the San Francisco Marriott Marquis. This first task establishes the basic path from a natural-language question through tool discovery to retrieved information.

The next task needs a Twitter scraper that is absent from the current context. Claude first searches the store for a suitable Actor, then calls add-actor to add the new tool. Finding a tool and making its definition available to the model are separate steps. A catalog result alone does not give the client a refreshed callable interface.

The recorded client exposes that distinction: Curn must disable and re-enable a tool to refresh Claude Desktop’s tool list. This is a workaround observed in that historical demonstration, not current setup guidance. Once refreshed, Claude calls the newly available Actor on Apify to retrieve the conference’s latest tweet. The result concerns that morning’s workshops. Curn suggests the Twitter handle probably came from the website, but does not establish its source.

The final task crosses into an external provider’s service. Curn says Apify created a Browserbase account, supplied its own API token, and published a wrapper for Browserbase’s MCP server. Browserbase, he says, neither published the Actor nor participated in its setup. The important architectural change is that the upstream account belongs to the wrapper’s publisher, while the agent continues to enter through Apify.

Claude is asked to use Browserbase to fill the conference website’s email subscription form with Curn’s email address. The call passes through the published Actor to Browserbase MCP, which performs the browser interaction. Curn presents this as a way to expand the marketplace without arranging a bespoke integration with each provider.

The browser task takes time: the agent evaluates screenshots and searches for the input field before completing the form. Curn advances through part of the recording and reports that the email subscription succeeded. The demonstration therefore connects three previously separate capabilities—discovering a tool, accessing a publisher-funded upstream service, and acting on a website—through the marketplace interface. Clients need tool-discovery support to use the ecosystem in this way.

For a developer, publishing an Actor combines monetization with distribution: the tool becomes accessible to AI clients already connected to Apify and to its existing integration ecosystem. Curn reports more than $250,000 paid to creators in the month preceding the talk.

He also reports overall Actor revenue above $1.5 million per month and one million monthly visitors across the ecosystem at talk time. Creator payouts, Actor revenue, and visitor counts measure different things; none is presented as MCP-only revenue. The invitation is to publish tools or agents into that existing marketplace, rather than build a separate acquisition and billing channel for each one.

Even a fixed-tool agent workflow can be difficult to make reliable. Letting the agent discover new tools introduces another source of variability: the available capabilities, their interfaces, and the agent’s choices can change during execution. Curn acknowledges that this can be flaky. His expectation is that improving models will make discovery useful and reliable, but he explicitly leaves that outcome open.

Trust is a separate unresolved problem. An agent may be able to find, call, and pay a tool without knowing whether it should trust that tool or another agent. No reputation or economic trust mechanism is supplied here. Whether autonomous interaction can ultimately enable AGI remains unanswered as well. Curn closes by inviting experimentation through mcp.apify.com: the marketplace demonstrates a path to acquiring capabilities, while reliability, trustworthy counterparties, and emergent intelligence remain questions to test.