How to monetize an MCP server and charge per tool call

How do you monetize an MCP server?

You monetize an MCP server by adding a payment step in front of each tool you want to charge for. MCP itself gives you discovery and calling, but nothing that sets a price, takes payment or returns a receipt. So the money has to come from a layer that works alongside the protocol.

On Qatom, that layer is the catalog. Each paid tool becomes a catalog item with one price per call, one HTTPS endpoint and an input schema. A buyer's agent finds the item through MCP, pays from its own wallet, and gets your tool's answer plus a receipt in the same call. The full sequence is in the Capabilities Index.

How does MCP work, and where do MCP payments fit?

The Model Context Protocol is an open protocol for connecting AI assistants to tools and data. A client such as Claude connects to a server, lists the tools it offers, and calls a tool by name with arguments that match the tool's input schema. Remote servers authorize the client with OAuth 2.1.

That authorization step answers "who is calling?". It does not answer "what does this cost?" or "has it been paid?". The specification has no message for a price, a payment or a receipt, which is why MCP payments sit in a separate layer.

You can still publish a server to the official MCP Registry so people can find and install it. A registry listing helps discovery. It does not collect money per call.

What are the ways to charge for MCP tools?

There are a few common patterns. Each fits a different kind of buyer.

Card fees are the main reason a per-call card model fails. Stripe's standard US online price is 2.9% + 30¢ per card transaction, so a $0.10 charge would cost about $0.30 in fees. These approaches can complement each other: a subscription for heavy users and a per-call catalog item for everyone else is a reasonable mix.

What does a paid MCP server look like on Qatom?

There are two MCP connections in the picture. Buyers connect their client to the Qatom master MCP at https://mcp.m.todaq.net/mcp, which gives their agent every public catalog item plus the wallet tools, including catalog_search and agent_checkout. That works in Claude, Grok, Muse or any other MCP client (A1).

As a seller, you also get your own MCP instance. Registering a seller account creates it (B34), and the Dashboard shows it as your first MCP instance. Your items live on that instance, and public ones also show up in master search.

The name of each catalog item becomes the tool name agents see (B9). Use a shared prefix such as "Brand: item", so a catalog_search for your prefix finds all your items. The receipt line comes from the separate Descriptor field.

Public or private: which should a paid MCP server use?

Public items appear in catalog_search on the master MCP. Private items are reachable only through your own MCP instance, so they suit internal tools or an item built for one customer (B14).

Choose carefully. Visibility is set when you create the item and can't be changed in the Dashboard afterwards. To take a private item public, you duplicate it.

How do you map an MCP tool to a catalog item?

If you already have MCP tools, most of the work is a translation. Each tool definition has a name, a description and an input schema, and each maps to a field on the item form.

Qatom forwards only the arguments your schema declares and rejects the rest (B11). Give each property a description with its unit, range and default. Never accept raw SQL, code or query strings as inputs; turn them into named inputs.

How to list your MCP tools as paid catalog items

Follow these steps for each tool you want to sell. The seller guide skill walks you through the same order inside your own agent.

1. Register. Go to dashboard.qatom.ai, register with an email code or passkey, fill in your organization, choose a plan and click Start my MCP server. The server takes a few minutes to become healthy.
2. Pick the first tool. Choose one that answers in one call and is cheap to serve, and pair it with a free check item.
3. Host the endpoint. Put the tool's logic behind one HTTPS endpoint. The Worker template reads one catalog.json, validates inputs, guards the paid route and serves /llms.txt (B2).
4. Guard the paid route. Generate a token with openssl rand -hex 24 and store it in your host's secret store. The endpoint checks the Authorization header and answers 404 when it is missing or wrong (B3).
5. Create the item. Open Catalog, click + New item and fill in name, descriptor, price, method, endpoint, description and schema. Add the header Authorization: Bearer <token> marked Sensitive (B12).
6. Write the agent read-me. Generate llms.txt from your catalog, with worked examples, input schemas and every error code, and serve it at your site root (B4).
7. Test by buying. Connect the master MCP, fund a small agent wallet and buy each item once with agent_checkout, with and without inputs. Try a bad input too (B19).
8. Announce. Run catalog_search for your brand prefix, check name, price and seller, then share your llms.txt URL (B21).

Headers are per item. If three paid tools share one endpoint, each item needs the Authorization header.

How should you set MCP server pricing?

Start from what one answer costs you to produce, then price each call above it. Prices are in USD-TDN, a US-dollar token where 1 USD-TDN equals 1 USD. The minimum paid price is 0.001, and prices use at most three decimals.

One catalog item has one price. If you want a basic and a detailed version of a tool, list them as two items, and have each description say what the higher tier adds. A free sibling item lets an agent check that your tool fits before it pays.

Two more points shape MCP server pricing:

• Agent wallets suit small prices. Guest card checkout has a minimum of about $0.50, so tools priced under 50 cents should expect buyers paying from agent wallets.
• Your plan sets your limits. Builder is free with 1 agent, up to 5 items and 25 transactions a month. Pro is $20 a month and Max is $300 a month; see pricing. Qatom takes 0% of each sale.

What does the buyer's agent experience when it pays?

The buyer's agent calls agent_checkout with the item id and arguments. Payment comes from the agent twin, a wallet that holds only what its owner moved there, so the agent can never overspend it (A13).

Under the owner's auto-approve limit, the purchase settles at once. Above it, the owner approves in the chat or by passkey or phone app. Every purchase returns a transaction id and an emailed receipt with proof of purchase.

A retry is a new charge, and a call your endpoint rejects can still be charged. Design each tool to answer in one call, and return every error with a code, a plain message and a next step. For tools that are expensive to serve, verify each call against the transaction id; the per-call API guide covers that check in detail.

How do you get paid when you monetize an MCP server?

Each sale lands on the item's own twin. A standing distribution sweeps it to your primary twin a few times a day (C17), and a distribution can also split revenue across up to 200 payees.

From the primary twin, you can cash out to a US or Canadian bank account. The minimum is 10 USD-TDN, the fee is a flat $1, and ACH takes 2 to 5 business days (C26). Sales counts and earnings per item show on each item page.

What did MCP Dev Summit Toronto 2026 say about paid MCP tools?

At MCP Dev Summit Toronto 2026 (5 to 6 October), a common thread across the published talks was that trust and identity, not the protocol, are now the hard parts. Three points matter when you charge for MCP tools.

• Design tools from tasks, not endpoints. Several talks, such as "Stop Wrapping Endpoints" and Poka's "Your MCP Is Not an API Gateway", warned that a 1:1 wrapper around a REST API makes a poor MCP server. Name each paid tool by the outcome it delivers, keep inputs short, and return errors that tell the agent what to call next. This maps directly onto one catalog item per outcome.
• Fewer, sharper tools cost less context. AMD's talk "Too Many Tools" measured each tool schema at about 204 tokens, so a long tool list crowds the model's context window. A small catalog of clearly named items is easier for an agent to choose from.
• Meter where the call happens. Kong's talk "From Tool Calls to Revenue" made the case that every tool call is an economic event and that metering belongs in the request path: "a meter that cannot say no is accounting, not control." On Qatom, payment settles before Qatom calls your endpoint, and your secret header turns away calls that did not come from Qatom.

Qatom ran a workshop at the summit on exactly this flow: list an item once, agents find it, pay, then receive it.

Next steps

• Follow every seller step in the Capabilities Index.
• Read how to charge AI agents for API calls for endpoint security and fulfillment checks.
• Compare plans on the pricing page, or contact the team about VPC, on-premises or air-gapped deployment.