Paid MCP server market report 2026: supply, networks and evidence

What this market report measures

This snapshot uses the 88-entry TOLL·402 editorial catalog as it existed on July 13, 2026. The catalog is a curated product layer, not the full discovery corpus. It stores classification, provider copy, network claims, price evidence and verification state separately so a mention in documentation does not automatically become a supported price or a verified paid call.

Two counts answer different questions. Thirty-nine entries mention MCP somewhere in their catalog record, which includes infrastructure, gateways, APIs and templates related to MCP. Eighteen use the specific mcp-server kind. The narrower count is the right denominator for describing deployed MCP-server supply; the broader count shows how far MCP has spread through the surrounding x402 tooling ecosystem.

The July 2026 supply snapshot

The 18 classified MCP servers span live data, search, public filings, crypto intelligence, utilities, due diligence, document work, payments and persistent agent services. Some expose a handful of focused tools; others advertise dozens or hundreds. Tool count alone does not measure value because schemas, output quality, upstream cost and charging units vary widely.

All 18 were marked live in the editorial catalog. That status reflects current public provider evidence and endpoint review, not a promise of uninterrupted availability. A live label is weaker than a recent quote check, and both are weaker than a settled paid call with reviewed output. Buyers should preserve those distinctions when building shortlists.

Which networks do paid MCP servers advertise?

Base appeared on 17 of the 18 MCP-server records. Solana appeared on six, and three included the catalog's other-network category. Counts overlap because a server may advertise several networks. The sample therefore shows a clear Base center of gravity alongside an emerging multi-network segment, not mutually exclusive market shares.

Network presence is a provider claim until the exact payment option is observed and exercised. A server can mention Base and Solana while only one route, scheme or asset works from the documented client. Buyers need the live requirement's CAIP-2 network identifier and asset details; providers should test every advertised option rather than treating multi-chain copy as sufficient evidence.

Why price coverage is still weak

None of the 18 MCP-server records had a supported numeric minimum in the catalog's structured price field on the observation date. Several descriptions contained provider-reported amounts or ranges, but a number embedded in prose is not automatically normalized evidence. It may apply to one tool, an old route, a free tier or a different billing unit.

This is a market opportunity. Providers that expose a current price or maximum, billing unit, scheme, network, asset and observation date become easier for agents and directories to compare. Directories should keep unknown prices unknown instead of converting missing data to free. The live 402 response remains the purchase-time source of truth.

The verification gap is larger than the discovery gap

The sample already contains many discoverable products and exact MCP endpoints, but none carried TOLL·402's settled paid-call verification flag. That does not mean the services cannot settle. It means the directory did not have the specific evidence required to claim that a real payment completed and returned a reviewed result through the represented path.

For buyers, the gap increases integration cost: each promising listing still needs a controlled first purchase. For providers, it creates a differentiation opportunity. A reproducible buyer recipe, safe sample arguments, current 402 requirement, settlement record and validated result are more convincing than adding another dozen tool names to a landing page.

MCP server, gateway, bridge or template?

The difference between 39 MCP-related entries and 18 MCP servers shows why category language matters. An x402-aware local MCP bridge helps a host buy remote APIs. A gateway may aggregate many providers. A template helps developers build. Infrastructure may handle discovery, signing or settlement. Only some entries expose a deployed MCP server that buyers connect to as the product.

These forms are all useful, but they need different evaluation. A server needs transport and tool-schema evidence. A bridge needs secure signer configuration and upstream compatibility. A gateway needs provider, routing and failure transparency. A template needs current packages and a working deployment path. Search pages that collapse them into one 'server list' make the ecosystem look larger while making buyer decisions worse.

What should buyers do with this snapshot?

Use the directory to identify capabilities and evidence gaps, then inspect the exact product architecture. Confirm whether the endpoint is remote MCP, a paid API or a bridge. Check transport support, tool schemas, current payment requirements and a safe read-only example. Start with a narrowly funded wallet and a per-request cap.

Treat a successful connection, an unpaid quote, settlement and useful output as four separate checkpoints. Stop automatic retries when a payment may have settled. Prefer providers that expose idempotency or correlation identifiers and explain paid failure behavior. The market is early enough that operational clarity is a stronger signal than brand polish.

• Shortlist by the result needed, not the number of tools advertised.
• Verify the current route, scheme, network, asset and amount before signing.
• Require human confirmation for mutating or unusually expensive first calls.

What should providers publish next?

Publish a machine-readable tool schema, safe example input, expected output, current price or maximum, billing unit and supported payment options. Add Bazaar discovery metadata where appropriate and keep it synchronized with the live MCP tool. Explain whether discovery is free, which errors are chargeable and how duplicate retries are handled.

Then make the buyer path reproducible from a clean environment. A single reviewed paid call can surface wrong methods, obsolete headers, unsupported schemes and output failures that documentation review misses. Providers that close this evidence gap will be easier for directories, agents and answer engines to recommend with precise qualifications.

Methodology and limitations

Counts were computed from the editorial seed used by the public site on July 13, 2026. MCP mentions were identified across each complete catalog record; server counts used the explicit mcp-server classification. Network counts used the structured networks array and overlap. Structured price and verification counts used their dedicated fields rather than inferring evidence from descriptions.

The sample is not every x402 or MCP service on the internet, and it changes as providers launch, move or retire. It does not measure transaction volume, revenue or uptime. The report should be read as a dated view of curated supply and evidence quality. The larger canonical resource dataset and discovery methodology explain broader coverage and source provenance.

Related directory entries

Sources and methodology

TOLL·402 distinguishes public claims, registry discovery, unpaid quote checks and settled paid-call verification. Sources below support the visible claims; presence in a registry is not treated as verification.

1. TOLL·402 MCP catalog view — Public editorial entries used to inspect MCP-related supply.
2. TOLL·402 discovery methodology — Source, normalization, evidence and limitation rules.
3. Official x402 MCP guide — Current paid-MCP architecture and discovery metadata.
4. x402 Bazaar documentation — Machine-readable discovery layer for x402 resources and MCP tools.