What is an MCP server.
An MCP server is a service that exposes tools, resources, or prompts to AI agents over the Model Context Protocol. Agents discover the server, read its tool descriptions, and call those tools as part of their plan. A paid MCP server adds one more behavior on top: it can return HTTP 402 with a payment URL, expecting the agent's wallet to settle before the tool actually runs.
One contract, many agent runtimes.
Before MCP, every tool provider had to ship a different integration for every agent host - one for Claude Desktop, one for a Cursor extension, one for an internal agent runtime, one for OpenAI's function-calling format. Each integration drifted independently. MCP collapses that into a single server interface. Write the server once; any MCP-aware client can use it.
That uniform contract is what makes MCP-server monetization viable. If every agent runtime spoke its own dialect, charging per tool call would require a separate billing integration per dialect. With MCP, the server returns 402 once, in HTTP, and any runtime whose agent has a wallet can settle it. The protocol pins the contract; the payment layer plugs in beneath it.
Advertise, invoke, optionally charge.
- Advertise. The server publishes a list of tools, each with a name, JSON-schema input, and a natural-language description. The agent's planner reads these descriptions when deciding which tool to call.
- Invoke. The agent calls a tool with structured arguments. The MCP transport (stdio, SSE, or HTTP) delivers the call to the server.
- Authorize. Paid servers check whether this caller has already paid for this tool call (typically by API key, session, or payment receipt). If yes, run the tool. If no, return 402 with a payment URL.
- Settle (if paid). The agent's wallet pays at the URL. The wallet provider confirms the payment to the server (typically via a signed webhook); the server marks the caller paid, and the retried call runs the tool.
- Return. The result flows back to the agent through the MCP transport. The agent integrates the result into its next reasoning step. Free MCP servers skip steps 3 and 4 entirely.
The provider never has to know which agent runtime is calling, and the agent never has to know which payment provider the MCP server uses. Both sides talk through the protocol contract.
Three MCP-server shapes.
A documentation-search MCP server
A startup publishes an MCP server that exposes a single tool, search_docs(query). Any MCP-aware agent (Claude Desktop, a coding agent, an internal agent at a customer) can install the server, see the tool advertised, and call it. The startup never has to ship a separate SDK per agent runtime - the MCP server is the SDK. Free initially, then monetized later by returning 402 on heavy queries.
An internal MCP server bridging a private database
An engineering team runs an MCP server inside their own infrastructure that exposes read-only tools against their production analytics warehouse. Their internal Claude-based agents call those tools to answer business questions. No external API, no SDK; the MCP server is the contract. Because it is internal, no payment layer is needed - but the same server pattern works unchanged if they later expose a paid version to partners.
A paid MCP marketplace listing
An independent developer publishes an MCP server that calls a premium financial-data API and resells it per-query. Their server returns 402 with a hosted payment URL for any tool call. Agents that have a wallet pay automatically (within their spend policy); agents without a wallet see the 402 and stop. The developer captures revenue per call without onboarding each customer manually.