# Loomal > The payments layer for agentic commerce. Sellers accept x402 payments from AI agents in USDC, settled on Base per request — no API keys, no invoices. ## Product - [/how-it-works](https://loomal.ai/how-it-works): How Loomal works — connect, price, earn, over x402 - [/ways-to-sell](https://loomal.ai/ways-to-sell): Paywall API & MCP, Loomal-hosted endpoints, Shopify/WooCommerce (soon) - [/paywall](https://loomal.ai/paywall): The Paywall API & MCP — charge agents per HTTP or tool call - [/marketplace](https://loomal.ai/marketplace): Live directory of paid endpoints agents can discover and buy - [/pricing](https://loomal.ai/pricing): Free to start; credit packs; per-call fee; USDC on Base - [/use-cases](https://loomal.ai/use-cases): Ways to sell to agents ## Use cases - [Monetize an MCP server](https://loomal.ai/use-cases/monetize-an-mcp-server): Charge agents per tool call. Drop a one-line paywall on any MCP tool and get paid in USDC before the call runs. - [Monetize a research API](https://loomal.ai/use-cases/monetize-a-research-api): Turn an expensive synthesis or analysis endpoint into per-call revenue from the agents that depend on it. - [Monetize a code-execution API for agents](https://loomal.ai/use-cases/monetize-a-code-execution-api): Charge agents per run in USDC. Give agents a sandbox to execute code and bill each run before the container starts. - [Monetize a knowledge base for agents](https://loomal.ai/use-cases/monetize-a-knowledge-base): Turn your docs into a paid MCP tool or hosted endpoint. Agents query it and pay per answer in USDC. - [Monetize a PDF generation API for agents](https://loomal.ai/use-cases/monetize-a-pdf-generation-api): Charge agents per document in USDC. Turn templates and data into polished PDFs and get paid for every render. - [Monetize a recommendation API for agents](https://loomal.ai/use-cases/monetize-a-recommendation-api): Charge agents per recommendation call. Your ranking model runs after the USDC clears, priced for the work each request costs. - [Monetize a scraping API for agents](https://loomal.ai/use-cases/monetize-a-scraping-api): Charge agents per extraction in USDC. You run the proxies and parsers; the agent pays for clean structured data, one URL at a time. - [Monetize a search API for agents](https://loomal.ai/use-cases/monetize-a-search-api): Charge agents per query in USDC. Web, site, or vector search — priced per call, paid before you spend a cent on a crawl or an index hit. - [Monetize a text-to-speech API for agents](https://loomal.ai/use-cases/monetize-a-text-to-speech-api): Bill agents per character of synthesized speech. They pay USDC for the audio they generate, priced by the work your voices actually do. - [Monetize a transcription API for agents](https://loomal.ai/use-cases/monetize-a-transcription-api): Charge agents per minute of audio in USDC. Audio in, text out, billed by duration and settled before the GPU spins up. - [Monetize a translation API for agents](https://loomal.ai/use-cases/monetize-a-translation-api): Charge agents per job in USDC. Price by language pair and character count, get paid before the translation runs. - [Monetize a vector search API for agents](https://loomal.ai/use-cases/monetize-a-vector-search-api): Charge agents per query in USDC. Let agents retrieve over your proprietary corpus and pay for each lookup, not for access to the index. - [Monetize an email validation API for agents](https://loomal.ai/use-cases/monetize-an-email-validation-api): Charge agents per verification. Syntax, MX, deliverability, the works, paid in USDC one check at a time. - [Monetize an OCR API for agents](https://loomal.ai/use-cases/monetize-an-ocr-api): Charge agents per page in USDC. Documents and images in, structured text out, paid before the extraction runs. - [Paywall premium content for agents](https://loomal.ai/use-cases/paywall-premium-content): Reports, guides, structured knowledge — let agents pay per access instead of locking everything behind a human login. - [Sell a dataset to AI agents](https://loomal.ai/use-cases/sell-a-dataset-to-agents): Have a file but no backend? Upload it, set a price, and Loomal hosts and paywalls it at a URL agents can pay. - [Sell an embeddings API to agents](https://loomal.ai/use-cases/sell-embeddings-api): Charge agents per batch in USDC. Text in, vectors out, billed by the batch and paid before the encoder runs. - [Sell API access to AI agents](https://loomal.ai/use-cases/sell-api-access-to-ai-agents): Charge AI agents per request in USDC — no API keys to issue, no plans to manage, no invoices to chase. - [Sell company data to agents](https://loomal.ai/use-cases/sell-company-data-to-agents): Firmographics, filings, and corporate records — charge AI agents per record in USDC, settled on Base, no keys required. - [Sell compliance data to agents](https://loomal.ai/use-cases/sell-compliance-data-to-agents): Charge agents per screening. Sanctions, PEP, and watchlist hits returned per check, paid in USDC with a signed receipt. - [Sell crypto price data to agents](https://loomal.ai/use-cases/sell-crypto-price-data): Spot prices, on-chain metrics, and pool depth — charge AI agents per query in USDC, settled on the same chain they trade on. - [Sell geocoding & location data to agents](https://loomal.ai/use-cases/sell-location-data-to-agents): Geocode, places, and routing lookups — charge AI agents per request in USDC, settled on Base, with no key to issue. - [Sell image generation to agents](https://loomal.ai/use-cases/sell-image-generation-to-agents): Charge agents per render for your model, your fine-tune, or your house style. They pay in USDC before the GPU spins up. - [Sell KYC & verification data to agents](https://loomal.ai/use-cases/sell-verification-data-to-agents): Charge agents per identity or business verification. They pay USDC per check, you return a signed result, no contract required. - [Sell lead enrichment to agents](https://loomal.ai/use-cases/sell-enrichment-data-to-agents): Person and company enrichment, priced per record — charge AI agents in USDC, settled on Base, with no key to manage. - [Sell legal documents & templates to agents](https://loomal.ai/use-cases/sell-legal-documents-to-agents): Upload a contract template, set a price, and Loomal hosts it behind a paywall agents can pay per download. No server needed. - [Sell market data to agents](https://loomal.ai/use-cases/sell-market-data-to-agents): Charge AI agents per quote, ticker, and fundamentals pull in USDC — value that decays in seconds, priced by the call. - [Sell model inference to agents](https://loomal.ai/use-cases/sell-model-inference-to-agents): Charge agents per generation in USDC. Put your fine-tuned or specialized model behind a paywall and get paid before each forward pass. - [Sell news feeds to agents](https://loomal.ai/use-cases/sell-news-feeds-to-agents): Headlines and full articles, priced per query — charge AI agents in USDC, settled on Base, with licensing baked into the call. - [Sell real estate data to agents](https://loomal.ai/use-cases/sell-real-estate-data-to-agents): Listings, valuations, and comps — charge AI agents per lookup in USDC, settled on Base, with no key to issue. - [Sell real-time data to agents](https://loomal.ai/use-cases/sell-real-time-data): Prices, signals, availability, telemetry — charge agents per fetch for data that's only valuable while it's fresh. - [Sell research papers to agents](https://loomal.ai/use-cases/sell-research-papers-to-agents): Host your PDFs on Loomal and charge agents per access. Upload the paper, set a USDC price, and skip running a paywall yourself. - [Sell sentiment data to agents](https://loomal.ai/use-cases/sell-sentiment-data-to-agents): Social and market sentiment scores, priced per query — charge AI agents in USDC, settled on Base, no keys to manage. - [Sell sports data to agents](https://loomal.ai/use-cases/sell-sports-data-to-agents): Live scores, odds, and stats that change by the second — charge AI agents per fetch in USDC, settled on Base. - [Sell video generation to agents](https://loomal.ai/use-cases/sell-video-generation-to-agents): Bill agents per clip rendered. They pay the USDC quote up front, the render job runs, and you keep your margin on every second of output. - [Sell weather data to agents](https://loomal.ai/use-cases/sell-weather-data-to-agents): Current conditions and forecasts that go stale by the hour — charge AI agents per fetch in USDC, no keys, no plans. ## Compare - [Loomal Index vs Algorithmia what the legacy algorithm marketplaces got wrong.](https://loomal.ai/vs/algorithmia): Algorithmia and the marketplaces like it proved developers would pay per call for ML models a decade before AI agents existed. Most of them have since shut down or been acquired. Loomal Index is built on the same per-call idea — minus the parts that killed it. - [Loomal Index vs Apify open payment standard vs platform billing.](https://loomal.ai/vs/apify): Apify is a web scraping and automation platform with its own store of monetizable Actors. Loomal Index is a payment-ready index for any MCP server or API. They overlap on 'developers earning per use' — but the billing models are fundamentally different. - [Loomal Index vs AWS Marketplace protocol-native vs cloud-account-native.](https://loomal.ai/vs/aws-marketplace): AWS Marketplace sells software that deploys into AWS accounts and bills through AWS. Loomal Index sells calls to MCP servers and APIs over an open protocol, with no cloud relationship required on either side. Different buyers, different units, different rails. - [Loomal Index vs Coinbase AgentKit the wallet and the marketplace.](https://loomal.ai/vs/coinbase-agentkit): Coinbase AgentKit gives an AI agent a wallet so it can hold funds and transact onchain — including x402 payments. Loomal Index is the catalog of things that wallet can pay for. This isn't a versus; it's two halves of the same transaction. - [Loomal Index vs Composio monetization layer vs integration layer.](https://loomal.ai/vs/composio): Composio gives agent builders managed, authenticated integrations — Gmail, Slack, GitHub and more — through its SDK and MCP support. Loomal Index gives tool builders a place to list and charge per call. One serves the agent's builder; the other serves the tool's owner. - [Loomal Index vs Crossmint where checkout meets catalog.](https://loomal.ai/vs/crossmint): Crossmint builds wallet and checkout infrastructure so AI agents can buy goods, services, and APIs — with x402 support. Loomal Index is the catalog those agents buy from. Buyer-side rails, seller-side shelf: two layers, one transaction. - [Loomal Index vs Cursor Directory one editor's community vs every agent's index.](https://loomal.ai/vs/cursor-directory): Cursor Directory is a community site curating MCP servers, rules files, and prompts for people who use the Cursor editor. Loomal Index lists MCP servers for every client — and attaches a payment rail to each one. Same servers can appear in both; the jobs are different. - [Loomal Index vs Fewsats marketplace vs payment plumbing.](https://loomal.ai/vs/fewsats): Fewsats builds payment infrastructure that lets AI agents pay for digital goods and API access, with x402 and Lightning Network support. Loomal Index is a marketplace — the place where paying agents and priced listings actually meet. Plumbing and venue, not rivals. - [Loomal Index vs Glama payment infrastructure vs index.](https://loomal.ai/vs/glama): Glama is a large, well-built directory of MCP servers for humans to browse. Loomal Index is a smaller, machine-queryable index where every listing can take payment. They solve different problems — and most builders should use both. Here's the honest comparison. - [Loomal Index vs Google AP2 a marketplace vs a payments protocol.](https://loomal.ai/vs/google-ap2): Google's Agent Payments Protocol (AP2) is an open spec for authorizing agent-initiated purchases with cryptographically signed mandates, spanning cards, bank transfers, and crypto. Loomal Index is a marketplace built on a different, narrower protocol — x402. Comparing them means comparing categories first. - [Loomal Index vs Gumroad selling to agents vs selling to people.](https://loomal.ai/vs/gumroad): Gumroad is a checkout for creators selling digital products to human buyers. Loomal Index lists MCP servers, APIs, and hosted files that AI agents can discover and pay for per call via x402. Different buyer, different rails — here's how they actually compare. - [Loomal Index vs Hugging Face MCP the whole ecosystem vs one platform's catalog.](https://loomal.ai/vs/hugging-face-mcp): Hugging Face's MCP offering exposes its own hosted Spaces and models as agent-callable tools. Loomal Index covers MCP servers across every host and registry, and adds an x402 payment layer. One is a platform surface; the other is an ecosystem-wide index. - [Loomal Index vs Klavis AI open marketplace vs managed hosting.](https://loomal.ai/vs/klavis-ai): Klavis AI hosts and manages MCP servers for popular SaaS tools, with authentication handled for you. Loomal Index is an open marketplace across the wider MCP ecosystem with x402 monetization for listing owners. Curated convenience versus open coverage plus payments. - [Loomal Index vs Lemon Squeezy micropayments for agents vs billing for humans.](https://loomal.ai/vs/lemon-squeezy): Lemon Squeezy is a merchant of record handling payments, tax, and subscriptions for software sold to people. Loomal handles per-call USDC micropayments from AI agents via x402. They bill different buyers at different magnitudes — and genuinely complement each other. - [Loomal Index vs Make.com the marketplace vs the workflow canvas.](https://loomal.ai/vs/make-com): Make.com is a visual platform where humans design automations by wiring apps together. Loomal Index is a marketplace where the MCP servers and APIs those automations call can be discovered — and paid for per call by the agents executing them. Different layers of the same stack. - [Loomal Index vs mcp-get discovery and payments vs local install.](https://loomal.ai/vs/mcp-get): mcp-get is a command-line tool and directory for installing open-source MCP servers on your machine. Loomal Index covers local and remote servers alike, and adds the layer an installer can't: per-call x402 payments. A package manager and a marketplace are different things. - [Loomal Index vs mcp.so payment infrastructure vs browse index.](https://loomal.ai/vs/mcp-so): mcp.so is a large, browse-only directory of MCP servers for humans. Loomal Index is an agent-queryable index where every listing can take payment. Different audiences, different jobs — and you can use both. Here's the comparison. - [Loomal Index vs n8n Workflow Marketplace selling the tools vs selling the templates.](https://loomal.ai/vs/n8n-marketplace): n8n's marketplace sells workflow templates — the automation logic. Loomal sells access to the MCP servers and APIs those workflows call underneath, priced per call via x402. One monetizes the recipe, the other monetizes the ingredients. - [Loomal Index vs OpenRouter paying for tools vs paying for tokens.](https://loomal.ai/vs/openrouter): OpenRouter unifies access to dozens of LLMs behind one endpoint with pay-as-you-go billing. Loomal does an analogous job for the other half of an agent's spend — the MCP servers and APIs it calls as tools — settled per call via x402 instead of a prepaid balance. - [Loomal Index vs Paddle agent transactions vs SaaS billing.](https://loomal.ai/vs/paddle): Paddle is a merchant of record running global subscription billing, tax, and compliance for SaaS companies selling to humans. Loomal settles cent-scale, per-call payments from autonomous agents over x402. The transaction shapes are so different that 'versus' mostly means 'and'. - [Loomal Index vs Payman machine-to-machine vs agent-to-human.](https://loomal.ai/vs/payman): Payman is payment rails for AI agents paying humans in fiat. Loomal Index is a marketplace where agents pay APIs and MCP servers in USDC via x402. Same buyer — an agent — but a completely different transaction. Here's how they actually relate. - [Loomal Index vs Postman API Network agents that pay vs developers who test.](https://loomal.ai/vs/postman-api-network): The Postman API Network is where human developers explore and test public APIs inside Postman's GUI. Loomal Index lists APIs and MCP servers so autonomous agents can find them, get a price, and pay per call via x402. Same APIs, different consumer. - [Loomal Index vs PulseMCP a sellable listing vs an editorial entry.](https://loomal.ai/vs/pulsemcp): PulseMCP is a community-run directory tracking roughly 18,000 MCP servers, with news and use cases for the ecosystem. Loomal Index also indexes MCP servers — then adds the part PulseMCP doesn't attempt: claimable listings with x402 per-call payments. - [Loomal Index vs RapidAPI x402 per-call vs keys and plans.](https://loomal.ai/vs/rapidapi): RapidAPI is the established API marketplace: thousands of REST APIs, discovered by developers, consumed via API keys and tiered subscription plans. Loomal Index sells API access the way agents buy it — one x402-paid call at a time, no signup, no key. - [Loomal Index vs Replicate selling calls vs selling compute.](https://loomal.ai/vs/replicate): Replicate hosts open-source ML models and bills you per second of compute. Loomal Index is a marketplace where any MCP server or API — including one backed by a Replicate-hosted model — gets a per-call x402 price that agents pay in USDC. - [Loomal Index vs Skyfire open standard vs payment network.](https://loomal.ai/vs/skyfire): Skyfire is an agent identity and payments network — "KYA" identity plus payment tokens that let agents pay sellers. Loomal pairs the open x402 standard (USDC on Base) with a marketplace, so payment and discovery ship together. - [Loomal Index vs Smithery deployment vs monetization.](https://loomal.ai/vs/smithery): Smithery helps you host and deploy MCP servers. Loomal Index helps you get discovered by agents and paid per call. These aren't the same job — they're different layers of the stack, and they fit together cleanly. Here's the comparison. - [Loomal Index vs Stripe ACP tool-level micropayments vs agentic checkout.](https://loomal.ai/vs/stripe-agentic-commerce-protocol): Stripe's Agentic Commerce Protocol, developed with OpenAI, lets agents complete checkout using a merchant's existing Stripe integration. x402 — the protocol behind every Loomal listing — skips checkout entirely: the API call itself is the purchase. - [Loomal Index vs Toolhouse open marketplace vs curated runtime.](https://loomal.ai/vs/toolhouse): Toolhouse is a cloud runtime that gives agents a curated set of tools through a simple API. Loomal Index is an open marketplace where any developer lists, prices, and sells their own MCP server or API to any agent via x402. Curation vs commerce. - [Loomal Index vs Zapier selling the tools vs wiring the apps.](https://loomal.ai/vs/zapier): Zapier connects thousands of apps with no-code automations and now ships its own MCP server for AI tools. Loomal Index is the marketplace for MCP servers and APIs themselves — including connectors that compete with or complement Zapier's — sold per call via x402. ## Glossary - [Agent Orchestration](https://loomal.ai/glossary/agent-orchestration): Agent orchestration is the coordination of multiple AI agents or tool calls — sequencing, parallelizing, and managing dependencies between the steps of a multi-step task. - [Agent Wallet](https://loomal.ai/glossary/agent-wallet): An agent wallet is a blockchain wallet controlled by or on behalf of an AI agent, used to hold and spend funds — typically USDC on Base — for x402 payments. - [Agentic Commerce](https://loomal.ai/glossary/agentic-commerce): Agentic commerce is commerce conducted autonomously by AI agents — discovering, paying for, and using services without a human completing each transaction. - [AI Agent](https://loomal.ai/glossary/ai-agent): An AI agent is a system that uses a large language model to autonomously plan and execute multi-step tasks, usually by calling external tools and acting on the results. - [API Endpoint](https://loomal.ai/glossary/api-endpoint): An API endpoint is a specific URL where an API can be accessed to perform one operation, such as fetching data or triggering an action. - [API Key](https://loomal.ai/glossary/api-key): An API key is a unique secret token used to authenticate requests to an API, traditionally issued to a developer after manual signup. - [API Marketplace](https://loomal.ai/glossary/api-marketplace): An API marketplace is a platform where developers — and increasingly AI agents — discover, evaluate, and access third-party APIs and MCP servers, often with built-in billing. - [Autonomous Agent](https://loomal.ai/glossary/autonomous-agent): An autonomous agent is an AI agent that operates with minimal human oversight, making its own decisions about which tools to use, when to act, and how to spend its budget. - [Base (Ethereum L2)](https://loomal.ai/glossary/base-ethereum-l2): Base is a low-cost Ethereum Layer 2 network incubated by Coinbase, used as the settlement chain for x402 USDC payments on Loomal. - [Claimed vs Unclaimed Listing](https://loomal.ai/glossary/claimed-vs-unclaimed-listing): On Loomal, an unclaimed listing is auto-indexed from public registry data; claiming it proves ownership and unlocks editing, richer metadata, and x402 monetization. - [Context Window](https://loomal.ai/glossary/context-window): The context window is the maximum amount of text, measured in tokens, that an LLM can process at once — including prompts, conversation history, and tool results. - [Ed25519 Signed Receipts](https://loomal.ai/glossary/ed25519-signature): Ed25519 signed receipts are tamper-proof proofs of payment or access, produced with the Ed25519 elliptic-curve signature algorithm and verifiable by anyone holding the signer's public key. - [Embedding](https://loomal.ai/glossary/embedding): An embedding is a numerical vector that represents text, images, or other data so that semantically similar items end up close together in vector space. - [Facilitator (x402)](https://loomal.ai/glossary/x402-facilitator): An x402 facilitator is a service that verifies and settles x402 payments on behalf of a resource server, so the server needs no blockchain infrastructure of its own. - [Gas Fees](https://loomal.ai/glossary/gas-fees): Gas fees are the transaction fees a blockchain network charges to process and confirm a transaction, paid to the validators that execute it. - [HTTP 402 Payment Required](https://loomal.ai/glossary/http-402-payment-required): HTTP 402 Payment Required is the long-reserved HTTP status code signaling that a resource requires payment before access — the foundation the x402 protocol is built on. - [JSON-RPC](https://loomal.ai/glossary/json-rpc): JSON-RPC is a lightweight remote procedure call protocol encoded in JSON, and the wire format underlying all Model Context Protocol communication. - [LLM (Large Language Model)](https://loomal.ai/glossary/large-language-model): A large language model (LLM) is a neural network trained on vast text data that can understand and generate human-like language — and, increasingly, decide which tools to call. - [MCP Client](https://loomal.ai/glossary/mcp-client): An MCP client is the AI application — Claude Desktop, Cursor, VS Code, and others — that connects to MCP servers and calls their tools on a user's behalf. - [MCP Manifest](https://loomal.ai/glossary/mcp-manifest): An MCP manifest is a metadata file — typically server.json — that describes an MCP server's name, version, packages, and capabilities so registries can index it. - [MCP Monetization](https://loomal.ai/glossary/mcp-monetization): MCP monetization is the practice of adding a per-call payment gate to Model Context Protocol tool registrations so that AI agents pay before the tool handler runs. - [MCP Registry](https://loomal.ai/glossary/mcp-registry): An MCP registry is a catalog of published MCP servers — including the official registry maintained by the MCP project and community indexes built on top of it. - [MCP Server](https://loomal.ai/glossary/mcp-server): An MCP server is a program that exposes tools, resources, or prompts to AI applications using the Model Context Protocol. - [MCPB (MCP Bundle)](https://loomal.ai/glossary/mcpb-mcp-bundle): MCPB (MCP Bundle) is a packaging format that distributes an MCP server as a single installable file, much like a browser extension package. - [Micropayments](https://loomal.ai/glossary/micropayments): Micropayments are very small payments — often a cent or less — made for individual units of consumption, such as a single API call or document lookup. - [Model Context Protocol (MCP)](https://loomal.ai/glossary/model-context-protocol): The Model Context Protocol (MCP) is an open standard from Anthropic that lets AI applications connect to external tools, data sources, and APIs through one common interface. - [OAuth](https://loomal.ai/glossary/oauth): OAuth is an open standard for delegated authorization that lets an application access a user's resources on another service without ever seeing the user's password. - [Open Source vs. Hosted MCP Server](https://loomal.ai/glossary/open-source-vs-hosted-mcp-server): The distinction between an MCP server you download and run yourself from source code, and one operated by its author as a managed remote endpoint you simply connect to. - [Pay-Per-Call API](https://loomal.ai/glossary/pay-per-call-api): A pay-per-call API is an API priced so that each individual request is billed separately — often via x402 — instead of through a subscription or pre-purchased credits. - [Pay-Per-Use Pricing](https://loomal.ai/glossary/pay-per-use-pricing): Pay-per-use pricing is a model that charges based on actual consumption — per call, per token, per document — rather than a flat subscription fee. - [Payment Channel](https://loomal.ai/glossary/payment-channel): A payment channel is an off-chain mechanism that lets two parties exchange many small payments while recording only the opening and closing balances on-chain. - [Prompts (MCP)](https://loomal.ai/glossary/mcp-prompts): Prompts in MCP are reusable, parameterized prompt templates that a server exposes to clients, packaging a recommended workflow with the right framing and arguments built in. - [RAG (Retrieval-Augmented Generation)](https://loomal.ai/glossary/rag-retrieval-augmented-generation): Retrieval-Augmented Generation (RAG) is a technique that retrieves relevant external information and feeds it into an LLM's context before the model generates a response. - [Rate Limiting](https://loomal.ai/glossary/rate-limiting): Rate limiting restricts how many requests a client can make to an API within a given time period, protecting the service from overload and abuse. - [Resources (MCP)](https://loomal.ai/glossary/mcp-resources): Resources are the MCP primitive that lets servers expose readable data — files, database rows, API responses — identified by URIs and loadable into the model's context. - [Roots (MCP)](https://loomal.ai/glossary/roots-mcp): Roots are an MCP mechanism by which a client tells a server which directories or URIs it is allowed to operate within. - [Sampling (MCP)](https://loomal.ai/glossary/sampling-mcp): Sampling is an MCP feature that lets a server request an LLM completion from the connected client, enabling agentic behavior inside the server without its own model access. - [SDK (Software Development Kit)](https://loomal.ai/glossary/sdk-software-development-kit): An SDK is a collection of libraries, tools, code samples, and documentation that helps developers build against a specific platform or protocol. - [Settlement Layer](https://loomal.ai/glossary/settlement-layer): A settlement layer is the underlying blockchain or network where a payment is finally and irreversibly recorded. - [SSE (Server-Sent Events) Transport](https://loomal.ai/glossary/sse-transport): SSE transport is an earlier MCP remote transport that paired a long-lived Server-Sent Events stream for server-to-client messages with HTTP POST for client-to-server messages. - [Stablecoin](https://loomal.ai/glossary/stablecoin): A stablecoin is a cryptocurrency designed to maintain a stable value relative to a reference asset, usually the US dollar. - [Stdio Transport](https://loomal.ai/glossary/stdio-transport): Stdio transport is a local MCP transport where the client launches the server as a subprocess and exchanges messages over standard input and output. - [Streamable HTTP Transport](https://loomal.ai/glossary/streamable-http-transport): Streamable HTTP transport is the current MCP transport for remote servers, using HTTP POST with optional server-sent event streaming over a single endpoint. - [Tool Calling (Function Calling)](https://loomal.ai/glossary/tool-calling): Tool calling is the mechanism by which an LLM selects and invokes an external function or MCP tool to complete a task. - [Tool Use (LLM)](https://loomal.ai/glossary/tool-use-llm): Tool use is the general capability of a large language model to invoke external functions or APIs as part of generating a response. - [USDC](https://loomal.ai/glossary/usdc): USDC is a US dollar-pegged stablecoin issued by Circle, used as the default settlement currency for x402 payments. - [Vector Database](https://loomal.ai/glossary/vector-database): A vector database is a database optimized for storing and searching high-dimensional embeddings, the backbone of semantic search and RAG. - [Webhook](https://loomal.ai/glossary/webhook): A webhook is an HTTP callback that a server sends to a configured URL when a specific event occurs. - [x402](https://loomal.ai/glossary/x402): x402 is an open, HTTP-native payment protocol that lets any server charge any client per request using HTTP status code 402 (Payment Required). - [x402 Protocol](https://loomal.ai/glossary/x402-protocol): The x402 protocol is an open payment standard that uses the HTTP 402 status code to let AI agents pay for API and MCP tool access automatically, settled in stablecoins. ## Blog - [Agents Can Pay Now. We Built the Rails.](https://loomal.ai/blog/introducing-loomal): The internet was never built for software to pay software. Loomal is the payments layer for the agent internet — drop a paywall on any API or MCP server and charge agents per call in USDC. ## Developers - [Docs](https://docs.loomal.ai): SDK, MCP, accept-payments guides - [x402 discovery feed](https://api.loomal.ai/.well-known/x402-discovery.json): machine-readable marketplace listings - [Console](https://console.loomal.ai): create endpoints, set prices, view payments --- # Use cases ## Monetize an MCP server URL: https://loomal.ai/use-cases/monetize-an-mcp-server MCP is becoming the default way agents reach tools — and most MCP servers are given away for free because there was no clean way to charge for a single tool call. Loomal closes that gap. Wrap a tool with a price and the agent pays per invocation over x402, in the same protocol it already speaks. No separate billing portal, no key exchange. ### Charge per invocation, not per seat Your most expensive tools — a search, a model call, a data pull — cost you money every time they run. Per-invocation pricing passes that cost through transparently: the agent pays for the call it makes, nothing more. Set different prices per tool. A cheap lookup can be a tenth of a cent; an expensive synthesis can be a dollar. ### One line on the tool Add a price to the tool definition. When an agent invokes it, Loomal serves the x402 challenge, the agent's client signs a USDC authorization, and the tool runs only after settlement. Most MCP clients — Claude, Cursor, and others — handle the payment handshake for the agent automatically. ### Get discovered Listed tools appear in the Loomal marketplace and the open x402 discovery feed, so agents can find and pay for them without a human ever wiring up an integration. Funds settle to your non-custodial wallet on Base, with a signed receipt per call. ## Monetize a research API URL: https://loomal.ai/use-cases/monetize-a-research-api Research and analysis endpoints are expensive to run: model inference, third-party data, compute. Giving them away to agents that hammer them is unsustainable, but gating them behind enterprise sales loses the long tail of agent demand. Per-call pricing lets every agent pay for exactly the analysis it requests. Loomal handles the payment so you can focus on the output. ### Charge for the work, not a contract Agents arrive without a procurement process. They want one report, one synthesis, one scored result — and they'll pay for it if the price is clear at request time. Set the price to cover your compute plus margin. Expensive jobs cost more; cheap lookups cost less. ### Wrap the endpoint Drop requirePayment on your research handler. The agent pays the quoted price in USDC, then your endpoint runs and returns the result, with a signed receipt attached. Refunds, when you choose to issue them, are a separate signed call recorded in your activity log. ### Provable revenue Every settled call lands USDC in your wallet on Base and produces an Ed25519 receipt. Your income is auditable down to the request. Webhooks notify your systems on each sale so you can reconcile usage and revenue automatically. ## Monetize a code-execution API for agents URL: https://loomal.ai/use-cases/monetize-a-code-execution-api Agents write code constantly, and they need somewhere safe to run it: a data transform, a quick script, a generated function under test. A sandbox that spins up a clean container per run is real infrastructure, and agents want to pay for the runs they trigger rather than reserve capacity. Loomal lets your execution service charge per run in USDC over x402. The agent submits code and inputs, pays for the run, and gets back stdout, results, and exit status. The container only boots after the payment settles. ### Bill per run, or by the compute it burns A flat per-run price is simple and predictable: every execution costs the same. It fits agents that run short scripts and want no surprises. For heavier work you can price by limits. A run with more CPU, memory, or a longer timeout can carry a higher charge, so a quick eval stays cheap while a long-running job pays for the capacity it holds. ### Settle before the container boots Wrap your run handler with requirePayment so the sandbox only provisions after payment. The agent sends code and a runtime, Loomal runs the x402 handshake and settles on Base, and your executor returns the output. ### Be the sandbox agents reach for Your execution service lists in the Loomal marketplace and the x402 discovery feed, with supported runtimes and limits in the listing. An agent that needs to run generated code finds your endpoint and pays per run with no onboarding. Settlement is USDC on Base to a non-custodial wallet, and each run produces a signed receipt so every execution you billed is provable. ## Monetize a knowledge base for agents URL: https://loomal.ai/use-cases/monetize-a-knowledge-base You've spent years building documentation, runbooks, or a curated knowledge base. Agents will pay to query it, but only if there's a clean way to charge per answer instead of giving the whole thing away in a scrape. Loomal turns a knowledge base into a paid surface two ways: expose it as an MCP tool agents call directly, or upload your content to a Loomal-hosted endpoint and let us serve it behind the paywall. Either way, agents pay per query in USDC. ### Sell answers, not access to a dump A flat data export gets copied once and never bought again. A query interface, priced per call, keeps paying: every time an agent needs an answer from your knowledge base, it pays for that retrieval. This fits how agents work. They don't want your whole corpus; they want the one passage or synthesized answer relevant to the task in front of them, and they'll pay a few cents for it. ### Expose it as a paid MCP tool Define a query tool on your MCP server with a price. When an agent invokes it, Loomal serves the x402 challenge, the agent's client signs the USDC authorization, and your retrieval runs only after settlement. Most MCP clients handle the handshake automatically. No backend of your own? Upload the docs to a Loomal-hosted endpoint instead and we serve the queries behind the same paywall. ### Discoverable expertise List the tool or hosted endpoint and it appears in the Loomal marketplace and the x402 discovery feed. An agent stuck on a problem your docs already answer can find your knowledge base and pay to query it without a human wiring anything up. Every settled query pays USDC into your non-custodial wallet on Base with a signed receipt, so your documentation becomes a metered revenue stream. ## Monetize a PDF generation API for agents URL: https://loomal.ai/use-cases/monetize-a-pdf-generation-api Agents produce documents all day: invoices, reports, contracts, certificates, statements. Rendering them well takes a real engine and a fonts-and-templates pipeline, and the agent wants to pay for each document it generates rather than license a platform. Loomal lets your PDF service charge per render in USDC over x402. The agent sends a template and data, pays for the document, and gets back a finished file. Your render engine runs only on renders that have settled. ### Charge for the document, not a license Per-document pricing is clean for both sides: one render, one charge. An agent generating a single invoice pays for one invoice; an agent batching a thousand statements pays for a thousand renders. You can price by complexity. A one-page receipt costs less than a multi-page report with charts, tables, and embedded assets, so heavy documents pay for the work they take. ### Render after the payment clears Wrap your render handler with requirePayment. The agent posts a template id and data, Loomal quotes the price and runs the x402 handshake, settlement clears on Base, and your engine returns the finished PDF. ### Get found by document agents Your PDF service lists in the Loomal marketplace and the x402 discovery feed, with template types and output options in the listing. An agent that needs a rendered document finds your endpoint and pays per render with no setup. Settlement is USDC on Base to a non-custodial wallet, and each render produces a signed receipt so every document you billed is provable. ## Monetize a recommendation API for agents URL: https://loomal.ai/use-cases/monetize-a-recommendation-api A good recommendation engine is expensive to run and valuable to call. Agents building shopping assistants, content feeds, or matching flows want personalized rankings on demand, and a free endpoint just funds someone else's product with your compute. Loomal lets you charge per recommendation call in USDC. The agent sends its context, pays the quote, and your ranking model runs and returns results with a signed receipt. No API key to issue, no usage tier to negotiate. ### Charge for the ranking, not a license Agents don't license recommendation engines; they call them. Per-call pricing matches that: each personalized ranking request pays for the inference and the candidate retrieval it triggers, so your cost is covered on every call regardless of who's asking. Bigger requests can cost more. A short top-5 pull is cheaper than a deep ranking over a large candidate set; read the request and price it before the model runs. ### Wrap the ranking endpoint Drop requirePayment on your recommendation route. The agent settles the USDC amount, your model scores the candidates against the supplied context, and the ranked results return with a signed receipt. No key handoff, no metered invoice to reconcile later. ### Found by the agents that need it List the endpoint and it appears in the Loomal marketplace and the x402 discovery feed. An agent building a shopping flow or a content feed can find your ranking model and start paying per call without a human wiring up an integration. Every settled call pays USDC into your non-custodial wallet on Base, so steady agent traffic becomes steady revenue, reconciled by a signed receipt per request. ## Monetize a scraping API for agents URL: https://loomal.ai/use-cases/monetize-a-scraping-api Scraping is expensive to run well. Rotating proxies, headless browsers, CAPTCHA solving, and parsers that survive layout changes all cost money on every page you fetch. Agents want that structured output but they want it on demand, not behind a sales call and a monthly commitment. Loomal lets your extraction endpoint charge per call in USDC. The agent points you at a URL, pays over x402, and gets back clean structured data. Your proxy and parser bill is covered before the job starts. ### Bill per page, per record, or per render A static HTML fetch is cheap; a JavaScript-heavy page that needs a full browser render and a CAPTCHA solve is not. Per-extraction pricing lets you charge for the real cost of getting that page open and parsed. You can also price by output. A flat fee per URL works for simple jobs, while a per-record price fits listings, search-results pages, and feeds where one fetch yields many rows. ### Charge before the crawler fires Wrap your extraction handler with requirePayment so the proxy and browser only spin up after settlement. The agent sends the target URL and extraction schema, pays in USDC, and your scraper returns normalized JSON. ### List once, get scraped jobs forever Your scraping service shows up in the Loomal marketplace and the x402 discovery feed. An agent that needs structured data from the open web can discover your endpoint, see the price, and start sending jobs with no onboarding. Settlement is USDC on Base into a non-custodial wallet, with a signed receipt per extraction so every job you ran is provable. ## Monetize a search API for agents URL: https://loomal.ai/use-cases/monetize-a-search-api Search is the first thing an agent reaches for when it needs fresh facts. Every query you serve costs you something real — a crawl, an index lookup, a re-rank pass — but the standard playbook of free tiers and monthly keys leaves you eating that cost while bots hammer your endpoint. Loomal lets your search endpoint quote a price and collect USDC before it runs the query. The agent asks, pays in the same round trip over x402, and gets ranked results. You charge for exactly the work you do. ### Price each query for what it actually costs A keyword lookup against a warm index is cheap. A live web crawl with re-ranking and snippet generation is not. Per-query pricing lets you reflect that: charge a fraction of a cent for a cached hit and more for a deep search that touches an LLM re-ranker. You can split pricing by mode too. Site search over your own corpus, broad web search, and vector similarity search can each carry their own per-call price on the same service. ### Pay-then-search in one request Wrap your search handler with requirePayment. The first call returns a 402 with the price; the agent signs a USDC authorization and retries; Loomal settles on Base and your search code runs only after the money clears. ### Get found by the agents doing the searching Your search service lists in the Loomal marketplace and the x402 discovery feed, so an agent that needs results over your domain can find the endpoint, read the price, and pay without a human ever provisioning a key. Revenue settles in USDC to a non-custodial wallet on Base, and every paid query leaves a signed receipt you can verify offline. ## Monetize a text-to-speech API for agents URL: https://loomal.ai/use-cases/monetize-a-text-to-speech-api Text-to-speech bills naturally by the character, and agents generate a lot of characters. A narration agent, a voice-assistant builder, or an audiobook pipeline can run your synthesis endpoint nonstop, and a flat free tier never covers the inference. Loomal lets you charge per request, priced off the exact text length, in USDC. The agent pays before the audio renders, so every second of speech you produce is paid for. ### Per-character pricing that matches your cost Your inference cost tracks the length of the input, so your price should too. Count the characters in the request body and quote a price before synthesis runs. A one-line notification costs a sliver of a cent; a full chapter costs more, in proportion. Premium and cloned voices can carry their own rate. Read the requested voice and price it accordingly, so your highest-quality output earns the margin it deserves. ### Charge, then synthesize Wrap the synthesis route so the agent settles payment first. Once the USDC authorization clears, your model renders the audio and returns it with a signed receipt. No key exchange, no metered billing dashboard to reconcile. ### Discoverable voices List your endpoint and it surfaces in the Loomal marketplace and the x402 discovery feed. An agent looking for a specific accent, language, or branded voice can find yours and start paying per synthesis without a human in the loop. Every settled call deposits USDC to your non-custodial wallet on Base, so a popular voice turns into steady revenue instead of an inference bill. ## Monetize a transcription API for agents URL: https://loomal.ai/use-cases/monetize-a-transcription-api Transcription is GPU time you pay for by the second. An agent processing a meeting recording, a podcast, or a voicemail wants the text now and wants to pay for the minutes it actually sends, not negotiate a plan sized for someone else's volume. Loomal lets your speech-to-text endpoint charge by audio duration in USDC over x402. The agent uploads the clip, pays per minute, and gets back a transcript. Your GPU cost is covered before the job runs. ### Bill by the minute, not by the month Per-minute pricing maps directly onto your cost: a thirty-second clip is cheap, a two-hour recording is not, and the agent pays in proportion to the audio it submitted. No idle seats, no minimum spend. You can layer in options. Speaker diarization, word-level timestamps, and translation can each add to the per-minute rate, so callers pay for the depth they ask for. ### Settle on duration before the model runs Read the audio length from the upload, quote a price per minute, and wrap the handler with requirePayment. The agent pays the quoted USDC amount, Loomal settles on Base, and only then does your transcription model start. ### Show up where agents look for speech-to-text Your transcription service lists in the Loomal marketplace and the x402 discovery feed, with supported formats and languages in the listing. An agent with audio to process finds you, reads the per-minute price, and pays without onboarding. Revenue settles in USDC on Base to a non-custodial wallet, with a signed receipt per job so every minute you billed is auditable. ## Monetize a translation API for agents URL: https://loomal.ai/use-cases/monetize-a-translation-api Agents handling multilingual workflows need translation on tap: a support reply in German, a product description in Japanese, a document localized into a dozen languages at once. Each request is short-lived and the agent wants to pay for that one job, not sign up for a tier. Loomal lets your translation endpoint quote a price per job and collect USDC over x402 before any tokens are spent. The agent sends text and a target language, pays inline, and gets the translation back. ### Price by length and language pair Translation cost scales with characters and with how hard the language pair is. A short string between two high-resource languages is cheap; a long technical document into a low-resource language costs more. Per-job pricing lets you set the price from the actual payload. Compute the price in your handler from the character count and the pair, then quote it. The agent sees a number tied to the real job, not a flat rate that under- or over-charges every time. ### Quote per job, settle in one round trip Wrap your translate handler with requirePayment and derive the price from the request body. Loomal returns the 402 with that amount, the agent signs a USDC authorization, and your model call runs only after settlement on Base. ### Be the endpoint agents reach for Your translation service lists in the Loomal marketplace and the x402 discovery feed, with your supported language pairs as part of the listing. Agents needing a specific pair can find you and pay per job without any setup. Funds settle in USDC on Base to a non-custodial wallet, and each translated job carries a signed receipt for clean accounting. ## Monetize a vector search API for agents URL: https://loomal.ai/use-cases/monetize-a-vector-search-api You built and indexed a corpus worth searching: a knowledge base, a research archive, a domain-specific document set. Agents doing retrieval-augmented work would pay to query it, but you do not want to hand over the raw data or run a key-and-quota system to gate it. Loomal lets you charge per query against your vector index in USDC over x402. The agent sends a query vector or text, pays for the lookup, and gets back the top matches. The corpus stays yours; only the answers go out. ### Sell retrieval without selling the data Per-query pricing lets agents tap your corpus one lookup at a time. They never get a dump of the index; they pay for a ranked set of matches against their query and nothing more. Your data stays behind the endpoint. You can price by result depth. Returning the top three matches can cost less than a top-fifty retrieval with full payloads and metadata, so callers pay for the breadth they pull. ### Pay per lookup, then retrieve Wrap your retrieval handler with requirePayment. The agent submits a query and a top-k, Loomal quotes the price and runs the x402 handshake, settlement clears on Base, and your index returns the matches. ### Make your corpus discoverable Your retrieval service lists in the Loomal marketplace and the x402 discovery feed, described by domain and coverage. An agent that needs grounded context from your kind of corpus finds the endpoint and pays per query without an integration. Revenue settles in USDC on Base to a non-custodial wallet, and every query produces a signed receipt so your retrieval traffic is auditable. ## Monetize an email validation API for agents URL: https://loomal.ai/use-cases/monetize-an-email-validation-api Email validation is a per-check business. Agents cleaning lists, qualifying leads, or guarding signup flows want one answer at a time: is this address real and deliverable. They don't want a monthly plan they'll outgrow or underuse. Loomal lets you charge for each check in USDC. The agent pays the quote, your validator runs its MX, syntax, and deliverability logic, and the verdict comes back with a signed receipt. No API key to provision, no credit packs to track. ### One check, one price Per-check pricing fits how validation is actually used. A bulk cleaning job pays for every address it submits; a single signup guard pays for one. Either way the price is clear before the lookup runs and your cost per query is covered. You can tier it: a fast syntax-and-MX check costs less than a full deliverability probe that pings the mail server. Read the requested depth and quote accordingly. ### Wrap the validator Put requirePayment on your check endpoint. The agent settles the USDC amount, your validation pipeline runs, and the structured result returns. There's no key handoff and no usage meter to reconcile at the end of the month. ### Found in the flow of agent work Your endpoint appears in the Loomal marketplace and the x402 discovery feed, so an agent in the middle of cleaning a contact list can find a validation tool and pay for it inline, without a human signing up first. Each settled check pays USDC into your non-custodial wallet on Base. High-volume cleaning jobs become high-volume revenue, settled in seconds. ## Monetize an OCR API for agents URL: https://loomal.ai/use-cases/monetize-an-ocr-api Agents that process invoices, contracts, receipts, and scanned forms need OCR they can call mid-task. Each document is a one-off, and the agent wants to pay for the pages it sends rather than commit to a tier it will mostly waste. Loomal lets your OCR endpoint charge per page in USDC over x402. The agent uploads a document, pays for the page count, and gets back structured text and fields. Your extraction pipeline is paid for before it touches the file. ### Price by the page, scale by the document A single receipt and a hundred-page contract should not cost the same. Per-page pricing scales the charge with the document so a small job is cheap and a large one pays its way. You can price tiers of extraction too. Plain text recognition is the base rate; layout-aware parsing, table extraction, and key-value field detection can each add to the per-page price. ### Charge on page count, then extract Detect the page count from the upload, quote a price, and gate the handler with requirePayment. Loomal returns the 402, the agent signs a USDC authorization, settlement clears on Base, and your OCR pipeline runs. ### Be discoverable to document agents Your OCR service lists in the Loomal marketplace and the x402 discovery feed, with supported file types and extraction modes in the listing. An agent with documents to read finds your endpoint and pays per page with no setup. Settlement is USDC on Base to a non-custodial wallet, and each extracted document carries a signed receipt so your billing is provable. ## Paywall premium content for agents URL: https://loomal.ai/use-cases/paywall-premium-content Premium content is usually gated by a login and a subscription — a wall agents can't climb. The result is that the fastest-growing class of readers, autonomous agents, simply can't buy what you publish. Loomal lets an agent pay for a single piece of content in USDC and get it immediately, with no account to create and no plan to join. ### Sell the unit, not the subscription Agents want the one article, the one report, the one answer. Pricing per access meets that intent and unlocks revenue from readers who would never sign up for a plan. You keep your human subscription product exactly as-is; the agent paywall sits alongside it. ### Host it or wrap it If you have a backend, wrap the content route with requirePayment. If you don't, upload the file to a Loomal-hosted endpoint and we serve it behind the paywall for you. Either way the agent pays the x402 challenge in USDC and receives the content in the same exchange. ### Settled and provable Each sale lands USDC in your wallet on Base and returns a signed receipt. Webhooks let your CMS or analytics record every agent purchase. List it and agents can discover and buy it through the marketplace without you lifting a finger. ## Sell a dataset to AI agents URL: https://loomal.ai/use-cases/sell-a-dataset-to-agents Not everything worth selling sits behind an API. A curated dataset, a research PDF, a model checkpoint, a structured export — agents will pay for these too, if there's a clean way to charge. With Loomal-hosted endpoints you don't need a server. Upload the file or paste the JSON, set a USDC price, and Loomal serves it behind an x402 paywall at a stable URL. ### No server, no DevOps Hosting is the part that usually kills these ideas. Loomal removes it: your content is served from api.loomal.ai/h/your-slug, and we handle delivery, the paywall, and settlement. Update or re-price it anytime from the console. ### Priced per download Each time an agent pays the challenge, it gets the file and you get the USDC. A tenth of a cent for a small lookup, more for a premium export — you decide. Because it's standard x402, any agent can buy it without a bespoke integration. ### Discoverable by default Hosted listings show up in the marketplace and the discovery feed, so agents looking for exactly your data can find and pay for it on their own. Every sale settles to your non-custodial wallet on Base with a signed receipt. ## Sell an embeddings API to agents URL: https://loomal.ai/use-cases/sell-embeddings-api Agents building retrieval pipelines embed constantly: chunking a document, vectorizing a query, re-indexing a corpus. Each call is a burst of encoder time, and the agent wants to pay for the batch it just sent rather than hold a subscription. Loomal lets your embeddings endpoint charge per batch in USDC over x402. The agent posts a list of texts, pays for the batch, and gets vectors back. Your encoder runs only on calls that have already settled. ### Bill the batch, not the seat Embedding cost scales with how many items and tokens you encode. Per-batch pricing charges for the actual payload: a handful of short strings is cheap, a thousand long chunks costs more, and the agent pays in proportion either way. If you serve several embedding models at different dimensions or quality levels, give each its own per-batch price on its own route so callers pick the tradeoff they want. ### Quote on batch size, settle in one trip Compute the price from the number of items in the request, wrap the handler with requirePayment, and let Loomal run the x402 handshake. After settlement on Base, your encoder produces the vectors. ### Let retrieval agents find your encoder Your embeddings service lists in the Loomal marketplace and the x402 discovery feed, with model name, dimension, and price in the listing. An agent assembling a vector pipeline can find your encoder and pay per batch with no setup. Settlement is USDC on Base to a non-custodial wallet, and each batch leaves a signed receipt so your usage and revenue are provable. ## Sell API access to AI agents URL: https://loomal.ai/use-cases/sell-api-access-to-ai-agents AI agents now call APIs faster and in higher volume than any human ever could. The old model — sign up, get a key, pick a monthly plan — was built for people, and it breaks the moment an autonomous agent shows up wanting one call right now. Loomal lets your API charge agents per request over the x402 protocol. The agent discovers the price, pays in USDC, and gets the response — all in a single round trip. You add a few lines of middleware and keep doing what you already do. ### Why per-call beats subscriptions for agents An agent rarely wants a relationship with your service. It wants one answer, once, and it wants to pay for exactly that. Subscriptions force it to over-commit; free tiers get abused; manual key provisioning can't happen at machine speed. Per-call pricing matches what the agent actually consumes. A tenth of a cent or a dollar per request — you set it — billed in real time. No seats, no minimums, no churn. ### How it works Wrap any HTTP handler with requirePayment. On the first hit Loomal returns a 402 with the price; the agent signs a USDC authorization and retries; Loomal verifies and settles the transfer on Base and returns a signed receipt. There are no keys to issue or rotate. Authentication and payment happen together in the x402 handshake. ### What you get paid in Settlement is in USDC on Base, directly to a non-custodial wallet Loomal provisions for your project. Funds land in seconds and you can cash out to any address anytime — Loomal never holds your money. Every settled call produces an Ed25519 receipt you can verify offline, so your revenue is provable and auditable. ## Sell company data to agents URL: https://loomal.ai/use-cases/sell-company-data-to-agents An agent researching a company wants one record: this firm's firmographics, that filing, these officers. It rarely needs your whole database, and it cannot wait for a sales call to get access. Company data is a per-record business, and agents make that obvious. Loomal lets your firmographics or filings dataset charge agents per record over x402. The agent reads the price, signs USDC, and gets the record in one round trip — settled on Base in seconds, with no API key to provision and no contract to sign. ### The record is the unit of value A due-diligence agent looking up a single acquisition target gets nothing from a year of bulk access. It wants one firmographic profile or one filing, and it should pay for that record alone. Per-record pricing aligns the charge with the lookup the agent actually performs. This also opens the long tail. Buyers who would never sign an enterprise data contract will happily pay a few cents for the one company they care about, so you monetize demand that a subscription model leaves on the table. ### Price firmographics and filings per record A basic firmographic record and a parsed regulatory filing carry different value. Wrap each route with requirePayment and set the price per record. Loomal returns a 402, verifies the USDC authorization, and settles before your handler returns the data. ### Discoverable to research agents Publish your firmographics and filings endpoints to the Loomal marketplace and they appear in the discovery feed agents browse when they need a company data source. The agent finds your endpoint, reads the price, and pays per record — no key, no signup, no human in the loop. Settlement is USDC on Base into a non-custodial wallet Loomal provisions for your project. Funds arrive in seconds, every settled record carries a verifiable receipt, and Loomal never holds your money. ## Sell compliance data to agents URL: https://loomal.ai/use-cases/sell-compliance-data-to-agents Sanctions, PEP, and adverse-media screening is consumed one name at a time. An agent clearing a transaction or onboarding a counterparty needs a single screening answer, fast, and shouldn't have to sit through a sales cycle to get it. Loomal lets you sell each screening in USDC. The agent submits a name or entity, pays the quote, and your watchlist logic returns the hits with a signed receipt. No contract, no key provisioning, no annual minimum. ### Screening priced per check Each screening costs you data licensing and matching work, so charge for each one. An agent running a single counterparty check pays for that check; an agent batch-screening a payment file pays per name. The price is set before the lookup runs. Tier it by depth: a sanctions-list match is cheaper than a combined sanctions, PEP, and adverse-media sweep. Read the requested scope and quote the matching price. ### Wrap the screening endpoint Add requirePayment to your screening route. The agent settles the USDC amount, your matching engine runs against the lists, and the result returns with the hits and a signed receipt. There's no key handoff and no metered invoice to reconcile. ### A signed trail for every screening Compliance work needs proof. Every settled screening produces an Ed25519 receipt and an entry in your activity log, with USDC landing in your non-custodial wallet on Base. The record of who paid for which check is auditable down to the request. List the endpoint and it appears in the Loomal marketplace and discovery feed, so agents that need screening can find and pay for it without anyone signing a data agreement first. ## Sell crypto price data to agents URL: https://loomal.ai/use-cases/sell-crypto-price-data Crypto agents are some of the heaviest data consumers in the wild. Arbitrage bots, portfolio rebalancers, and on-chain analysts all need prices and metrics constantly, and they already hold USDC. They are wallets first and users second. Loomal turns that into revenue. Your price feed charges per query over x402, the agent pays in USDC, and settlement happens on Base — the same kind of rail the agent already operates on. No keys, no signup, no waiting for a human to approve an account. ### Agents that hold USDC are the ideal buyer Most data monetization fails because the buyer has to set up billing. Crypto agents skip that entirely. They are funded, they sign transactions natively, and paying a tenth of a cent for a spot price is something they can do thousands of times an hour without a human in the loop. Because settlement is USDC on Base, there is no currency conversion, no card network, and no chargeback risk. The agent pays in the asset it already manages, and you receive it directly. ### Meter spot, depth, and on-chain reads separately A spot price and a deep on-chain query cost you different amounts to serve, so price them differently. Wrap each route with requirePayment, and Loomal returns a 402, verifies the USDC authorization, and settles before your handler responds. ### Discovery for trading agents List your feed in the Loomal marketplace and it surfaces in the discovery feed that agents scan when they need a price oracle or metrics source. An agent finds the endpoint, reads the price, and starts paying — no API key issued, no plan chosen. Settlement lands in seconds in a non-custodial wallet Loomal provisions for your project. Every settled query produces an Ed25519 receipt you can verify offline, so your on-chain revenue is provable end to end. ## Sell geocoding & location data to agents URL: https://loomal.ai/use-cases/sell-location-data-to-agents Location is a per-lookup business by nature. An agent geocodes one address, asks for places near a point, or routes between two stops. Each is a discrete request with a discrete answer, and that maps directly onto charging per call. Loomal lets your geocoder, places index, or routing engine charge agents per request over x402. The agent reads the price, signs USDC, and gets the result in one round trip — settled on Base in seconds, with no API key to provision and no plan to pick. ### Each lookup is a clean unit to bill Forward geocode, reverse geocode, nearby search, and route calculation are all naturally atomic. There is no session to maintain and no state to carry between calls, so each one stands alone as something to price and settle on its own. An agent building an itinerary might geocode a handful of stops, then request one optimized route. Per-call billing charges for precisely those operations instead of forcing a monthly tier sized for traffic the agent may never generate again. ### Set a rate per operation Geocoding is cheap to serve; multi-stop route optimization is not. Wrap each route with requirePayment and give it the right price. Loomal returns a 402, verifies the USDC authorization, and settles before your handler returns the coordinates or route. ### Discoverable to agents planning in space Publish your geocoding and routing endpoints to the Loomal marketplace and they surface in the discovery feed agents search when they need to turn an address into coordinates or plan a route. The agent finds your endpoint, reads the price, and pays — no key, no onboarding. Settlement is USDC on Base into a non-custodial wallet Loomal provisions for your project. Funds land in seconds, every settled lookup carries a verifiable receipt, and Loomal never takes custody of your money. ## Sell image generation to agents URL: https://loomal.ai/use-cases/sell-image-generation-to-agents Every render costs you GPU time. When agents start calling your image endpoint in a loop, a free tier turns into a bill you can't recover. Per-render pricing puts the cost back where it belongs: on the caller. If you trained a LoRA, dialed in a house style, or stood up a diffusion pipeline worth paying for, Loomal lets you charge for each generation in USDC with one wrapper around your handler. ### Price by what the render actually costs A 512px draft and a 4K upscaled batch don't cost the same to produce, so they shouldn't cost the same to buy. Quote the price after you read the request body: resolution, step count, batch size, whether the agent asked for your premium checkpoint. Agents that just want a quick thumbnail pay cents. Agents pulling a full campaign of variations pay for the compute they consume, and your margin holds at any volume. ### Wrap the render handler Drop requirePayment on the route that calls your model. The agent settles the quoted USDC amount, then the GPU runs and the image comes back with a signed receipt attached. No key to issue, no quota table to maintain. ### Your style, found by the agents who want it List the endpoint and it shows up in the Loomal marketplace and the discovery feed. An agent building a brand mood board or a game asset pipeline can find your signature look and start paying for renders without anyone wiring up an integration. Every settled render lands USDC in your non-custodial wallet on Base, so a viral burst of demand is revenue, not a support ticket. ## Sell KYC & verification data to agents URL: https://loomal.ai/use-cases/sell-verification-data-to-agents Identity and business verification has always lived behind sales calls and signed contracts. That model breaks the moment the buyer is an agent that wants one check, right now, without onboarding. Loomal lets you sell verification per check in USDC. An agent submits an identity or a company, pays the quote, and gets your verified result back with a signed receipt. No procurement, no key provisioning, no minimum commit. ### Verification without the contract KYC and KYB checks cost you data access and processing on every call. Pricing per verification passes that cost through cleanly: the agent pays for the one check it needs, whether that's confirming a person's identity or validating a business registration. An agent onboarding a counterparty, screening a vendor, or qualifying an applicant can transact for a single check instead of negotiating a data agreement it will never read. ### Charge per check Wrap your verification endpoint with requirePayment. The agent settles the USDC amount, your provider logic runs the identity or business lookup, and the result returns with a signed receipt that proves the check was paid for. Different check types can carry different prices. A basic name-and-address match costs less than a full document and liveness verification; read the request and quote the right one. ### Auditable by design Every settled check produces an Ed25519 receipt and lands USDC in your non-custodial wallet on Base. For a compliance product, that signed, on-chain trail of who paid for which check is part of the value, not just billing. List the endpoint and it shows up in the Loomal marketplace and discovery feed, where agents that need verification can find and pay for it on their own. ## Sell lead enrichment to agents URL: https://loomal.ai/use-cases/sell-enrichment-data-to-agents Enrichment has always been priced in credits, and agents make the per-record nature of it obvious. A sales or research agent hands you an email or a domain and wants the attributes back — one record in, one record out. That is a unit you can bill directly. Loomal lets your enrichment service charge agents per record over x402. The agent reads the price, signs USDC, and gets the enriched profile in one round trip — settled on Base in seconds, with no API key to issue and no credit pack to pre-purchase. ### Per-record billing without credit packs The credit-pack model exists because there was no clean way to charge for a single enrichment. Agents and x402 remove that constraint. Each lookup settles on its own, so the agent pays for the exact records it enriches and nothing more — no expiring credits, no upfront commitment. An agent enriching a freshly scraped list might process a few hundred contacts in one run, then go quiet. Per-record pricing earns on every successful match in that run instead of forcing the buyer into a tier sized for traffic that comes in bursts. ### Charge per enriched profile A person enrichment and a full company enrichment can carry different prices. Wrap each route with requirePayment and set the rate per record. Loomal returns a 402, verifies the USDC authorization, and settles before your handler returns the enriched data. ### Found by prospecting agents List your person and company enrichment endpoints in the Loomal marketplace and they surface in the discovery feed agents scan when they need to fill in a contact or account. The agent finds your endpoint, reads the price, and pays per record — no key, no signup, no approval. Settlement is USDC on Base into a non-custodial wallet Loomal provisions for your project. Funds land in seconds, every settled record carries a verifiable receipt, and Loomal never takes custody of your money. ## Sell legal documents & templates to agents URL: https://loomal.ai/use-cases/sell-legal-documents-to-agents A well-drafted NDA, services agreement, or compliance policy is worth money, and agents drafting on behalf of their users will pay for a clean template rather than hallucinate one. The problem has always been charging for a single download without standing up a store. With Loomal-hosted endpoints you don't run anything. Upload the document, set a USDC price, and Loomal serves it behind an x402 paywall at a stable URL that any agent can pay per download. ### No store, no server The hard part of selling documents has always been the plumbing: a storefront, a checkout, a way to deliver the file only after payment. Loomal removes all of it. Your template is served from a hosted endpoint and we handle delivery, the paywall, and settlement. Update the document or re-price it anytime from the console. A new revision of your master services agreement is a single upload. ### Priced per download Each time an agent pays the challenge, it gets the document and you get the USDC. Price a simple one-page form low and a negotiated 30-page agreement higher, your call. Because it's standard x402, any agent can buy it without a custom integration. If you'd rather serve from your own backend, the same paywall wraps a route that returns the file. ### Found when an agent needs the document Hosted listings appear in the Loomal marketplace and the discovery feed, so an agent tasked with drafting an agreement can find your template and pay for it on its own, no human checkout required. Every download settles USDC to your non-custodial wallet on Base with a signed receipt. You keep all rights to your documents; Loomal only stores and serves them to paying agents. ## Sell market data to agents URL: https://loomal.ai/use-cases/sell-market-data-to-agents A quote is worth something for about as long as it takes the next print to land. Market data is the textbook case for per-fetch pricing: the agent wants this snapshot, now, and the value is gone before a monthly invoice would ever clear. Loomal lets a trading agent pay for a single quote or a fundamentals pull over x402. It reads the price, signs a USDC authorization, and gets the data in one round trip. You charge for exactly what was consumed, at the moment it had value. ### Perishable data wants per-call pricing Subscriptions price a year of access whether the buyer reads one row or a million. For market data that is backwards. An agent screening a watchlist might pull a fundamentals record once and never touch it again; another fires thousands of quote requests in a burst and then goes quiet. Per-fetch billing follows the actual demand curve. Price a delayed quote at a tenth of a cent, real-time at more, a full fundamentals bundle higher still. The agent pays the marginal cost of the marginal request, and you capture revenue on data the instant it is fresh. ### Price each endpoint to its freshness Wrap any handler with requirePayment and set a price per route. Real-time quotes, EOD bars, and reference data can each carry their own rate. On the first request Loomal returns a 402 with the price; the agent signs USDC and retries; the data goes back with a signed receipt. ### Get listed where trading agents look Publish your quote and fundamentals endpoints to the Loomal marketplace and they show up in the discovery feed agents crawl when they need a data source. An agent can find your feed, read the price, and start paying without anyone signing a contract. Settlement is USDC on Base, straight to a non-custodial wallet Loomal provisions for you. Funds land in seconds, every settled call carries a verifiable receipt, and Loomal never holds your money. ## Sell model inference to agents URL: https://loomal.ai/use-cases/sell-model-inference-to-agents You trained a model that does one thing better than the general-purpose APIs: a domain-tuned LLM, a specialized vision model, a custom diffusion checkpoint. Other agents would pay to call it, but standing up keys, quotas, and billing for them is a project of its own. Loomal lets you put your model behind a per-generation paywall. An agent calls your endpoint, pays in USDC over x402, and gets the output. Your GPU time is covered on every forward pass, and you never issue a credential. ### Charge for the compute you actually run Inference cost tracks output length and model size. Per-generation pricing lets a short completion cost a fraction of a cent and a long, high-resolution, or multi-step generation cost more, all on the same endpoint. You can quote from request parameters: token budget, image dimensions, sampling steps. The agent pays a price tied to the work it asked for, not a flat rate that loses money on the heavy calls. ### One forward pass, paid for up front Wrap your inference handler with requirePayment. The agent sends a prompt, Loomal quotes the price and runs the x402 handshake, settlement clears on Base, and your model produces the output only after it is paid. ### List your model where agents shop for capability Your model lists in the Loomal marketplace and the x402 discovery feed with its task, modality, and price. An agent looking for a model that does your specialty can find it and pay per generation without a contract or an integration call. Revenue settles in USDC on Base to a non-custodial wallet, with a signed receipt per generation so every paid call is provable. ## Sell news feeds to agents URL: https://loomal.ai/use-cases/sell-news-feeds-to-agents Agents reading the news want it the moment it breaks, and they want only the stories that match their query. A headline scan, a topic search, a full-article fetch — each is a separate ask with a separate value, which is why per-query pricing fits news better than a blanket subscription. Loomal lets your newsroom or aggregator charge agents per query over x402. The agent reads the price, signs USDC, and gets the headlines or article body in one round trip — settled on Base in seconds, with the payment itself acting as the access grant. ### Freshness and licensing in one transaction News has two things to sell: timeliness and the right to use the content. A per-query paywall handles both. The agent pays at the instant the story is fresh, and the settled payment is the license to read that response. No separate contract, no usage report to reconcile later. Because each call is metered and receipted, you have a precise record of what was accessed and paid for. That makes licensing to autonomous readers auditable in a way a flat feed subscription never is. ### Price headlines and full text differently A headline search is cheap; serving licensed full article text is worth more. Wrap each route with requirePayment and set the price accordingly. Loomal returns a 402, verifies the USDC authorization, and settles before your handler returns the results. ### Listed for agents that read Publish your headline and article endpoints to the Loomal marketplace and they show up in the discovery feed agents browse when they need a news source. The agent finds your feed, reads the price, and pays per query — no API key, no signup, no human approval. Settlement is USDC on Base into a non-custodial wallet Loomal provisions for your project. Funds arrive in seconds, every settled query produces a verifiable receipt, and Loomal never holds your revenue. ## Sell real estate data to agents URL: https://loomal.ai/use-cases/sell-real-estate-data-to-agents A property agent wants one thing at a time: this listing, that valuation, the comps for a single address. It is working a deal, not buying a database, and it needs the answer before the opportunity moves. Real estate data is a per-lookup business, and agents make that plain. Loomal lets your listings, valuation model, or comps dataset charge agents per lookup over x402. The agent reads the price, signs USDC, and gets the record in one round trip — settled on Base in seconds, with no API key to provision and no contract to negotiate. ### The address is the unit of value An investment agent evaluating a single property gets nothing from a bulk MLS license. It wants the listing detail, an automated valuation, and the recent comps for that one address. Per-lookup pricing charges for exactly those queries instead of an all-or-nothing data deal. It also reaches buyers a contract never would. An agent screening one neighborhood will pay a few cents per valuation, so you monetize one-off and long-tail lookups that traditional data licensing leaves untouched. ### Price listings, valuations, and comps apart A listing detail is cheap to serve; a modeled valuation and a comps set are worth more. Wrap each route with requirePayment and set its own price. Loomal returns a 402, verifies the USDC authorization, and settles before your handler returns the property data. ### Discoverable to property agents Publish your listings, valuation, and comps endpoints to the Loomal marketplace and they surface in the discovery feed agents browse when they need a property data source. The agent finds your endpoint, reads the price, and pays per lookup — no key, no signup, no approval step. Settlement is USDC on Base into a non-custodial wallet Loomal provisions for your project. Funds land in seconds, every settled lookup carries a verifiable receipt, and Loomal never takes custody of your money. ## Sell real-time data to agents URL: https://loomal.ai/use-cases/sell-real-time-data Real-time data is perfect for per-call monetization: its value decays in seconds, so agents fetch it exactly when they need it and would happily pay per read. Loomal lets you charge for each fetch in USDC without standing up billing or managing keys for thousands of agent callers. ### Per-fetch fits fresh data A monthly plan makes no sense for a price tick an agent needs once. Per-fetch pricing captures demand at the exact moment of value and scales with usage. Tiny amounts add up: at a tenth of a cent a call, a popular feed monetizes the long tail that subscriptions never reach. ### Drop-in paywall Wrap your feed endpoint with a price. The agent pays, gets the latest value, and you get USDC — settled on Base in seconds. No key provisioning means a new agent can start paying you the first time it calls, with zero onboarding. ### Found in the feed List your feed and it appears in the marketplace and the discovery feed, so data-hungry agents can locate and pay for it autonomously. Receipts and webhooks give you a clean, real-time record of every read you sold. ## Sell research papers to agents URL: https://loomal.ai/use-cases/sell-research-papers-to-agents Research agents read voraciously. They pull papers, reports, and analyses to ground their answers, and they'll pay for access to work that isn't free elsewhere. What's been missing is a way to charge for a single read without a journal subscription or a custom paywall. Loomal-hosted endpoints handle it. Upload the PDF, set a USDC price, and Loomal serves it behind an x402 paywall at a stable URL. Each access is a payment, no server or subscription system on your side. ### Per-access, not per-subscription Subscriptions assume a steady human reader. Agents aren't that. They want one paper now, relevant to one task, and a per-access price fits exactly. The agent pays for the read it needs and you earn on work that would otherwise sit behind a wall nobody reaches. Price a short report low and a flagship study higher. You set the number; the agent sees the quote before it pays. ### Upload and host, no backend Hosting is what usually kills the idea of selling a single paper. Loomal removes it: upload the PDF and we serve it from a hosted endpoint, handling delivery, the paywall, and settlement. If you already serve PDFs from your own backend, the same paywall wraps that route instead. ### Discoverable by research agents Hosted papers appear in the Loomal marketplace and the discovery feed, so an agent assembling a literature review or grounding a claim can find your paper and pay to read it on its own. Every access settles USDC to your non-custodial wallet on Base with a signed receipt. You keep all rights to your work; Loomal only serves it to agents that have paid. ## Sell sentiment data to agents URL: https://loomal.ai/use-cases/sell-sentiment-data-to-agents Sentiment is a derived signal that an agent wants for a specific ticker, brand, or topic, right now. A trading agent gauging the mood on an asset or a brand agent watching social chatter asks one question and acts on the score. That is a per-query product. Loomal lets your sentiment model charge agents per query over x402. The agent reads the price, signs USDC, and gets the score in one round trip — settled on Base in seconds, with no API key to provision and no plan to commit to. ### A score is worth paying for once Sentiment moves with the conversation, so a score is a snapshot of the mood at the moment it was computed. An agent acts on it and moves on. Pricing per query matches that: you charge when the signal is fresh and never have to justify a year of access to a number that changes by the minute. Querying patterns are spiky too. An agent might sweep sentiment across a basket of tickers ahead of a decision, then stay quiet. Per-query billing earns on each of those reads instead of forcing a flat tier that fits neither the sweep nor the quiet. ### Expose it as a paid MCP tool Sentiment is a natural MCP tool an agent can call mid-reasoning. Register the tool with a price and Loomal handles the 402, verifies the USDC authorization, and settles on Base before the tool returns its score — the agent pays inline as it thinks. ### Found by agents that read the mood Publish your sentiment tool to the Loomal marketplace and it appears in the discovery feed agents browse when they need a sentiment source. The agent finds your tool, reads the price, and pays per query — no API key, no signup, no human approval. Settlement is USDC on Base into a non-custodial wallet Loomal provisions for your project. Funds arrive in seconds, every settled query carries a verifiable receipt, and Loomal never holds your revenue. ## Sell sports data to agents URL: https://loomal.ai/use-cases/sell-sports-data-to-agents During a live game the score, the clock, and the odds all move constantly. A betting agent or a fantasy assistant needs that state right now, and a value that changes second to second belongs on a per-fetch meter, not a monthly bill. Loomal lets your scores, odds, and stats feed charge agents per request over x402. The agent reads the price, signs USDC, and gets the current state in one round trip — settled on Base in seconds, with no key to issue and no plan to negotiate. ### Live data is bursty by nature Demand for sports data is not steady. It spikes the moment a match kicks off and during every key play, then drops to nothing between fixtures. An odds agent might poll a single game hundreds of times in ninety minutes and ignore your feed the rest of the week. Per-fetch pricing captures exactly that pattern. You earn on every poll during the spike instead of guessing at a subscription tier that is either too small for game day or too big for the off-season. ### Meter scores, odds, and deep stats apart A live score check, an odds snapshot, and a full play-by-play stat line carry different value. Wrap each route with requirePayment and price it on its own. Loomal returns a 402, verifies the USDC authorization, and settles before your handler returns the live state. ### Found by betting and fantasy agents List your scores and odds endpoints in the Loomal marketplace and they surface in the discovery feed agents scan when they need a live sports source. The agent finds your feed, reads the price, and starts paying per fetch — no API key, no signup, no approval step. Settlement is USDC on Base into a non-custodial wallet Loomal provisions for your project. Funds land in seconds, every settled fetch carries a verifiable receipt, and Loomal never takes custody of your money. ## Sell video generation to agents URL: https://loomal.ai/use-cases/sell-video-generation-to-agents Video is the most expensive thing you can ask a GPU to do. A few seconds of generated footage can burn through compute that a free tier will never recover. The moment agents discover your endpoint, that cost compounds fast. Per-clip pricing fixes the economics. With Loomal you quote a USDC price for each render, take payment before the job queues, and let the agent pay for exactly the footage it asked for. ### Price the render, not a subscription Video cost scales with length, frame rate, and resolution. Read those off the request and set the price per job: a 4-second 720p preview costs a fraction of a 20-second 1080p final cut. Agents won't sign a contract for a single clip, but they'll happily pay a clear per-render price. That turns the long tail of one-off jobs into recoverable revenue instead of a compute drain. ### Charge before the job queues Wrap your render endpoint so payment settles before the work starts. The agent pays the quote, your pipeline accepts the job, and the finished clip (or a signed status URL for long jobs) returns once it's ready. Because the price covers your GPU minutes, a queue full of agent requests is a queue full of paid work. ### Found by the agents building video Your endpoint appears in the Loomal marketplace and the x402 discovery feed. An agent assembling an ad, a product demo, or a series of social cuts can find your model and start paying per clip on its own. Each settled render pays out USDC to your non-custodial wallet on Base with a signed receipt, so demand spikes show up as deposits instead of unpaid load. ## Sell weather data to agents URL: https://loomal.ai/use-cases/sell-weather-data-to-agents Weather is only useful while it is current. A forecast pulled an hour ago may already be wrong, which makes weather data a clean fit for paying per fetch rather than per month. The agent wants the conditions for one place at one time, and that is what it should pay for. Loomal lets a logistics agent, a travel planner, or a farming assistant pay for a single conditions read or forecast over x402. It reads the price, signs USDC, and gets the data in one round trip — settled on Base in seconds, with no key to provision. ### Freshness is the product When an agent asks for the weather, it is buying a guarantee that the answer reflects the world right now. That value evaporates fast, which is exactly why per-fetch pricing works: you charge at the moment the data is fresh and never have to defend an annual contract for something that changes every hour. An agent planning a delivery route might pull conditions for fifty cities in one pass, then nothing for the rest of the day. Per-call billing matches that bursty, location-by-location pattern far better than a flat plan ever could. ### Charge per location and per forecast horizon A current-conditions read and a fifteen-day hourly forecast are different products with different costs. Wrap each route with requirePayment and set its own price. Loomal returns a 402, verifies the USDC authorization, and settles before your handler sends the data back. ### Found by the agents that need conditions List your conditions and forecast endpoints in the Loomal marketplace and they appear in the discovery feed agents browse when they need a weather source. The agent finds your feed, reads the price, and starts paying — no signup, no API key, no human approval. Settlement is USDC on Base into a non-custodial wallet Loomal provisions for your project. Funds arrive in seconds, each settled fetch carries a verifiable receipt, and Loomal never holds your balance. # Comparisons ## Loomal Index vs Algorithmia what the legacy algorithm marketplaces got wrong. URL: https://loomal.ai/vs/algorithmia Comparing Loomal Index to Algorithmia is partly a history lesson: Algorithmia belongs to an earlier generation of algorithm marketplaces that let developers publish and monetize ML models and functions via API, and most of that generation has shut down or been acquired. That makes this comparison useful in a specific way. The legacy marketplaces validated the demand — developers will pay per call for capabilities they don't want to build. What they got wrong was the plumbing. This page looks at what changed. ### What Algorithmia got right The core insight behind Algorithmia and its peers was sound: package an algorithm behind an API, put a per-call price on it, and let other developers call it without licensing negotiations or self-hosting. Publish once, earn per invocation. That's the same economic shape Loomal Index is built around. The legacy marketplaces deserve credit for proving the model years before anyone was talking about AI agents as customers. ### Why the legacy model broke Legacy algorithm marketplaces required centralized accounts, API keys, and platform-specific billing. Every buyer had to sign up with the platform, get provisioned a key, and run their spend through the marketplace's own billing system. Every seller was locked to that platform's payment rails and its audience. That friction was tolerable when buyers were humans with credit cards and patience. It also made each marketplace a walled garden: when the platform faded, the listings, the billing relationships, and the revenue went with it. Most of that generation is gone — shut down or absorbed in acquisitions. ### What x402 removes Loomal Index replaces the account-and-API-key layer with the x402 protocol. A caller hits a priced endpoint, gets an HTTP 402 Payment Required response with the price, pays in USDC, and retries. Payment settles on Base in roughly two seconds, the payment clears before your handler runs, and every call produces an Ed25519 signed receipt. No signup, no key provisioning, no platform billing account on the buyer's side. Because x402 is an open HTTP standard rather than one marketplace's billing system, your monetization isn't hostage to any single platform's survival — including Loomal's. The price travels with the endpoint. ### The buyer changed too Algorithmia's buyers were human developers. Loomal Index's primary buyers are AI agents, which can't fill out a signup form or paste an API key from an email. An agent queries the index, reads the per-call price (minimum $0.01), pays, and calls — autonomously, in one pass. That's the structural difference: a legacy marketplace assumed a human in the loop at purchase time. An x402 listing assumes there isn't one. ### If you sold on a legacy marketplace The skill set transfers directly: you already know how to package a capability behind an endpoint and price it per call. On Loomal you list (or claim) your MCP server or API, set a per-call price you can change in one field, and keep your revenue minus a 5% fee on settled transactions — currently waived. This time the payment rail is a protocol, not a platform. ## Loomal Index vs Apify open payment standard vs platform billing. URL: https://loomal.ai/vs/apify Apify and Loomal Index both let developers earn money when someone uses their tool, so they get compared. But they sit at different layers: Apify is a platform you build and run scrapers on, with a marketplace attached; Loomal is a protocol-based index where any MCP server or API — hosted anywhere — takes payment. If you build scraping tools, this comparison matters concretely: it determines who can pay you, and through what. ### What Apify does well Apify is a platform and marketplace — the Apify Store — for web scraping and automation tools it calls Actors. Developers publish Actors, users run them on usage-based pricing, and the platform handles execution. For scraping specifically, that's a complete, focused offering: you write the Actor, Apify runs it and bills for it. If your product is a scraper and your customers are people who want to run scrapers, the Apify Store puts you in front of exactly that audience. ### Where the platform boundary shows Apify's Store sells Actors with its own usage-based billing, inside the Apify platform. Monetization and the platform are a package: your buyers transact through Apify, and what you sell is an Actor in Apify's format. Loomal takes the opposite bet. Payment is an open HTTP standard — x402 — not a platform feature. Your server can run on your own infrastructure, in any language, scraping-related or not, and still charge per call. The buyer doesn't need a relationship with any particular platform to pay you; it needs a wallet with USDC. That distinction matters most when your callers aren't Apify users at all — an agent assembled on a completely different stack can still discover and pay your endpoint, because nothing about the transaction depends on where either party signed up. ### What Loomal adds for agent buyers Loomal Index is built for the case where the customer is an AI agent rather than a person with a dashboard. An agent queries the index, finds your MCP server, gets the per-call price (from $0.01), and pays via x402: an HTTP 402 response quotes the price, the agent pays in USDC, settlement lands on Base in about two seconds, and payment clears before your handler executes. Each call carries an Ed25519 signed receipt, and there are no chargebacks. You set and change the price in a single field, and Loomal's fee is 5% of settled transactions — currently waived. ### When to use which Use Apify when you want a managed place to build, run, and sell scraping and automation Actors to its user base — the platform does the heavy lifting on execution. Use Loomal Index when you've built an MCP server or API — scraping or otherwise — and want any agent, on any stack, to be able to discover it and pay per call without going through one platform's billing. Plenty of teams will do both: run scraping infrastructure where it's convenient, and expose a priced MCP endpoint so the agent economy can pay for it directly. ## Loomal Index vs AWS Marketplace protocol-native vs cloud-account-native. URL: https://loomal.ai/vs/aws-marketplace AWS Marketplace is Amazon's marketplace for third-party software, SaaS, APIs, and data products that deploy into AWS accounts and bill through AWS. Loomal Index is an index of MCP servers and APIs where every listing is payable per call over x402. These rarely compete head-to-head today — but if you sell an API or data product and you're deciding where AI agents will buy it from, the architectural difference between them is exactly the thing to understand. ### What AWS Marketplace does well For organizations already running on AWS, the Marketplace collapses procurement: a third-party product becomes a line item on the AWS bill, deployable into the AWS account the team already operates. Software, SaaS, API, and data listings all flow through one billing relationship a company has already negotiated. That's genuinely valuable for enterprise sales. If your buyer is a company with an AWS commit and a procurement process, meeting them inside that process is a real advantage. ### The AWS account is the gate Everything in AWS Marketplace presumes an AWS relationship: purchases tie to an AWS billing account and products deploy into AWS infrastructure. The buyer is an organization, the unit is a subscription or contract, and the human doing the buying works inside a cloud account. An autonomous agent has none of that. It doesn't hold an AWS billing account, can't sign a procurement agreement, and doesn't want a deployment — it wants one tool call, right now, priced in something it can pay. ### What Loomal Index adds Loomal listings are protocol-based — MCP for the interface, x402 for the payment — and cloud-agnostic. Your server can run on AWS, another cloud, or a box under your desk; an agent on any infrastructure can discover it through the index and pay it without any AWS relationship. The unit of commerce is a single call: the agent hits your endpoint, receives an HTTP 402 with the price (minimum $0.01), pays in USDC, and the payment settles on Base in roughly two seconds — before your handler runs. Every call yields an Ed25519 signed receipt, and there are no chargebacks. No contract, no provisioning, no account on either side of the transaction. ### Different units of commerce The comparison reduces to granularity. AWS Marketplace sells deployments and subscriptions to organizations through a cloud billing account. Loomal Index sells individual calls to whoever — or whatever — shows up with a wallet. One is procurement infrastructure for companies; the other is transaction infrastructure for agents. That's also why neither replaces the other. A subscription negotiated through cloud procurement and a $0.01 metered call answer different questions. ### When to use which Sell through AWS Marketplace when your buyers are AWS-based organizations and your product fits subscription or contract pricing inside their cloud bill. List on Loomal Index when you want per-call revenue from AI agents regardless of whose cloud anyone uses. If you sell an API or data product, doing both covers two distinct buyer populations: procurement teams on one side, autonomous agents on the other. Loomal's fee is 5% on settled transactions, currently waived. ## Loomal Index vs Coinbase AgentKit the wallet and the marketplace. URL: https://loomal.ai/vs/coinbase-agentkit People search 'Loomal vs Coinbase AgentKit' expecting a competitor comparison, so let's be precise upfront: they sit on opposite sides of the same payment. AgentKit equips the buyer; Loomal Index lists the sellers. Coinbase AgentKit is a developer SDK for giving AI agents their own onchain wallets — holding funds, signing transactions, making x402 payments. Loomal Index is the machine-queryable index of MCP servers and APIs those payments go to. Here's how the pieces fit. ### What Coinbase AgentKit is AgentKit solves the demand-side problem: an autonomous agent needs to hold money and spend it without a human clicking through a checkout. The SDK gives the agent its own onchain wallet, the ability to transact crypto, and support for x402 payments specifically. If you're building an agent that buys things — data, API calls, tool invocations — AgentKit is one of the established ways to give it spending power. ### What a wallet doesn't answer A funded wallet answers 'how do I pay' but not 'what's worth paying for, where is it, and what does it cost.' An agent holding USDC still needs a way to find a geocoding endpoint, a scraping tool, or a document parser — and to learn the price before committing. That's the supply-side problem, and it's the one Loomal Index exists for: a queryable catalog where every entry exposes what it does, what it costs per call, and how to pay it. ### What Loomal Index provides Every Loomal listing is x402-ready with a concrete per-call price, minimum $0.01. The agent queries the index, picks a tool, calls the endpoint, receives an HTTP 402 quoting the price, pays in USDC, and the call proceeds — payment settles on Base in roughly two seconds and clears before the handler runs. Each transaction produces an Ed25519 signed receipt, and there are no chargebacks to claw revenue back from the seller. For sellers, the console handles the listing, the claim flow, and pricing — changeable in one field — with a 5% fee on settled transactions that's currently waived. ### One transaction, both tools Trace a single purchase and the relationship is obvious. An AgentKit-equipped agent holds USDC in its wallet. It queries Loomal Index for a capability, gets back an endpoint and a price, and makes the call. The 402 challenge comes back; the agent's wallet — AgentKit's job — signs and pays; Loomal's listing — the seller's side — collects and serves the response. Wallet pays, marketplace gets paid. There is no configuration of this transaction where you'd choose between them. ### Who needs which Building an agent that spends? You need wallet infrastructure like AgentKit, and Loomal Index becomes one of the places it can spend. Running an MCP server or API you want agents to pay for? You need a Loomal listing, and AgentKit-style wallets are where your customers' money lives. Building both sides — an agent platform with paid tools — you'll touch both on day one. ## Loomal Index vs Composio monetization layer vs integration layer. URL: https://loomal.ai/vs/composio Composio and Loomal Index both live in the 'agents using tools' stack, which is why the comparison comes up. But they answer different questions. Composio answers: how does my agent reliably call Gmail, Slack, or GitHub with auth handled? Loomal answers: how does my tool get found by agents and paid per call? If you're deciding which one you need, start with which side of the tool call you're on. ### What Composio does well Composio is a tool integration platform: managed, authenticated connections to services like Gmail, Slack, and GitHub, exposed to AI agents through its own SDK and with MCP support. The hard part it absorbs is auth — OAuth flows, token storage, refresh — multiplied across many third-party services. For an agent builder, that's a real saving. Wiring up authenticated access to a dozen SaaS products yourself is exactly the kind of undifferentiated work a platform should eat. ### Integration infrastructure isn't a sales channel Composio's focus, per its own positioning, is managed auth and tool execution infrastructure for the people building agents. That's the consumption side of tools. It isn't aimed at the person who built a tool and wants to earn revenue every time an agent calls it. If you maintain an MCP server — say a document parser or a data API — the integration layer doesn't get you discovered by paying callers or put a price on your endpoint. That's a different layer of the stack. ### What Loomal Index adds Loomal is the marketplace and payment layer: discovery, listing, and per-call x402 monetization for any MCP server or API — including the long tail of independent servers that no integration catalog covers. You claim your listing, set a price per call from $0.01 (repriceable in one field), and agents pay it directly: HTTP 402 quotes the price, the agent pays in USDC, settlement hits Base in about two seconds, and payment clears before your handler runs. Every paid call comes with an Ed25519 signed receipt and no chargeback risk. Loomal's cut is 5% of settled transactions — currently waived. ### Different sides of the same call Picture one tool invocation. The agent builder may use Composio-style infrastructure so the agent can execute tools with auth handled. The tool owner uses Loomal so that invocation gets found, priced, and paid. The integration layer makes the call work; the marketplace layer makes the call worth serving. There's no fork in the road here — these concerns compose rather than compete. ### When to use which Building an agent that needs authenticated access to mainstream SaaS tools: an integration platform like Composio is the right shape, and you should check its docs for current coverage. Built a server or API you want the agent economy to pay for: list it on Loomal Index. Teams doing both — consuming tools and selling their own — will end up with both, because neither does the other's job. ## Loomal Index vs Crossmint where checkout meets catalog. URL: https://loomal.ai/vs/crossmint Crossmint and Loomal both show up in 'agentic commerce' conversations, but they aren't rivals — they're adjacent layers. Crossmint provides the wallets and checkout capabilities an agent uses to purchase things, including API access via x402. Loomal Index provides the things: a machine-queryable catalog of MCP servers and APIs, each with a per-call price attached. This page maps where each one starts and stops, and what the combined flow looks like. ### What Crossmint does Crossmint is agent wallet and checkout infrastructure: it equips AI agents with wallets and the ability to complete purchases of goods, services, and APIs, with x402 among its supported payment paths. An agent builder integrates Crossmint's SDKs directly so the agent can hold funds and check out on its own. That's the demand side of agentic commerce — the part that turns 'the agent decided to buy' into a completed payment. ### Checkout needs a shelf Wallet and checkout infrastructure presumes there's something to buy and the agent knows where it is. For physical goods, that's existing storefronts. For API access and agent tools, the inventory question is wide open: where does an agent look up 'PDF extraction, priced per call, payable right now'? Crossmint doesn't claim to be that lookup — its SDKs are something a builder integrates, not a public catalog of priced endpoints. The catalog is a separate piece of the puzzle. ### What Loomal Index is Loomal is that catalog for MCP servers and APIs. Each listing carries a description, an endpoint, and a per-call price starting at $0.01 — queryable by machines, not just browsable by humans. The payment mechanics are pure x402: the endpoint answers with HTTP 402 and a price, the agent pays in USDC, the transaction settles on Base in roughly two seconds, and the handler only runs once payment has cleared. Sellers get Ed25519 signed receipts on every call, no chargebacks, one-field repricing, and a 5% fee on settled transactions that's currently waived. ### The combined flow End to end: an agent equipped with Crossmint-style wallet and checkout capability needs a capability it doesn't have. It queries Loomal Index, finds a server, reads the price. It calls; the 402 comes back; the agent's checkout layer pays it; the server responds. The buyer's infrastructure and the seller's listing each did exactly one job. Because both sides speak x402, no bilateral integration was needed — the protocol is the handshake. ### Who reaches for which Building an agent that purchases things: wallet and checkout infrastructure like Crossmint's is your integration, and Crossmint's docs are the authority on its current capabilities. Selling calls to a server or API you run: Loomal Index is your listing venue. The honest answer to 'Loomal vs Crossmint' is that a healthy agent economy needs both layers populated — and if you're a seller, the buyers Crossmint equips are precisely who you want finding your listing. ## Loomal Index vs Cursor Directory one editor's community vs every agent's index. URL: https://loomal.ai/vs/cursor-directory Cursor Directory and Loomal Index both list MCP servers, so a builder deciding where to be visible reasonably asks which matters more. The answer depends on two axes: which audience you want, and whether visibility alone is the goal. Cursor Directory reaches one specific, engaged community — Cursor users — with curation built for that editor. Loomal Index reaches every MCP client and every agent, and makes each listing payable. Here's the breakdown. ### What Cursor Directory does well Cursor Directory is a community site listing MCP servers, rules files, and prompts curated specifically for the Cursor editor. That focus is its strength: a Cursor user browsing it sees material chosen for their exact workflow — not just servers, but the rules and prompts that make Cursor itself work better. If your MCP server is useful to developers who live in Cursor, being present in the community's own curated directory is straightforwardly good distribution. ### Curation for one client has a ceiling The directory's framing is its boundary: it's curated for use with the Cursor editor, and it's a site for humans to browse. An MCP server, though, isn't Cursor-specific — the protocol's whole point is that one server works across clients. Listing only in client-specific directories means re-doing distribution per community, and none of those listings answer what an autonomous agent needs to know: is this endpoint callable right now, and what does a call cost? ### What Loomal Index adds Loomal listings work across all MCP clients — Cursor, Claude, Windsurf, and the rest — because the index describes the server, not any one editor's integration. And the index is machine-queryable: agents, not just humans, can search it and act on the results. The second addition is the one no curation-focused directory offers: monetization. Every Loomal listing can take x402 payment — the caller gets an HTTP 402 with a per-call price (minimum $0.01), pays in USDC, settlement lands on Base in about two seconds, and payment clears before your handler runs, with an Ed25519 signed receipt per call. You reprice in one field; Loomal's fee is 5% of settled transactions, currently waived. ### Discovery vs distribution vs revenue Sort the jobs and the comparison resolves itself. Community awareness among Cursor users: Cursor Directory. Presence across every MCP client and discoverability by agents: Loomal Index. Per-call revenue from the calls that discovery produces: only Loomal, because only it carries a payment rail. A free, open-source server might be perfectly served by community directories alone. The moment you want calls to pay for the infrastructure serving them, you need the listing that can charge. ### Use both, for different reasons There's no exclusivity question here — appear in Cursor Directory for the community reach, and claim your Loomal listing for cross-client discovery and the option to charge per call. The Cursor users who find you in one place and the agents that find you in the other are different audiences, and you want both. ## Loomal Index vs Fewsats marketplace vs payment plumbing. URL: https://loomal.ai/vs/fewsats Fewsats and Loomal both touch agent payments, which invites the comparison — but they're different kinds of product. Fewsats is infrastructure: SDKs and payment machinery a developer integrates into their own service so agents can pay for digital goods and API access. Loomal Index is a marketplace: a catalog where buyers (agents) find sellers (MCP server and API listings) with prices already attached. Infrastructure and marketplace sit at different altitudes, and the choice between them is usually not a choice at all. ### What Fewsats does Fewsats provides agent payments infrastructure — the machinery for AI agents to pay for digital goods and API access, supporting both x402 and the Lightning Network. A developer takes that infrastructure and wires it into their own service or agent. Notably, the Lightning support gives builders a Bitcoin-rails option alongside x402 — a breadth point worth knowing if your payment requirements span ecosystems. For specifics on current capabilities, Fewsats's own documentation is the source of truth. ### Infrastructure alone doesn't create a market Integrating payment infrastructure makes your endpoint able to charge. It doesn't make anyone show up to pay. The seller still faces the marketplace problems: where do paying agents look for tools, how do they learn your price before calling, and how do you appear in that search at all? Those are venue problems, not plumbing problems — and they're the half of monetization that an SDK, by its nature, leaves to you. ### What Loomal Index provides Loomal is the venue. Sellers list or claim their MCP server or API, set a per-call price from $0.01 (changeable in one field), and become discoverable in a machine-queryable index. Buyers — agents — query that index, get an endpoint plus a price, and pay per call through x402: HTTP 402 challenge, USDC payment, settlement on Base in roughly two seconds, payment cleared before the handler runs, Ed25519 signed receipt on every call, no chargebacks. x402-compatible payment infrastructure is exactly the kind of machinery that can operate under the hood of flows like this — which is why the marketplace and infrastructure layers complement rather than collide. Loomal's fee: 5% of settled transactions, currently waived. ### Choosing your layer Ask what you're actually short of. If you're building a service and need raw payment machinery embedded in it — or you specifically want Lightning alongside x402 — that's infrastructure territory, where Fewsats plays. If you've built an MCP server or API and your missing piece is paying customers, that's the marketplace, and a Loomal listing is the move. Many sellers need no extra infrastructure at all: listing on Loomal gives the endpoint its x402 payment flow as part of the package. ### The same direction of travel Both products exist because the same thing is becoming true: agents are turning into paying customers, and HTTP-native payments like x402 are how they'll transact. Infrastructure providers make that possible at the protocol level; Loomal Index makes it practical at the market level — a price, a listing, and a buyer who can find both. ## Loomal Index vs Glama payment infrastructure vs index. URL: https://loomal.ai/vs/glama If you're choosing where to list an MCP server, the honest framing isn't 'which is better' — it's 'which job are you hiring it for.' Glama and Loomal Index are built for different consumers, and the right answer is usually both. Glama optimizes for human discovery at scale. Loomal Index optimizes for agents that need to find, evaluate, and pay for a tool without a person in the loop. This page lays out what each does well and exactly where they differ. ### What Glama does well Glama indexes 18,000+ MCP servers and presents them for people to browse, search, and evaluate. If your goal is maximum human reach and a presence in the largest catalog, that's real, concrete value. It's a directory, and a good one — the place a developer goes to discover what MCP servers exist. For top-of-funnel awareness among human builders, a Glama listing is worth having. ### What Loomal Index adds Loomal Index is machine-readable and payment-ready. Every server listed has the SDK integrated and is x402-ready, so an agent can query the index, get a price and a payment endpoint, and call the tool — paying per call in USDC on Base — in one transaction. Glama can't answer 'what does this cost and how do I pay for it,' because there's no price field and no payment layer in the listing. Loomal answers both, programmatically. The difference shows up the moment an autonomous agent (rather than a human) is doing the discovering. The agent can't transact against a Glama listing; it can transact against a Loomal listing immediately. ### Side by side Audience: Glama is built for humans browsing; Loomal Index is built for agents querying. Catalog: Glama is far larger (18,000+); Loomal is smaller but every entry is payment-ready. Payment: Glama has none; Loomal has x402 on every listing, priced per call from $0.01. Discovery mode: Glama is browse-and-click; Loomal is query-and-call. SDK: Glama requires nothing to list; Loomal requires the SDK, which is precisely what makes every listing payable. Path to revenue: a Glama listing earns you nothing directly; a Loomal listing earns per call. Read that table and the takeaway is clear — these aren't substitutes, they're different layers of the stack. ### The advantage is structural It's tempting to assume Glama could just add payments and close the gap. It can't easily: payment infrastructure on every listing requires mandating SDK integration for every server, which is a business-model change, not a feature toggle. A browse directory's whole value proposition is that listing is frictionless and requires nothing — adding a hard SDK requirement would break that. So the catalog gap (Loomal has fewer servers) closes over time as more builders list; the payment gap (Glama has none) doesn't close for a directory without becoming a different kind of product. ### Use both List on Glama for human discovery and awareness. List on Loomal Index when you want agents to find you and pay automatically — with per-call pricing you set and reprice in one field. They're complementary: reach on one, monetization on the other, and no reason to choose. ## Loomal Index vs Google AP2 a marketplace vs a payments protocol. URL: https://loomal.ai/vs/google-ap2 This comparison crosses categories, so it pays to be exact. Google AP2 — the Agent Payments Protocol — is an open protocol: a specification for secure agent-initiated payments using cryptographically signed mandates to authorize purchases. Loomal Index is a product: a marketplace of MCP servers and APIs where every listing takes payment. The real protocol-level comparison is AP2 versus x402, the standard Loomal is built on. That one is worth walking through, because the two specs are sized for different problems. ### What AP2 is designed for AP2 tackles authorization: when an agent buys something on a person's behalf, how does the merchant know the purchase was actually sanctioned? Its answer is cryptographically signed mandates — verifiable records of what the user authorized the agent to do — and it spans payment methods from cards to bank transfers to crypto. That breadth fits its problem. Agent purchases of real-world goods and services across traditional payment rails genuinely need an authorization trail, and an open protocol from Google carries weight in getting merchants and processors to adopt one. ### Where x402 is deliberately narrower x402 doesn't try to cover cards or bank transfers. It's an HTTP-native challenge/response for stablecoin micropayments: a server answers a request with HTTP 402 Payment Required and a price; the caller pays in USDC and retries; done. On Loomal, that settles on Base in roughly two seconds, the handler runs only after payment clears, every call produces an Ed25519 signed receipt, and there are no chargebacks. That narrowness is the feature. A $0.01 tool call can't carry the ceremony of mandate issuance and multi-rail authorization — at micropayment scale, the protocol overhead has to approach zero or the economics fail. ### Why Loomal builds on x402 Loomal's unit of commerce is the single API or MCP tool call, priced from $0.01 upward. For that unit, x402's simplicity is exactly right: the price quote, the payment, and the call all happen in one HTTP exchange that any agent on any stack can perform. Sellers list their server, set the per-call price, change it in one field, and collect — Loomal's fee is 5% of settled transactions, currently waived. Per-call pricing for machine callers is the well-matched case. A purchase that needs proof of human authorization across traditional rails is a different shape of transaction, and the shape AP2 was drawn for. ### Protocols compete; venues don't have to Even at the protocol layer, AP2 and x402 read more like adjacent tools than rivals — authorization mandates for agent purchases versus HTTP-native micropayment mechanics. And Loomal isn't a protocol at all; it's a venue where one of those protocols is put to work. If AP2 adoption grows the world of agent-initiated commerce, the agents doing that commerce still need a place to find priced, callable tools. For current AP2 specifics — supported methods, adoption, tooling — Google's own documentation is the source to check, as protocol details evolve quickly. ### What to take away Researching agent payment standards: study both AP2 and x402 — they answer different questions and may both end up in your stack. Trying to monetize an MCP server or API today: that's not a protocol-selection exercise. List it on Loomal Index, where the x402 flow is already wired to every listing and any agent with USDC is a potential customer. ## Loomal Index vs Gumroad selling to agents vs selling to people. URL: https://loomal.ai/vs/gumroad Gumroad and Loomal both let you sell digital things, which is roughly where the overlap ends. Gumroad's buyer is a person with a credit card; Loomal's buyer is increasingly an AI agent with a wallet, paying per call without a human clicking checkout. If you sell courses or design assets to people, this comparison won't change your stack. If you sell files, data, or tool access that agents might consume programmatically, it matters. Here's the honest breakdown. ### What Gumroad does well Gumroad is a mature marketplace for creators selling digital products — files, courses, software licenses — directly to customers. The checkout, delivery, and storefront problems are solved; you upload a product, set a price, share a link, and a human buys it with a card. For creator commerce aimed at people, that's a proven model with years of refinement behind it. Its strength is exactly that human-facing simplicity: no integration work, no protocol knowledge, just a product page and a buy button. ### Where the human-checkout model stops A traditional checkout assumes a person on the other end — someone to fill a form, confirm a card, click a button. An autonomous agent can't do any of that against a standard storefront. If an agent's task requires a dataset, a document, or a tool you sell, a checkout page is a dead end: there's no machine-readable price, no programmatic payment flow, and no way for the agent to complete the purchase mid-task. That's not a criticism of Gumroad — it's a different transaction shape than the one it was built for. ### What Loomal adds Loomal's listings — MCP servers, API endpoints, and hosted files — are sellable to agents over x402. The flow is HTTP-native: the agent requests the resource, gets a 402 Payment Required response with the price, pays in USDC on Base (settlement in roughly two seconds), and gets the resource. The payment lands before your handler runs, there are no chargebacks, and every transaction produces an Ed25519-signed receipt. For hosted files specifically, this means the same kind of asset you'd put on Gumroad — a dataset, a report, a template — becomes purchasable by software, priced per download from $0.01. Humans can still buy it too; agents just stop being locked out. ### Side by side Buyer: Gumroad sells to humans at a checkout; Loomal sells to agents (and humans) over HTTP. Product types: Gumroad covers files, courses, licenses, memberships; Loomal covers MCP servers, API endpoints, and hosted files. Payment: card and PayPal versus per-call USDC on Base via x402. Pricing model: one-time or subscription versus per-call from $0.01. Disputes: card payments can be charged back; x402 settlements can't. Fees on Loomal: 5% on settled transactions, currently waived. The pattern is clear — these are parallel channels, not substitutes. ### When to use which Keep Gumroad for products humans browse, evaluate, and buy deliberately — courses, art packs, software people install. Use Loomal when the consumer of your product could plausibly be a program: data files an agent pulls into a pipeline, an API it queries mid-task, an MCP server it calls as a tool. Plenty of sellers will run both: the same expertise packaged for people on one channel and for agents on the other. ## Loomal Index vs Hugging Face MCP the whole ecosystem vs one platform's catalog. URL: https://loomal.ai/vs/hugging-face-mcp Hugging Face is a hub for ML models, datasets, and Spaces — hosted apps — and its MCP server makes those Spaces callable by agents as tools. That's a genuinely useful bridge: a huge catalog of ML capability becomes reachable from any MCP client. But it's a bridge into one platform. Loomal Index is scoped differently: it indexes MCP servers wherever they live — npm packages, remote endpoints, other people's infrastructure — and gives each listing a price and a payment rail. Here's how the two relate. ### What Hugging Face MCP does well Hugging Face's MCP server turns its hosted assets — Spaces and models — into tools an agent can call. If the capability you need already exists as a Space, this is the shortest path to using it from an agent: no deployment, no wrapper code, just the Hugging Face MCP connection. The depth of ML-specific capability behind that single connection is the platform's core strength. For agent builders whose workloads are model-shaped — inference, image generation, classification — that catalog is hard to match. ### Where the platform scope stops The Hugging Face MCP surface is, by design, scoped to Hugging Face. It exposes what's hosted there; it doesn't index the thousands of MCP servers running elsewhere — a Stripe server, a Postgres server, a web-scraping server published to npm. An agent that needs tools beyond ML inference needs a discovery layer that spans hosts. There's also no per-call payment primitive in the listing itself. A Space's author can't attach a machine-readable price that an arbitrary agent pays at call time without an account relationship — the question 'what does this call cost and how does my agent pay' isn't something the catalog answers. ### What Loomal adds Loomal Index is host-agnostic and payment-native. It indexes MCP servers across the broader ecosystem regardless of where they run, and every claimed listing can carry x402 pricing: the agent hits the endpoint, receives an HTTP 402 with the price, pays in USDC on Base — settlement in about two seconds — and the call proceeds. Payment clears before the handler runs, receipts are Ed25519-signed, and there are no chargebacks. For a builder, that means one listing makes your server both discoverable to agents everywhere and billable per call from $0.01 — without requiring your callers to hold an account on any particular platform. ### Different layers, not rivals The cleanest way to see it: Hugging Face is a host with an MCP doorway; Loomal is an index with a payment rail. A tool that runs as a Hugging Face Space and a tool that runs as a remote server on your own VPS look the same to Loomal — both are listings with metadata, a connection method, and optionally a price. The index doesn't compete with the host; it sits above hosts. That's also why the comparison is honest rather than adversarial — most agent stacks in 2026 will touch both: Hugging Face for ML capability, an ecosystem index for everything else and for payments. ### When to use which Use Hugging Face MCP when the tool you need is a model or Space already hosted there. Use Loomal Index when you need to discover tools across the whole MCP ecosystem, or when you're on the selling side and want your server — wherever it's hosted — to be findable by agents and paid per call. If you maintain a Space and a standalone MCP server, list the server on Loomal; the two channels don't conflict. ## Loomal Index vs Klavis AI open marketplace vs managed hosting. URL: https://loomal.ai/vs/klavis-ai Klavis AI and Loomal both make MCP servers easier to use, but they attack different parts of the problem. Klavis takes a set of popular SaaS integrations and runs them for you — hosting, uptime, OAuth flows all managed. Loomal indexes the ecosystem at large and gives every listing owner a way to charge per call. If you're an agent builder, the question is curation versus coverage. If you're a server maintainer, the question is who carries your listing and whether it can earn. Both questions get answered below. ### What Klavis AI does well Klavis provides hosted, managed MCP servers for popular SaaS tools with built-in authentication for agent builders. The pain it removes is real: running MCP servers yourself means dealing with deployment, credentials, and OAuth dances for every integration. With a managed provider, you point your agent at a hosted endpoint and the operational burden is theirs. For teams that need a known set of SaaS integrations working reliably without infrastructure work, that's a sensible trade. ### Where the managed model stops A managed catalog is necessarily a curated one — Klavis hosts a fixed set of integrations it has chosen to support. If the tool your agent needs isn't in that set, the managed layer can't help; you're back to finding the server in the wider ecosystem yourself. And the managed model is built for consumers of MCP servers, not producers. If you maintain an MCP server and want distribution and revenue from it, hosting-as-a-service isn't the channel — there's no open listing surface and no per-call payment primitive attached to your server's identity. ### What Loomal adds Loomal Index is open: it covers 1,000+ MCP servers across the ecosystem, whoever hosts them, and any maintainer can claim their listing. Claiming unlocks x402 monetization — agents calling your server get an HTTP 402 with your price, pay in USDC on Base with settlement in roughly two seconds, and the call runs only after payment clears. Receipts are Ed25519-signed; there are no chargebacks to dispute. Pricing is yours to set, from $0.01 per call, repriced in one field. The platform fee is 5% on settled transactions, currently waived. The point isn't to host your server — it's to make it discoverable and billable wherever it already runs. ### Two roles, two tools For agent builders: Klavis answers 'run these known integrations for me'; Loomal answers 'what exists, what does it cost, and how does my agent pay for it.' For maintainers: Klavis isn't your distribution channel unless you're in its supported set; Loomal is open to any server and is the only one of the two that routes revenue back to you per call. There's no contradiction in an agent stack using a managed provider for core SaaS integrations while querying Loomal for the long tail and for anything priced per call. ### When to use which Choose Klavis-style managed hosting when your integration list is short, popular, and operational simplicity is worth a subscription to you. Choose Loomal when you need breadth beyond a curated catalog, when your agent should pay per use instead of you pre-committing, or when you're the one with a server to list. Maintainers in Klavis's catalog lose nothing by also claiming their Loomal listing — that's where the per-call revenue lives. ## Loomal Index vs Lemon Squeezy micropayments for agents vs billing for humans. URL: https://loomal.ai/vs/lemon-squeezy Comparing Loomal to Lemon Squeezy is really comparing two transaction shapes. Lemon Squeezy is built for the classic one: a human subscribes to your software, you bill monthly, and someone has to handle tax jurisdictions, invoices, and compliance — that's the merchant-of-record job. Loomal is built for the new one: an AI agent needs one call to your MCP server or API right now, pays a cent or a few cents in USDC, and moves on. No subscription, no signup, no invoice. Most teams selling to both audiences will end up with both rails. ### What Lemon Squeezy does well Lemon Squeezy acts as merchant of record for software and digital products: it takes on payments, global sales tax, and subscription management so the seller doesn't carry the compliance burden. For a SaaS or digital product business billing human customers monthly or annually, that's a heavy, unglamorous problem handled end to end. If your revenue is recurring plans bought by people, a merchant-of-record platform earns its fee. ### Where subscription billing stops Subscription infrastructure assumes a durable relationship: an account, a stored payment method, a recurring charge. An autonomous agent making a one-off tool call has none of that — it won't create an account, can't complete a card checkout, and a monthly plan makes no sense for a task that needs exactly four calls. The economics break too. Card-based billing carries fixed per-transaction costs that make a $0.02 charge irrational, which is why human-facing platforms aggregate usage into monthly invoices. That aggregation requires the account relationship agents don't have. ### What Loomal adds Loomal's listings are priced per call and settled per call. The x402 flow runs over plain HTTP: the agent's request gets a 402 Payment Required with the price, the agent pays in USDC, settlement lands on Base in about two seconds, and your handler runs only after payment clears. Every settlement carries an Ed25519-signed receipt, and there's no chargeback mechanism to staff a dispute process for. Minimum price is $0.01 per call — small enough for tool-call economics, settled instantly rather than netted monthly. Loomal's fee is 5% on settled transactions, currently waived. ### Side by side Buyer: humans with accounts versus agents with wallets. Unit: monthly or annual plans versus single calls from $0.01. Settlement: card networks with multi-day clearing and chargeback exposure versus USDC on Base in seconds with none. Compliance: Lemon Squeezy carries tax and MoR obligations for you on human sales; x402 transactions are a different shape entirely. Relationship: Lemon Squeezy assumes a customer record; Loomal assumes none. Notice neither column covers the other's job. That's the tell that this is a both-and decision. ### Run both rails If you sell developer tooling, the realistic 2026 setup is: Lemon Squeezy (or a peer) bills your human customers on plans, and a Loomal listing lets agents pay per call for the same underlying capability without ever becoming 'customers.' The agent traffic is revenue you currently can't capture with checkout-based billing at all — adding the x402 rail doesn't cannibalize the subscription business, it extends it to a buyer type that couldn't pay you before. ## Loomal Index vs Make.com the marketplace vs the workflow canvas. URL: https://loomal.ai/vs/make-com Make.com (formerly Integromat) and Loomal aren't fighting over the same job, even though both live in the automation conversation. Make is where a person designs the logic — a node-based canvas connecting apps, APIs, and conditions into a scenario. Loomal is where the capabilities those scenarios depend on get listed, discovered, and priced. As workflows shift from human-designed scenarios toward agent-executed tasks, the question of how the executing agent finds and pays for a tool mid-run is exactly the gap Loomal fills. ### What Make.com does well Make.com gives non-developers and developers alike a visual way to build real automation: drag nodes onto a canvas, connect apps and APIs, add conditional logic, and run scenarios on schedules or triggers. Its strength is making integration work legible — you can see the data flow, debug a step visually, and ship automation without writing a service. For human-designed, human-maintained workflows across SaaS tools, that model is mature and proven. ### What a workflow platform doesn't solve A canvas assumes the builder already knows which services to wire in and has accounts or API keys for each. It's not a discovery surface for the broader MCP ecosystem, and it has no answer for usage-based payment between the workflow and a third-party tool — every connection rides on credentials and billing relationships the human set up beforehand. That assumption gets strained when the 'builder' is an AI agent. An agent composing its own task plan can't sign up for six SaaS accounts first; it needs tools it can find programmatically and pay for at call time. ### What Loomal adds Loomal Index is the supply side: a marketplace of MCP servers and API endpoints with machine-readable listings and, on claimed listings, x402 pricing. An agent — or an automation step — that calls a Loomal-listed endpoint gets an HTTP 402 with the price, pays in USDC on Base with roughly two-second settlement, and the call executes once payment clears. No account creation, no API key provisioning, no chargebacks; each payment carries an Ed25519-signed receipt. For tool builders, this is the channel Make doesn't offer: list once, set a per-call price from $0.01, and any agent or workflow runtime that speaks x402 becomes a paying caller. ### Where they meet The interesting overlap is a workflow that consumes paid tools. An automation needing, say, a specialized data lookup can call a Loomal-listed endpoint and settle the cost per execution rather than maintaining yet another subscription for a service used twelve times a month. Pay-per-use pricing matches the bursty, per-run shape of automation traffic better than seat-based plans do. So the relationship is supply and demand: Make-style platforms orchestrate; Loomal lists and prices what gets orchestrated. ### When to use which Use Make.com when a human is designing and maintaining the automation and the integrations are mainstream SaaS apps. Use Loomal when you need to discover MCP servers and APIs across the ecosystem, when your automation should pay per call instead of holding subscriptions, or when you've built a tool and want workflows and agents to pay you for using it. One is the canvas, the other is the catalog — there's nothing to choose between. ## Loomal Index vs mcp-get discovery and payments vs local install. URL: https://loomal.ai/vs/mcp-get mcp-get answers a narrow, useful question: 'how do I get this open-source MCP server installed on my machine?' It's a CLI plus a directory, in the spirit of a package manager — find a server, run a command, it's configured locally. Loomal Index answers a wider set of questions: what servers exist across the ecosystem (local and remote), what does calling one cost, and how does an agent pay for it. The comparison is short because the overlap is thin — but if you're deciding where your server should be findable, it's worth seeing clearly. ### What mcp-get does well mcp-get reduces installing an open-source MCP server to a single CLI command — discovery and setup in one tool. For a developer wiring local stdio servers into a client, that's a real friction cut compared with hand-editing config files and hunting package names across READMEs. Its directory is also a legitimate browsing surface for the open-source corner of the ecosystem: free servers you run yourself, on your own machine. ### Where the installer model stops An installer's worldview is local: packages you download and run. That leaves out the growing population of remote MCP servers — hosted endpoints reached over streamable HTTP that you don't install at all. It also has nothing to say about money. The servers mcp-get installs are free software, which is great, but the model has no slot for a server whose calls cost something: no price field, no payment flow, no way for a maintainer to earn from usage. None of that is a flaw in mcp-get — it's just a smaller job than the one a marketplace does. ### What Loomal adds Loomal Index spans both deployment shapes: locally-run packages and hosted remote servers appear as listings with metadata, connection details, and — when the owner claims the listing — x402 pricing. The payment layer is what changes the economics: an agent calling a priced endpoint gets an HTTP 402, pays in USDC on Base (settled in about two seconds, no chargebacks, Ed25519-signed receipts), and the handler runs after payment clears. For maintainers, that's the difference between a download count and a revenue line. A server that's free to install via mcp-get can still offer a paid hosted endpoint listed on Loomal, priced from $0.01 per call — open source and per-call revenue aren't mutually exclusive. ### Different consumers entirely mcp-get serves a developer at a terminal setting up their own environment. Loomal serves two parties that tool doesn't: autonomous agents querying for capabilities programmatically at run time, and maintainers who want usage to pay them. A human installing a free local server has no need for a payment rail; an agent selecting a tool mid-task has no use for a CLI installer. So 'versus' overstates it. The honest framing is that mcp-get covers install-time convenience for free local servers, and Loomal covers run-time discovery and monetization across the whole ecosystem. ### When to use which Reach for mcp-get when you're a developer setting up free, open-source servers on your own machine. Use Loomal when you need agents to discover your server, when you want to charge per call for a hosted endpoint, or when you're hunting for capabilities beyond the locally-installable open-source set. If you maintain a server distributed through mcp-get, claiming its Loomal listing costs nothing and adds the monetization path the installer can't provide. ## Loomal Index vs mcp.so payment infrastructure vs browse index. URL: https://loomal.ai/vs/mcp-so mcp.so and Loomal Index both list MCP servers, but they're built for different consumers. mcp.so is a place for people to browse a very large catalog. Loomal Index is a place for agents to query a payment-ready one. The choice is less 'which directory' and more 'do you need human reach or agent transactions' — and the answer can be both. This page lays out what each does well and exactly where they part ways. ### What mcp.so does well mcp.so indexes 21,000+ MCP servers and presents them for humans to browse and discover. For sheer catalog breadth and human-facing visibility, it's a strong directory — the kind of place a developer scans to see what's out there. If your goal is awareness among human builders, a presence in a catalog that large has value. ### What Loomal Index adds Loomal Index is machine-readable and payment-ready. Every listing has the SDK integrated and is x402-ready, so an agent can query the index, read a price and a payment endpoint, and call-and-pay in one transaction — in USDC on Base, with a signed receipt. mcp.so is browse-only: there's no price field and no payment layer, so an agent can read about a tool there but can't transact against it. The moment the consumer is an autonomous agent rather than a human, that gap is the whole story — discovery without payment doesn't let the agent actually use and pay for the tool. ### Side by side Audience: mcp.so is humans browsing; Loomal Index is agents querying. Catalog: mcp.so is far larger (21,000+); Loomal is smaller but every entry is payable. Payment: mcp.so has none; Loomal has x402 on every listing, from $0.01 a call. Discovery mode: mcp.so is browse-and-read; Loomal is query-and-call. Path to revenue: an mcp.so listing earns nothing directly; a Loomal listing earns per call. They're different layers — visibility versus transactability — not competing versions of the same thing. ### The advantage is structural Building payment into every listing would require mcp.so to mandate SDK integration for every server, which is a different business model — not something a browse directory bolts on. A browse directory's value is that listing is frictionless; a hard SDK requirement is the opposite of frictionless. So the catalog gap (Loomal has fewer servers) narrows as more builders list, while the payment gap (mcp.so has none) stays open for a browse directory that wants to remain one. ### Use both List on mcp.so for human-facing reach across the largest catalog. List on Loomal Index when you want agents to discover and pay you automatically, with per-call pricing you set and reprice in one field. There's no conflict in doing both — one builds awareness, the other builds revenue. ## Loomal Index vs n8n Workflow Marketplace selling the tools vs selling the templates. URL: https://loomal.ai/vs/n8n-marketplace The n8n Workflow Marketplace and Loomal both monetize the automation stack, but at different layers. n8n's marketplace trades in templates: pre-built workflow definitions — including ones that use MCP nodes — that you import into your n8n instance and run. Loomal trades in the layer below: the MCP servers and API endpoints those workflows actually call when they execute. A template is bought once; the tools inside it get called on every run. That difference in shape drives everything in this comparison. ### What the n8n marketplace does well n8n's marketplace gives builders a head start: instead of designing an automation from a blank canvas, you import a pre-built template — the node graph, the logic, the wiring — and adapt it. For common patterns, that compresses hours of workflow design into minutes, and it gives template authors a way to package and distribute their automation expertise. Templates that include MCP nodes also act as a soft on-ramp to the MCP ecosystem for n8n users who haven't touched the protocol directly. ### What a template can't carry A template is a static artifact. It encodes which services a workflow calls, but it can't supply the access: the buyer still needs credentials, accounts, or payment arrangements for every external tool the template references. And the template author monetizes the design once — they capture nothing from the thousands of executions that follow, and neither does the builder of the underlying tool the template depends on. There's also no usage-based payment primitive in the template model. If a workflow step needs a paid lookup, the marketplace that sold the template has no mechanism for settling that per-run cost. ### What Loomal adds Loomal monetizes execution, not design. An MCP server or API listed on Loomal carries a per-call price (from $0.01), and the x402 flow settles it inline: the calling agent or workflow gets an HTTP 402 with the price, pays in USDC, settlement lands on Base in about two seconds, and the handler runs after payment clears. Ed25519-signed receipts document every call; there are no chargebacks. That's the recurring-revenue shape the template model lacks — the tool builder earns on every run, not once at import time. Loomal's fee is 5% on settled transactions, currently waived. ### The layers compose These two markets feed each other. A workflow template that calls Loomal-listed endpoints is more useful, not less — the buyer imports the template and the per-call payments handle tool access without provisioning six API accounts first. And every popular template that references your MCP server is distribution for your Loomal listing: more runs, more paid calls. Template author, tool builder, and workflow runner are three roles, and only the middle one is Loomal's customer. There's no scenario where listing on Loomal and distributing templates on n8n conflict. ### When to use which Sell on the n8n marketplace when your product is automation design — a polished, reusable workflow. List on Loomal when your product is a capability — a server or endpoint that workflows and agents call repeatedly and should pay for per call. If you've built both a useful MCP server and workflows that showcase it, do both: the template drives adoption, the listing converts adoption into per-call revenue. ## Loomal Index vs OpenRouter paying for tools vs paying for tokens. URL: https://loomal.ai/vs/openrouter An agent's bill has two halves: the model that does the reasoning, and the tools it calls along the way. OpenRouter consolidated the first half — one API, dozens of LLMs from different providers, pay-as-you-go billing against a single account. Loomal Index addresses the second half: the MCP servers and API endpoints agents invoke as tools, each discoverable through one index and payable per call. The billing architectures differ in a way that matters, so this comparison covers both what each does and how their payment models diverge. ### What OpenRouter does well OpenRouter solved a genuinely annoying problem: every LLM provider has its own API, account, and billing. By putting dozens of models behind a unified endpoint with pay-as-you-go pricing, it lets developers switch models with a string change and consolidate inference spend in one place. For teams comparing or mixing models, that aggregation is the product. If your question is 'how do I access many LLMs without managing many provider accounts,' OpenRouter is a solid answer. ### What model routing doesn't cover OpenRouter's scope is model access. The tools an agent calls between inference steps — a search server, a database connector, a scraping endpoint, a niche data API — sit outside it. There's no MCP server index behind the unified endpoint, and no mechanism for a tool builder to list a capability and earn from agent calls. The billing model also reflects its scope: a centralized account with a balance, which works when you're buying from one aggregator, but doesn't extend to paying thousands of independent tool providers — each of those would need its own account relationship. ### What Loomal adds Loomal Index covers the tool layer with a decentralized payment model. Listings span the MCP ecosystem, and a claimed listing carries x402 pricing: the agent's call meets an HTTP 402 with the price, it pays the provider in USDC on Base — settled in roughly two seconds, before the handler runs — and gets the result. No prepaid balance with an intermediary, no per-provider accounts; payment flows per call, to each provider, with Ed25519-signed receipts and no chargebacks. For tool builders, this is the monetization channel model routers don't offer: set a per-call price from $0.01, change it in one field, keep 95% of settled revenue (the 5% fee is currently waived). ### Two different aggregation models It's worth being precise about the architectural difference. OpenRouter aggregates supply behind itself — it is the counterparty; you fund an account and it settles with providers. Loomal aggregates discovery but not payment custody — agents pay listing owners directly over x402, and the index is how they find what to pay for. Both are aggregation; they make different trade-offs about where money and trust sit. Centralized balances are convenient for one vendor relationship. Per-call settlement scales to a long tail of independent providers no aggregator could onboard one by one. ### When to use which Use OpenRouter for what it's built for: flexible, consolidated access to LLMs. Use Loomal for the tool half of your agent stack — discovering MCP servers and APIs, and paying for them per call without account sprawl. Most production agents in 2026 plausibly use both in the same loop: tokens through a model router, tool calls settled over x402. And if you've built a tool, OpenRouter was never your distribution channel — Loomal is. ## Loomal Index vs Paddle agent transactions vs SaaS billing. URL: https://loomal.ai/vs/paddle Paddle exists because selling software subscriptions globally is operationally brutal — tax registrations, currency handling, invoicing, renewals, dunning. As merchant of record, it absorbs that so SaaS companies can just ship. Loomal exists because a new buyer showed up that subscription machinery was never designed for: AI agents that need one API call or one tool invocation, will pay a few cents for it right now, and will never sign up, store a card, or renew anything. This page maps where each belongs. ### What Paddle does well Paddle acts as merchant of record for SaaS and software companies selling subscriptions worldwide. That's the maximal version of 'handling payments': Paddle is the legal seller, so global sales tax, compliance, invoicing, and recurring billing land on its books rather than yours. For a software business with human customers in many jurisdictions, that offload is the entire value proposition, and it's substantial. If your revenue is plans bought by people, Paddle-class infrastructure is the standard answer for a reason. ### Where recurring billing meets agents Now run an agent through that machinery. It has no legal identity to put on an invoice, no card to store, no inclination to subscribe — it has a task that needs your endpoint four times, today only. Checkout pages and recurring plans simply don't parse for that buyer. The unit economics fail independently: card-rail transactions carry fixed costs that make a $0.03 charge absurd, which is why human-facing billing aggregates usage into monthly invoices. Aggregation requires the standing account relationship that agents, by nature, don't form. Whole categories of agent demand are unbillable on this infrastructure — not poorly billed, unbillable. ### What Loomal adds Loomal settles the transaction shape Paddle doesn't: single calls, paid by machines, at cent scale. Over x402, the agent's request gets an HTTP 402 carrying your price; it pays in USDC, settlement finalizes on Base in about two seconds, and your handler executes only after the money clears. No invoices, no renewals, no dunning — and no chargebacks, since settlement is final and every payment carries an Ed25519-signed receipt. Prices start at $0.01 per call and reprice in one field. Loomal's fee is 5% on settled transactions, currently waived. The compliance surface is correspondingly different — these are per-call digital settlements, not card-network subscription commerce. ### Side by side Buyer: human account holders versus autonomous agents. Revenue shape: monthly and annual recurring versus per-call, settled instantly. Rails: card networks with merchant-of-record structure versus USDC on Base over x402. Failure modes: involuntary churn and chargebacks versus a payment that either clears in seconds or the call doesn't run. Minimum viable transaction: practically dollars on card rails; $0.01 on Loomal. Each column is a poor fit for the other's buyer — which is exactly why this isn't a migration decision. ### Both, in the same business The realistic architecture for a 2026 API or tool business: Paddle (or a peer) bills your human-facing plans, and a Loomal listing exposes the same capability to agents at a per-call price. The agent revenue is incremental — traffic that could never convert through a checkout — and it requires no change to your existing billing stack. List the endpoint, set the price, and the buyer type your MoR can't see starts paying you. ## Loomal Index vs Payman machine-to-machine vs agent-to-human. URL: https://loomal.ai/vs/payman Put 'Loomal vs Payman' side by side and the first thing you notice is that they don't compete on the transaction that matters to you. Payman is a payments platform that lets AI agents pay humans and businesses in fiat currency for tasks and services. Loomal is a marketplace where agents discover MCP servers and APIs and pay for individual calls in USDC. One moves money from an agent to a person. The other moves money from an agent to a piece of software, one request at a time. Which one you need depends entirely on who's on the receiving end. ### What Payman does well Payman's focus is fiat payouts: an agent completes against a task or service performed by a human or a business, and Payman handles getting real currency to that recipient. That's a genuinely hard problem — fiat rails come with compliance, identity, and banking plumbing that crypto-native systems skip — and it's a problem Loomal doesn't touch at all. If your agent workflow ends with 'and then a person gets paid in dollars,' Payman is solving your problem and Loomal isn't. ### Where the overlap ends The transaction Loomal handles looks nothing like a payout. An agent queries the index, finds a tool, hits its endpoint, receives an HTTP 402 Payment Required, pays the per-call price in USDC, and the handler runs. Settlement lands on Base in about two seconds, the seller gets an Ed25519-signed receipt, and there's no chargeback risk because payment clears before the work happens. That flow makes no sense for paying a freelancer, and a fiat payout makes no sense for a $0.02 API call — card and bank rails can't economically move two cents. The two products diverge because the transactions themselves are shaped differently: high-frequency machine-to-machine micropayments versus lower-frequency agent-to-human transfers. ### What Loomal Index adds for tool builders If you maintain an MCP server or an API, Payman doesn't give you a way to sell it — that's not its job. Loomal does: you claim your listing, set a per-call price starting at $0.01, and any x402-capable agent can find and pay for your tool with no account, no API key issuance, and no invoicing. Repricing is a single field on the console. Loomal charges a 5% fee on settled transactions, currently waived. There's no subscription to manage on either side — the agent pays exactly for what it calls. ### When to use which Use Payman when agents in your system need to compensate people — task marketplaces, bounty payouts, human-in-the-loop services settled in fiat. Use Loomal when agents need to consume software — search, scraping, data, inference — priced per call. A sufficiently autonomous agent might use both in one workflow: pay a Loomal-listed API for data with x402, then pay a human reviewer through Payman. These are adjacent layers of the agent economy, not substitutes, and there's no exclusivity question because they never handle the same payment. ## Loomal Index vs Postman API Network agents that pay vs developers who test. URL: https://loomal.ai/vs/postman-api-network The Postman API Network and Loomal Index both answer the question 'what APIs exist and how do I use them' — but they answer it for different audiences. Postman answers it for a developer sitting at a keyboard. Loomal answers it for an agent running unattended. That single difference cascades into everything: how listings are structured, what metadata matters, and whether a payment can happen without a human. This page walks through where each one earns its place. ### What the Postman API Network does well Postman's API Network is a directory of public API collections inside Postman, and for its intended job — a developer manually exploring and testing an API before writing integration code — it's excellent. You import a collection, fire requests from the GUI, inspect responses, and understand an API's shape in minutes instead of hours of doc-reading. If you publish an API, having a collection in the network is real distribution among the developers who already live in Postman daily. ### Where the workflow stops Everything in that workflow assumes a person. A collection tells a human what to click; it doesn't tell an agent what a call costs or how to pay for it. When an autonomous agent — not a developer — is the one discovering and consuming the API, a Postman collection has no machine-completable path from 'found it' to 'paid for it and got a response.' Whether Postman builds agent-payment features over time is something to watch in their own announcements; as of mid-2026, the API Network's described purpose is manual exploration and testing by developers. ### What Loomal Index adds Loomal frames the same kind of APIs for autonomous consumption. Each listing carries a per-call price (minimum $0.01) and an x402 payment endpoint. An agent calls the API, gets an HTTP 402 with the price, pays in USDC, and the request executes — settlement on Base in roughly two seconds, with an Ed25519-signed receipt. No signup form, no API-key provisioning step, no plan selection: every step a human would do in Postman is replaced by something a machine can complete alone. For the API publisher, that means revenue with no billing integration. You claim your listing, set the price, and reprice in one field. Loomal's fee is 5% on settled transactions, currently waived. ### Same API, two front doors These products don't compete for the same moment in an API's life. Postman serves the evaluation moment, when a human decides whether to integrate. Loomal serves the consumption moment, when an agent decides whether to pay for a call right now. The practical move for an API publisher is both: a Postman collection so developers can kick the tires, and a Loomal listing so agents can transact. Listing on Loomal requires no exclusivity, and the two audiences barely overlap — one is pre-integration humans, the other is in-production machines. ## Loomal Index vs PulseMCP a sellable listing vs an editorial entry. URL: https://loomal.ai/vs/pulsemcp PulseMCP and Loomal Index both maintain a catalog of MCP servers, so on the surface this looks like a directory-versus-directory comparison. It isn't. PulseMCP is editorial infrastructure for the MCP ecosystem — tracking, news, use cases. Loomal is commercial infrastructure: every listing can carry a price and accept payment. If you build MCP servers, the question isn't which catalog to appear in. You'll likely appear in both. The question is which one can put revenue against your name. ### What PulseMCP does well PulseMCP tracks roughly 18,000 MCP servers and wraps the catalog in editorial value: ecosystem news, use cases, and client coverage. For a developer trying to keep up with what's happening in MCP — new servers, new clients, what people are actually building — that's a genuinely useful vantage point that a bare index doesn't give you. Coverage there is worth having. A community-run directory with that reach is real top-of-funnel visibility for any server. ### What a directory entry can't do A PulseMCP entry describes your server; it doesn't transact for it. There's no price attached to the listing, no payment endpoint, and no way for the entry itself to produce revenue. That's not a flaw — it's not what an editorial directory is for — but it means the listing's value ends at awareness. It also means an autonomous agent reading the catalog can learn that your server exists, but can't go from discovery to a paid call. The commercial loop stays open. Whether PulseMCP adds anything payment-shaped later is for their own announcements; as of mid-2026 it's described as a directory with news and use cases. ### What Loomal Index adds On Loomal, a listing is a claimable product. You verify ownership of your server, claim the listing, and attach a per-call price — minimum $0.01, repriced in a single field. From that point, any x402-capable agent can hit your endpoint, receive the HTTP 402 challenge, pay in USDC, and run the tool. Settlement lands on Base in about two seconds, payment clears before your handler executes, and each transaction produces an Ed25519-signed receipt. No chargebacks, no invoicing, no key management. Loomal's cut is a 5% fee on settled transactions, currently waived. The unclaimed-to-claimed step is the whole difference: the same server that sits as a row in a directory becomes a storefront with a price, a payment rail, and an audit trail. ### How they fit together Treat PulseMCP as where the MCP community finds out about your server, and Loomal as where agents pay for it. Nothing about claiming a Loomal listing conflicts with directory coverage elsewhere — there's no exclusivity, and the audiences differ: humans reading ecosystem news versus agents executing paid calls. If you only have time for one action this week, claim your Loomal listing — it's the only one of the two that changes what your server can earn. ## Loomal Index vs RapidAPI x402 per-call vs keys and plans. URL: https://loomal.ai/vs/rapidapi RapidAPI is probably the most established name in API monetization, so 'Loomal vs RapidAPI' is a fair question — both let you charge for API access. The difference is the unit of commerce and who can complete it. On RapidAPI, the unit is a subscription: a developer signs up, picks a tier, gets a key, and integrates. On Loomal, the unit is a single call: an agent pays $0.01 or more in USDC via x402 and the request runs. Those two models suit different buyers, and increasingly the buyer is not a person. ### What RapidAPI does well RapidAPI aggregates thousands of traditional REST APIs behind one account, one billing relationship, and one key-management surface. For a human developer, that's real convenience: discover an API, subscribe to a plan, and start calling it without negotiating separate contracts with every provider. The tiered-plan model also fits steady, predictable workloads where a monthly quota maps cleanly to usage. If your customers are developers who integrate once and call you forever, a RapidAPI presence reaches them where they already shop. ### Where the model strains Every step of the RapidAPI flow — sign up, choose a tier, store a key — assumes a human making a one-time decision that amortizes over months of usage. An autonomous agent's usage doesn't look like that. It might need an API exactly once, mid-task, with no account and no ability to click through a subscription page. A tiered plan is the wrong shape for a buyer whose demand is a single call. Key-based access also concentrates risk: a leaked key spends someone's quota until it's rotated. Whether RapidAPI adds agent-native payment over time is a question for their docs; the model described as of mid-2026 is keys and tiered plans. ### What Loomal Index adds Loomal removes the account from the transaction. A listing exposes a price and an x402 endpoint; an agent that hits it gets an HTTP 402 Payment Required, pays the per-call price in USDC, and the handler runs — settlement on Base in roughly two seconds, with an Ed25519-signed receipt per call and no chargebacks, since payment clears before execution. There's nothing to sign up for and no key to leak. For the seller, pricing is one field: minimum $0.01 per call, repriced anytime from the console. Loomal takes a 5% fee on settled transactions, currently waived. No tier design, no quota enforcement, no billing-period edge cases. ### Which one, or both Match the model to the buyer. Human developers with sustained, predictable usage are well served by subscriptions, and RapidAPI is built for them. Agents with bursty, one-shot, or unpredictable usage need per-call payment they can complete autonomously, and that's Loomal's entire design. An API publisher doesn't have to pick: keep subscription plans for integrated human customers and list on Loomal so agents can pay per call. There's no exclusivity requirement, and the two channels monetize demand the other one structurally can't. ## Loomal Index vs Replicate selling calls vs selling compute. URL: https://loomal.ai/vs/replicate Replicate and Loomal both end with 'an API call that costs money,' which is why they get compared. But they sit on opposite sides of that call. Replicate is the supplier: it runs open-source ML models and charges you for the compute they consume. Loomal is the storefront: it lets you charge someone else — specifically, an AI agent — for calls to whatever you've built. For a lot of builders the realistic relationship is supply chain, not rivalry: Replicate is a cost line, Loomal is a revenue line. ### What Replicate does well Replicate took the painful part of ML inference — provisioning GPUs, packaging models, scaling them — and turned it into an API. You pick an open-source model, call it, and pay per second of compute. No CUDA wrangling, no idle GPU bills if you don't call anything. As a way to consume models without operating them, it's a strong product with a clear billing logic: you pay for exactly the compute your request used. If your product needs image generation, transcription, or any of the open models Replicate hosts, it's a sensible backend. ### What Replicate doesn't do for your product Replicate bills you through its own platform billing — it's how you pay for models, not how your customers pay you. If you wrap a Replicate model in something valuable — better prompting, domain-specific post-processing, an MCP interface — Replicate gives you no mechanism to charge agents for that wrapper. Its commercial relationship stops at your account. Per-second compute billing is also an awkward interface for an autonomous buyer: an agent shopping for a tool wants a known price per result, not a compute meter it can't predict before the call runs. ### What Loomal Index adds Loomal is protocol-based and model-agnostic: any MCP server or API can be listed, whatever runs behind it. You set a fixed per-call price — minimum $0.01, changed in one field — and agents pay it via x402: HTTP 402 challenge, USDC payment, then your handler executes. Settlement hits Base in about two seconds, every call yields an Ed25519-signed receipt, and because payment precedes execution there are no chargebacks. Loomal's fee is 5% on settled transactions, currently waived. The fixed price is what makes the economics composable. If a Replicate inference costs you a variable amount of compute, you price your Loomal listing above your expected cost and the spread is your margin — the agent sees one predictable number. ### The stack, not the choice Use Replicate when you need to run models without owning GPUs. Use Loomal when you need agents to pay for what you've built. A concrete pattern: an MCP server whose tool calls a Replicate-hosted model, listed on Loomal at a per-call price covering compute plus margin. The agent pays you in USDC per call; you pay Replicate for compute; the difference is revenue. Nothing about that requires choosing — they bill different parties at different layers. ## Loomal Index vs Skyfire open standard vs payment network. URL: https://loomal.ai/vs/skyfire Skyfire and Loomal are working on the same macro problem — AI agents that can pay for things — from different design positions. Skyfire builds a network: agents get identity credentials ("Know Your Agent") and payment tokens they can spend with sellers who join. Loomal builds on a standard: x402, the open HTTP 402 payment flow, with USDC on Base as the settlement rail, plus a marketplace where priced tools are discoverable. The comparison comes down to two choices: network versus open protocol, and payments-only versus payments-plus-discovery. ### What Skyfire does well Skyfire's distinctive bet is identity. Its KYA layer lets an agent prove who it is — or who it acts for — to a seller before money moves, and that matters for sellers who can't accept anonymous machine traffic for compliance or fraud reasons. Pairing verified identity with payment tokens gives the network a coherent answer to 'who is this agent and can it pay,' two questions most of the ecosystem still answers separately. For transactions where the seller needs to know the counterparty, that combination is a real differentiator. ### The network question A token-based network creates value inside its own boundary: the payment instrument and identity credentials work where the network is integrated. That's a deliberate trade — tighter guarantees within the network in exchange for adoption being the gating factor on reach. x402 makes the opposite trade. It's an open standard riding plain HTTP semantics: any server can return 402 with a price, any agent holding USDC can pay, and no party needs membership in anything. Settlement is on Base, a public chain, in roughly two seconds, with Ed25519-signed receipts. Loomal chose that side of the trade because tool calls are commodity transactions — high frequency, low value, between parties who may never interact again — where openness compounds faster than network guarantees. ### What Loomal adds beyond payment rails Payment infrastructure alone doesn't answer the question that precedes it: what is worth paying for? Loomal couples x402 with an index. Listings are machine-queryable with price and payment endpoint attached, so an agent goes from 'I need OCR' to a settled USDC call in one pass — discover, get the 402, pay, execute. Payment clears before the handler runs, so sellers carry no chargeback risk. For sellers, the console handles the commerce: claim your listing, set a per-call price from $0.01, reprice in one field. Loomal's fee is 5% on settled transactions, currently waived. ### When each fits If your transactions need verified agent identity before payment — regulated data, counterparty-sensitive services — Skyfire's KYA-plus-payment design speaks directly to that, and it's worth evaluating against your compliance needs. If your problem is selling tool calls to the broadest possible set of agents with no membership requirement on either side, the open x402 path is the shorter route, and Loomal adds the storefront on top. These can coexist: a seller might serve identity-verified traffic through one channel and open per-call traffic through a Loomal listing. Nothing in either model demands exclusivity. ## Loomal Index vs Smithery deployment vs monetization. URL: https://loomal.ai/vs/smithery Smithery and Loomal Index get mentioned in the same breath because both touch MCP servers, but they sit at different points in the lifecycle. One is about running your server; the other is about monetizing it. If you're trying to decide between them, you probably don't have to — they compose. This page makes the boundary explicit so you know which problem each one solves. ### What Smithery does Smithery focuses on deployment: getting your MCP server hosted, running, reachable, and kept alive. That's the infrastructure for operating a server — the equivalent of where and how your code runs. It's valuable and necessary, and it's entirely orthogonal to whether or how the server earns money. A deployed server that nobody can discover or pay is still just running. ### What Loomal Index does Loomal Index makes your server discoverable by agents and payable per call. Integrate @loomal/sdk and set a per-call price (from $0.01), and your tools are x402-ready — agents find them in the index and pay in USDC on Base, with a signed receipt on every call. Changing your price later is a one-field edit. Loomal doesn't host your server; it monetizes it. That's the half Smithery isn't trying to solve, and the half that turns a running server into a revenue stream. ### Side by side Job: Smithery runs your server; Loomal gets it discovered and paid. Layer: Smithery is hosting/infrastructure; Loomal is discovery + payment. Output: Smithery gives you a live endpoint; Loomal gives you agent traffic and per-call revenue. Payment: Smithery has none; Loomal settles USDC on Base per call. Audience: Smithery serves you, the operator; Loomal serves the agents calling your tools. Because they operate at different layers, there's no overlap to reconcile — you can use one, the other, or both without conflict. ### Use both Deploy with Smithery (or wherever you host — a VPS, a serverless function, your own cluster), then list on Loomal Index to get agent discovery and per-call payment on top. Hosting plus monetization, two layers, no conflict. Listing on Loomal doesn't move or change your deployment; you just point the listing at the endpoint Smithery (or your host) already gives you. ## Loomal Index vs Stripe ACP tool-level micropayments vs agentic checkout. URL: https://loomal.ai/vs/stripe-agentic-commerce-protocol Stripe's Agentic Commerce Protocol (ACP) is probably the most consequential signal yet that agent payments are real: Stripe and OpenAI building a protocol so agents can buy things from merchants. So how does it relate to Loomal, which also exists so agents can buy things? The split is granularity. ACP is built around checkout — an agent completing a purchase with saved payment methods through a merchant's existing Stripe integration. x402, which powers Loomal, is built for transactions too small and too frequent to justify a checkout at all: individual API and tool calls, paid in stablecoins on-chain rather than over card rails. ### What Stripe ACP does well ACP meets commerce where it already lives. Merchants have Stripe integrations, customers have saved payment methods, and ACP lets an agent drive that existing machinery to completion — developed with OpenAI, which means distribution into the agent surfaces consumers actually use. For buying products — physical goods, subscriptions, anything with a cart — extending proven card-rail checkout to agents is the pragmatic design. If you're a merchant selling things people would otherwise buy on your website, ACP is aimed squarely at you. ### Why checkout doesn't fit tool calls Now shrink the transaction to a $0.02 web-scrape or a $0.05 OCR call, repeated hundreds of times an hour by a machine. A checkout flow — even an agent-driven one — is the wrong shape: card rails carry per-transaction economics that make two-cent charges impractical, and 'saved payment method within a merchant relationship' assumes an ongoing buyer-seller relationship that one-shot tool calls don't have. This isn't a flaw in ACP; it's scope. ACP is described as agentic checkout on Stripe's network. Pricing individual API requests was never the problem it set out to solve. ### What x402 and Loomal do instead x402 removes checkout from the loop. The agent calls an endpoint, gets HTTP 402 Payment Required with a price, pays in USDC, and retries — the payment is a header, not a flow. Settlement lands on Base in about two seconds, the seller's handler only runs after payment clears, and every call produces an Ed25519-signed receipt. No chargebacks, no card network, no minimum-viable-transaction problem: Loomal listings price from $0.01 per call. Loomal adds the market layer: a machine-queryable index of MCP servers and APIs with prices attached, so the agent that needs a tool can discover it and pay it in the same pass. Sellers claim a listing, set the price in one field, and pay a 5% fee on settled transactions — currently waived. ### Two protocols, two transaction shapes The clean way to hold both in your head: ACP is for when an agent buys what a human would have bought — a product, at checkout, on card rails. x402 is for what only machines buy — metered access to software, per call, on-chain. A sophisticated agent will end up speaking both, the way today's web speaks both 'add to cart' and 'API request.' If what you sell is tool calls, the x402 side is your market, and Loomal is where agents go to find it priced and payable. ## Loomal Index vs Toolhouse open marketplace vs curated runtime. URL: https://loomal.ai/vs/toolhouse Toolhouse and Loomal both exist because agents need tools, but they take opposite positions on who decides what's available and how it's paid for. Toolhouse is a managed runtime: it hosts a curated set of tools and 'Toolhouse Actions' that agents reach through a simple API. Loomal is an open market: any developer can list any MCP server or API, attach a price, and sell calls to any agent. The right comparison frame is the one you'd use for an app store's editorial picks versus an open exchange — both useful, for different reasons, to different people. ### What Toolhouse does well Toolhouse compresses tool integration into one decision. Instead of evaluating, hosting, and wiring up a dozen separate tools, an agent developer points at the Toolhouse API and gets a working, curated set — execution managed in Toolhouse's cloud, quality filtered before anything reaches your agent. For teams that want tools to be someone else's operational problem, that's a clean value proposition. Curation is a feature when you're building fast: fewer choices, fewer integration surprises, one API to learn. ### What curation costs The same filter that guarantees quality bounds the catalog. If the tool your agent needs isn't in the curated set, the runtime can't help — and if you build tools rather than consume them, a curated platform isn't an open door you can walk through with your own server and your own price. The brief description of Toolhouse is a runtime for accessing its tools, not a venue where any developer sells theirs. There's also no price-per-call relationship between an outside agent and an individual tool author in that model — the platform mediates access. Whether Toolhouse expands toward open third-party monetization is a question for their docs; check there for the current state. ### What Loomal Index adds Loomal removes the gatekeeper from both sides. Tool builders list their own MCP server or API — claimed via ownership verification — and set their own per-call price, minimum $0.01, repriced in a single console field. Agents query the open index, find a tool with price and payment endpoint attached, and pay via x402: HTTP 402, USDC payment, handler runs. Settlement on Base in roughly two seconds, Ed25519-signed receipts, no chargebacks because payment clears before execution. The commercial relationship is direct: agent pays builder, per call. Loomal's fee is 5% on settled transactions, currently waived. No curation committee decides whether your tool gets to exist in the market. ### Consumer or producer — that's the fork If you consume tools and want a managed, pre-vetted set behind one API, a curated runtime like Toolhouse is a legitimate choice. If you produce tools and want to earn from them — or consume tools that no curator has picked yet — an open marketplace is the only structure that serves you, and that's Loomal. These can also stack: nothing stops a team from using a curated runtime for its core toolset while its agents pay for long-tail or specialized tools through Loomal listings. Listing on Loomal carries no exclusivity, so builders lose nothing by being discoverable everywhere. ## Loomal Index vs Zapier selling the tools vs wiring the apps. URL: https://loomal.ai/vs/zapier Zapier comes up in MCP conversations for a good reason: a platform connecting thousands of apps now exposes some of that connectivity through its own MCP server, putting an enormous integration surface within reach of AI tools. So where does Loomal fit next to that? One level up. Zapier is a participant in the MCP ecosystem — a (very large) supplier of connectivity. Loomal is a venue for that ecosystem: the index where MCP servers and APIs of every origin get listed, priced, and paid by agents. The comparison is supplier versus marketplace, not feature versus feature. ### What Zapier does well Zapier's core asset is breadth: thousands of app integrations reachable through no-code triggers and actions, built up over years. For a human automating a workflow — new CRM row triggers an email, form submission updates a sheet — it remains the default answer, precisely because someone already built and maintains the connector you need. Its MCP offering extends that asset to AI tools: rather than writing integrations app by app, an AI tool can reach Zapier-connected actions through MCP. Riding thousands of existing connectors into the agent era is a sensible play, and for agent builders who need broad SaaS reach quickly, it's a real shortcut. ### What Zapier isn't Zapier is one server with many connectors — it isn't a market where other people's MCP servers live. If you've built your own MCP server — a scraper, a data feed, a domain-specific tool — Zapier gives you no listing, no price field, and no way for an agent to pay you. Its automations are also human-configured: a person designs the workflow and the platform bills that person, which is a different commercial loop from an agent autonomously buying a tool call from a stranger. For Zapier's current MCP and pricing specifics, their own documentation is the source — the point here is structural, not a feature gap they forgot. ### What Loomal Index adds Loomal is the venue layer. Any MCP server or API — independent, open source, or backed by a company — gets a claimable listing with a per-call price from $0.01 and an x402 payment endpoint. An agent queries the index, gets a 402 challenge with the price, pays in USDC, and the tool executes: settlement on Base in about two seconds, an Ed25519-signed receipt per call, and no chargebacks because payment lands before the handler runs. For builders, the commerce is self-serve: claim the listing, set the price, reprice in one field, and pay a 5% fee on settled transactions — currently waived. Your tool doesn't need to be part of anyone's platform to earn. ### Where each belongs in your stack Reach for Zapier when the job is connecting established SaaS apps into workflows, especially with no code — that's the problem it has spent years solving. Reach for Loomal when the job is selling your own tool to agents, or when your agent needs a specialized capability that no app connector covers and is worth paying for per call. They coexist without friction. An agent might trigger Zapier-connected actions for SaaS plumbing while paying Loomal-listed servers for scraping, OCR, or data lookups. And a builder whose tool overlaps with an app connector can still list on Loomal — no exclusivity, and a direct per-call revenue line that an automation platform doesn't offer. # Glossary ## Agent Orchestration URL: https://loomal.ai/glossary/agent-orchestration Agent orchestration is the coordination of multiple AI agents or tool calls — sequencing, parallelizing, and managing dependencies between the steps of a multi-step task. ### What is agent orchestration? Agent orchestration is the layer that decides which agent or tool runs when, how results flow between steps, and what happens when a step fails. A single LLM call answers a question; an orchestrated workflow books the flight — it searches, compares, holds a seat, pays, and confirms, each step depending on the output of the last. The orchestrator can be a framework (LangChain, CrewAI, AutoGen, n8n), a purpose-built planner agent that delegates to specialist sub-agents, or simply application code that sequences tool calls. What makes it orchestration rather than plain scripting is that the control flow is at least partly decided by a model at runtime — which tools to call, in what order, and whether the result is good enough to proceed. ### The core problems orchestration solves Sequencing and dependencies: step three often needs the output of steps one and two. The orchestrator tracks intermediate state and feeds it forward, so a research agent's findings become the writing agent's source material. Parallelism: independent steps — querying four data sources, scraping ten pages — should run concurrently. Good orchestrators fan work out and join the results, cutting wall-clock time dramatically. Failure handling: tools time out, return garbage, or hit rate limits. Orchestration defines retries, fallbacks (try a different search server), and escalation to a human when the workflow genuinely cannot proceed. ### How agent orchestration relates to MCP Orchestration frameworks increasingly treat MCP servers as the standard tool abstraction. Instead of writing a bespoke integration for every API, the orchestrator connects to an MCP server, reads its tool list, and exposes those tools to whichever agent needs them. This is why the same Firecrawl or GitHub MCP server shows up in LangChain pipelines, n8n workflows, and Claude Desktop alike. MCP also makes orchestration composable: a workflow can mix a filesystem server, a search server, and a database server from different authors, because they all speak the same protocol over stdio or Streamable HTTP. ### Orchestration meets agentic commerce Once a workflow spans premium tools, the orchestrator needs a way to pay mid-flow without a human pausing to enter a card. This is where x402 fits: when a paid MCP server responds with HTTP 402, the agent's wallet signs a per-call USDC payment, the call retries, and the workflow continues — settlement lands on Base in about two seconds, before the tool handler runs. Practically, that means an orchestrated pipeline can budget per step: $0.01 for a search call here, $0.05 for an extraction there, all metered exactly to usage rather than to a stack of subscriptions the workflow may or may not exhaust. ### Where to see orchestration in practice The Loomal Index lists thousands of MCP servers across categories that orchestrated workflows typically chain together — search, web scraping, browser automation, databases, code execution. Browsing a category hub is a quick way to see what a multi-step agent pipeline can be assembled from, and which servers expose paid x402 endpoints an orchestrator can pay for autonomously. ## Agent Wallet URL: https://loomal.ai/glossary/agent-wallet An agent wallet is a blockchain wallet controlled by or on behalf of an AI agent, used to hold and spend funds — typically USDC on Base — for x402 payments. ### What is an agent wallet? An agent wallet is a crypto wallet whose signing key is available to an AI agent's runtime, so the agent can pay for things without a human approving each transaction. In the x402 ecosystem it typically holds USDC on Base, because that pairing makes payments as small as $0.01 economically viable — fees on Base are a fraction of a cent and settlement takes about two seconds. The wallet is identified by its address, which is what a paid API or MCP server sees as the payer. The agent itself has no bank account and no credit card; the wallet is its entire financial identity. ### Why agents need their own wallet Traditional payment methods assume a human in the loop: a checkout page, a card form, a 3-D Secure prompt. An autonomous agent calling fifty paid endpoints in a minute cannot stop for any of that. A wallet lets it respond to an HTTP 402 challenge by signing a payment authorization programmatically and retrying the request — the entire exchange happens between machines. Per-call payment also sidesteps the alternative: provisioning an API key and a subscription for every service the agent might conceivably touch. With a funded wallet, the agent discovers a tool, pays for exactly the calls it makes, and moves on. ### How an agent wallet is set up The typical flow has three steps. First, the operator provisions a wallet — either a raw keypair managed by the agent framework or a managed wallet service that keeps keys in custody. Second, they fund it with USDC on Base; a few dollars covers hundreds of calls at typical per-call prices. Third, they grant the agent's runtime access to sign x402 payment authorizations, usually behind spending controls. Spending limits are the critical safety layer: per-call caps, daily budgets, and allowlists of payee addresses keep a misbehaving or compromised agent from draining the balance. The wallet signs only what policy permits. ### Agent wallets in the x402 flow When an agent calls a paid MCP server or API listed on the Loomal Index, the server replies with a 402 response carrying the price and payment address. The agent's wallet signs that payment requirement, the request retries with the payment header attached, and USDC settles on Base before the handler runs. The agent receives the tool result plus an Ed25519 signed receipt and a transaction hash — a verifiable audit trail of what its wallet spent and why. Because settlement is final, there are no chargebacks; the wallet's on-chain history is the ledger of record for everything the agent bought. ### Wallet hygiene for agent operators Treat the agent wallet like a metered expense account, not a treasury: keep only working capital in it, top it up automatically, and rotate keys if the runtime environment may have been exposed. Reconcile spend against the signed receipts your agent collects — each one ties a payment to a specific call, which is what makes per-call budgeting auditable in a way subscription bills never were. ## Agentic Commerce URL: https://loomal.ai/glossary/agentic-commerce Agentic commerce is commerce conducted autonomously by AI agents — discovering, paying for, and using services without a human completing each transaction. ### What is agentic commerce? Agentic commerce is a model where AI agents independently discover services — MCP servers, APIs, data feeds — accept their pricing, and pay for usage as part of completing a task for their human or organizational principal. The human sets the goal and the budget; the agent handles the transactions. The defining feature is that no person is present at the moment of purchase. There is no checkout page, no card form, no subscription signup. The agent encounters a price mid-task, decides the call is worth it, pays, and continues. ### Why it could not happen on existing payment rails Card networks were built for humans: a roughly $0.30 minimum economical transaction, multi-day settlement, fraud checks tuned to human behavior, and a 120-day chargeback window. None of that survives contact with software that wants to spend two cents, four hundred times an hour, across forty different vendors. Agentic commerce needed a rail with machine-scale properties: prices down to $0.01, settlement in seconds, final transactions with no chargebacks, and a protocol an agent can negotiate without a browser. That is the gap stablecoin micropayments over x402 fill. ### The two protocols underneath: MCP and x402 Two standards make the model practical. The Model Context Protocol gives agents a uniform way to find and call tools — any MCP client can use any MCP server's capabilities without bespoke integration. x402 gives agents a uniform way to pay: a server answers an unpaid request with HTTP 402 and a price, the agent's wallet signs a USDC payment, the request retries, and settlement lands on Base in about two seconds — before the handler runs. MCP is the catalog and the calling convention; x402 is the cash register. An agent that speaks both can walk into an unfamiliar service and transact with it in a single round trip. ### What changes for sellers For anyone running an API or MCP server, agentic commerce inverts the usual go-to-market. Instead of marketing to developers who sign up, read docs, and provision keys, you publish a machine-readable listing with a per-call price and let agents find it. Revenue tracks usage exactly: a tool priced at $0.02 per call earns the same margin on its tenth call and its ten-millionth. Discovery becomes the bottleneck, which is why indexes matter. The Loomal Index is the discovery layer for this economy — thousands of MCP server and API listings that agents and their operators can browse, evaluate, and pay through x402. ### Where agentic commerce stands as of mid-2026 The pattern is early but no longer theoretical. Paid MCP servers settle real USDC per call, agent frameworks ship wallet integrations, and several payment players have announced agent-focused protocols. The open questions are mostly about scale and governance — spending controls, agent identity, and dispute handling when settlement is final. The mechanics of an agent paying a server for a single call, though, work today end to end. ## AI Agent URL: https://loomal.ai/glossary/ai-agent An AI agent is a system that uses a large language model to autonomously plan and execute multi-step tasks, usually by calling external tools and acting on the results. ### What is an AI agent? An AI agent combines a large language model with the ability to take actions: it calls tools, reads the results, and decides what to do next, repeating until the goal is met. The distinction from a chatbot is the loop — a chatbot produces text and stops; an agent treats its own output as a plan and executes it with minimal step-by-step human instruction. Concretely, an agent given "find the three cheapest flights to Lisbon next month and summarize the tradeoffs" will call a search tool, parse results, maybe call it again with refined parameters, and only then write the summary. The model supplies judgment; the tools supply reach. ### The anatomy of an agent Most agents share four parts. A model provides reasoning and language. A set of tools — search, code execution, file access, APIs — provides capabilities the model lacks. A context window holds the working state: the task, conversation history, and tool results. And a loop (the orchestration layer) feeds tool outputs back to the model until it decides the task is done. Tool quality usually matters more than model choice. An agent with a strong web-extraction tool will outperform a smarter model guessing from memory, which is why the tool ecosystem around agents has grown so quickly. ### How MCP changed agent tooling Before the Model Context Protocol, every agent framework defined tools its own way, and every API needed a custom adapter per framework. MCP standardized the interface: a server declares its tools once, and any MCP-compatible client — Claude Desktop, Cursor, LangChain pipelines, custom runtimes — can discover and call them. The result is a genuine ecosystem: thousands of interchangeable servers an agent can plug in without integration work. The Loomal Index catalogs that ecosystem, listing MCP servers and APIs by category so builders can find the tools their agents need. ### Agents that can pay: the x402 connection MCP solved discovery and calling; it did not solve payment, so the best data and compute tools were stuck behind signup forms agents cannot fill in. x402 closes that gap. When an agent calls a paid tool, the server responds with HTTP 402 and a price; the agent's wallet signs a per-call USDC payment, the call retries, and settlement completes on Base in about two seconds — before the handler runs. An agent with a funded wallet can therefore use tools its developer never signed up for, paying from $0.01 per call and collecting an Ed25519 signed receipt for every transaction. ### AI agent vs autonomous agent The terms overlap but are not identical. "AI agent" covers anything with the model-plus-tools loop, including assistants that check in with a human constantly. "Autonomous agent" implies long horizons and independent decision-making with little or no per-step review. The more autonomous the agent, the more it depends on machine-native infrastructure — standardized tools via MCP, programmatic payment via x402, and hard spending limits in place of human judgment. ## API Endpoint URL: https://loomal.ai/glossary/api-endpoint An API endpoint is a specific URL where an API can be accessed to perform one operation, such as fetching data or triggering an action. ### What is an API endpoint? An API endpoint is an addressable URL that accepts requests and returns responses for one particular operation — for example, GET /v1/search to run a query or POST /v1/invoices to create a record. The path identifies the resource, the HTTP method identifies the action, and together they define a contract: send a request shaped like this, get a response shaped like that. An API is the whole surface; an endpoint is one door into it. A weather API might expose /v1/current, /v1/forecast, and /v1/history — three endpoints, three distinct operations, often with three different costs to serve. ### Endpoints as the unit of value Because each endpoint does one job, it is the natural unit for both rate limiting and pricing. Providers commonly meter endpoints separately: a cheap lookup endpoint and an expensive bulk-export endpoint should not cost the same. Per-endpoint pricing also makes cost legible to callers — you can predict what a workflow costs by counting which endpoints it hits and how often. This granularity is exactly what pay-per-call models exploit. Under x402, an individual endpoint carries its own price (minimum $0.01 per call), and a caller pays for precisely the operations it invokes rather than buying access to the whole API. ### How MCP servers relate to endpoints An MCP server typically wraps one or more API endpoints behind a tool interface. The agent sees a tool called search_web with typed parameters; the server translates that tool call into the appropriate HTTP request to the underlying endpoint, handles authentication, and returns the response in a form the model can use. When the wrapped endpoint is monetized via x402, the MCP layer can handle the 402 payment challenge transparently: the server quotes the price, the agent's wallet signs a USDC payment, and the request retries — all before the endpoint's handler runs. To the agent, a paid endpoint and a free one look identical except for the receipt. ### Designing endpoints for agent callers Agents punish ambiguity more than humans do. Endpoints meant for machine callers benefit from strict, predictable schemas; explicit error codes rather than prose error pages; idempotency on anything that mutates state, since agents retry; and stable versioning, because no human is reading your changelog. Pagination matters too — an agent's context window is finite, so endpoints that return focused results beat ones that dump everything. Endpoints with these properties wrap cleanly into MCP tools, which is the most common path from "existing REST API" to "tool agents actually use." ### Endpoints on the Loomal Index Loomal lists both MCP servers and standalone API endpoints. A listed endpoint carries its description, schema, and — once the owner claims the listing — an x402 price per call, making it discoverable and payable by agents directly. Browsing the index shows the pattern in practice: thousands of individual operations, each addressable, each independently priced. ## API Key URL: https://loomal.ai/glossary/api-key An API key is a unique secret token used to authenticate requests to an API, traditionally issued to a developer after manual signup. ### What is an API key? An API key is a secret string a developer obtains — usually after creating an account — and attaches to each request, typically in a header like Authorization or X-API-Key. It proves the caller is authorized and lets the provider attribute usage to an account for billing, rate limiting, and abuse control. Keys are deliberately simple: no cryptographic handshake, no token refresh, just a shared secret. That simplicity made them the default authentication scheme for two decades of web APIs. ### What API keys actually do A key bundles three functions that are conceptually separate. Identity: which account is calling. Authorization: what that account is allowed to do, often by plan tier. Metering: how much it has used, feeding invoices and quota enforcement. The bundling is the source of most key pain. Rotating a leaked key breaks metering continuity; sharing a key across services blurs identity; and upgrading a plan means the same key suddenly means something different. Larger systems usually graduate to OAuth or signed requests precisely to unbundle these concerns. ### Where API keys break down for AI agents The key model assumes a human signs up before the first request: read the docs, create an account, verify an email, paste a secret into config. An autonomous agent that discovers a useful API mid-task cannot do any of that. Pre-provisioning is no better — an agent might plausibly touch hundreds of services, and nobody is going to maintain hundreds of accounts, keys, and subscriptions on the chance the agent needs one. Keys are also standing credentials: they leak in logs and repos, and a stolen key works until someone notices. For fleets of agents, the secret-distribution problem alone becomes a genuine operational burden. ### The x402 alternative: pay instead of authenticate x402 reframes the problem. Instead of proving who you are, the caller proves it has paid. A server answers an unkeyed request with HTTP 402 and a price; the agent's wallet signs a per-call USDC payment (from $0.01), the request retries with the payment attached, and settlement lands on Base in about two seconds — before the handler runs. No account, no signup, no secret to leak; the payment itself is the credential, and an Ed25519 signed receipt documents each call. This is why agentic commerce is often framed as an alternative to API keys: the agent pays as it goes rather than enrolling in advance. ### Keys and x402 are not mutually exclusive In practice many providers run both. Keys still make sense for high-volume contracted customers who want invoicing, custom terms, and support relationships. x402 covers the long tail: anonymous agents, one-off calls, and users who will never justify an enterprise agreement. A server listed on the Loomal Index can keep its existing key-based plans while exposing a per-call x402 price for callers who arrive with a wallet instead of an account. The likely steady state is segmentation by caller type: humans and contracted integrations on keys, autonomous agents on per-call payment — with the same endpoints serving both. ## API Marketplace URL: https://loomal.ai/glossary/api-marketplace An API marketplace is a platform where developers — and increasingly AI agents — discover, evaluate, and access third-party APIs and MCP servers, often with built-in billing. ### What is an API marketplace? An API marketplace aggregates many third-party APIs or MCP servers into a single point of discovery and access. Instead of finding each provider separately, reading separate docs, and opening separate billing relationships, a consumer browses one catalog, compares offerings side by side, and often pays through one account. The marketplace's job splits into three layers: discovery (search, categories, listings with structured metadata), evaluation (descriptions, tool lists, pricing, signals of maintenance and trust), and access (authentication and billing handled centrally so the consumer does not need a relationship with every provider). ### How traditional API marketplaces worked First-generation marketplaces — RapidAPI being the best-known example — were built for human developers. You signed up, picked a subscription tier per API, received a key, and got a monthly invoice. The marketplace took a cut and handled the billing plumbing. The model worked, but it inherited the assumptions of human commerce: monthly tiers, manual signup per API, and pricing units (requests per month) designed for an engineer estimating capacity, not for software deciding in real time whether one call is worth one cent. ### What changes when the buyer is an agent AI agents invert the marketplace's requirements. Discovery must be machine-readable — structured listings an agent can parse, not screenshots and marketing pages. Evaluation must be programmatic — published tool schemas and per-call prices an agent can compare. And access must be instant — no signup step, because the agent is mid-task when it finds the tool. Payment is the sharpest break. An agent cannot subscribe; it can pay per call. With x402, a listed server quotes its price in an HTTP 402 response, the agent's wallet pays in USDC, and settlement completes on Base in about two seconds — the marketplace's billing layer is replaced by a protocol. ### The Loomal Index as an agentic-era marketplace Loomal is an API and MCP marketplace built for this second model. The index catalogs thousands of MCP servers and API endpoints — seeded from the official MCP registry and public sources — with structured metadata and live-probed tool lists. Maintainers claim their listings by verifying ownership of the linked repository, then manage the listing and set an x402 per-call price (minimum $0.01). On the buy side, agents and their operators get one place to discover tools and one payment rail to use them. On the sell side, Loomal charges a 5% fee on settled transactions, currently waived. ### API marketplace vs registry vs directory The terms get blurred. A registry (like the official MCP registry) is a canonical namespace — it records that a server exists and where its package lives. A directory adds browsable presentation on top. A marketplace adds the commercial layer: pricing, payment, and a transaction between consumer and provider. Loomal spans all three — it indexes registry data, presents it for discovery, and adds x402 payments so a listing is not just findable but purchasable, one call at a time. ## Autonomous Agent URL: https://loomal.ai/glossary/autonomous-agent An autonomous agent is an AI agent that operates with minimal human oversight, making its own decisions about which tools to use, when to act, and how to spend its budget. ### What is an autonomous agent? An autonomous agent goes further than a tool-calling assistant: it operates over long horizons, makes independent decisions about strategy, and may run for hours or days without a human reviewing each step. Where an assistant proposes and waits, an autonomous agent commits — it picks the approach, executes it, evaluates its own results, and changes course when something fails. Autonomy is a spectrum, not a switch. A coding agent that opens a pull request for review sits in the middle; a monitoring agent that detects an incident, gathers diagnostics from five services, and files a remediation overnight sits near the far end. ### What separates autonomous from merely agentic Three capabilities mark the difference. Self-direction: the agent decomposes a goal into steps without a human supplying the plan. Self-correction: it detects bad tool output, retries, and switches tools rather than halting. And resource management: it operates within budgets — time, API calls, money — and makes tradeoffs between them. The third one is the least discussed and the most binding. An agent that cannot acquire resources on its own has a hard ceiling on its autonomy: it can only ever use what was provisioned in advance. ### Why autonomous agents force the payment question Autonomous agents are the primary beneficiaries of agentic commerce, for a blunt reason: no human is in the loop to click "subscribe." If an agent running overnight discovers that the best data source for its task is a paid MCP server, the traditional answer — stop, wake a human, create an account, enter a card — defeats the point of autonomy. x402 gives the agent a machine-native answer. The server responds with HTTP 402 and a price; the agent evaluates the cost against its budget, its wallet signs a USDC payment, and the call proceeds — settled on Base in about two seconds, with an Ed25519 signed receipt for the audit trail. Discovery, evaluation, and payment all happen programmatically. ### Guardrails: autonomy without blank checks Letting software spend money requires controls humans rarely need for themselves. Operators typically set per-call price ceilings, daily or per-task budgets, and allowlists of acceptable payees on the agent's wallet. Because every x402 payment is receipted and on-chain, spend is reviewable after the fact call by call — a sharper audit trail than a monthly card statement ever offered. The combination matters: hard limits constrain the worst case, receipts make the actual behavior inspectable, and final settlement means the accounting is never provisional. ### Autonomous agents and the tool ecosystem An autonomous agent is only as capable as the tools it can reach, which makes standardized discovery part of the autonomy stack. MCP gives agents a uniform way to connect to thousands of servers — search, scraping, databases, code execution — and indexes like the Loomal Index make that catalog browsable and, where servers are claimed and priced, payable. The further an agent runs from human supervision, the more it leans on this machine-readable infrastructure. ## Base (Ethereum L2) URL: https://loomal.ai/glossary/base-ethereum-l2 Base is a low-cost Ethereum Layer 2 network incubated by Coinbase, used as the settlement chain for x402 USDC payments on Loomal. ### What is Base? Base is an Ethereum Layer 2 (L2) network incubated by Coinbase and built on the OP Stack, the open-source rollup framework behind Optimism. As an L2, it processes transactions off Ethereum mainnet, batches them, and posts the results back to Ethereum — inheriting mainnet's security while charging a small fraction of its fees. For users the experience is ordinary Ethereum: the same addresses, the same tokens (including USDC), the same tooling. The differences are economic — fees of a fraction of a cent and confirmation in a few seconds. ### Why an L2 at all? Ethereum mainnet is secure but expensive for small transfers; at busy times a simple token transfer can cost more than the amount being sent. Layer 2 networks exist to fix exactly that: by executing transactions off-chain and settling compressed batches on-chain, they spread mainnet's security cost across thousands of transactions. The practical consequence is that payments too small to make sense on mainnet — a cent, two cents — become routine. That property, more than any other, is why Base matters to agent payments. ### Why x402 settles on Base x402 is a per-call payment protocol: an AI agent pays for a single API or MCP tool call, with a minimum price of $0.01. That model only works if the cost of moving the money is far below the payment itself and if settlement is fast enough to sit inside a request/response cycle. Base delivers both — sub-cent fees and settlement in roughly two seconds, fast enough that the payment clears before the tool handler runs. Deep native USDC liquidity helps too: Circle issues USDC natively on Base, so agents transact in a dollar-pegged unit without bridging or price risk in the middle of a workflow. ### What settlement on Base looks like in practice When an agent calls a paid listing on the Loomal Index, the server responds with HTTP 402 and a price. The agent's wallet signs the payment, the call retries, and USDC moves on Base before the handler executes. The response carries a Base transaction hash alongside an Ed25519 signed receipt — so every payment is independently verifiable on a public block explorer. Because on-chain settlement is final, there is no chargeback window. For sellers of machine-priced calls this is a feature: revenue recognized in two seconds stays recognized. ### Does using Base require crypto expertise? Less than the word "blockchain" suggests. An agent operator funds a wallet with USDC on Base and sets spending limits; the x402 client libraries handle signing and retries. A server owner pricing a listing on Loomal receives USDC to an address they control. Gas fees exist but are economically negligible at Base's price levels, and the unit of account throughout is the dollar-pegged USDC, not a volatile asset. The chain is, in effect, plumbing. Most people interacting with Base through x402 never look at a block explorer unless they want to verify a specific receipt — at which point the public ledger becomes a feature rather than a complication. ## Claimed vs Unclaimed Listing URL: https://loomal.ai/glossary/claimed-vs-unclaimed-listing On Loomal, an unclaimed listing is auto-indexed from public registry data; claiming it proves ownership and unlocks editing, richer metadata, and x402 monetization. ### What is an unclaimed listing? The Loomal Index is seeded automatically from the official MCP registry and public repositories, so it includes thousands of MCP servers whose maintainers have never visited Loomal. These start life as unclaimed listings: a page built from public metadata — name, description, package details, repository link, and where possible a live-probed tool list. An unclaimed listing is real and useful — agents and developers can discover the server and follow its install instructions — but nobody is at the wheel. The description is whatever the registry had, and the listing cannot carry a price. ### What claiming a listing means Claiming is the act of proving you are the server's maintainer and taking control of its page. Verification runs through the linked GitHub repository: if you can demonstrate ownership of the repo the listing points to, the listing is yours. This keeps the claim mechanism honest — control of the code is the credential, not a form submission. Once claimed, the listing flips from a public-data mirror to a maintained storefront, and the maintainer manages it from the Loomal console. ### What claiming unlocks A claimed listing can be edited: better descriptions, accurate categorization, documentation links, and a published tool list that maintainers can keep current by connecting their server. Claimed status itself is a trust signal — a buyer choosing between two similar servers reasonably prefers the one whose author demonstrably stands behind its page. The substantive unlock is monetization. A claimed listing can carry an x402 price per call — minimum $0.01 — so AI agents can pay for the server's tools directly: the agent hits the endpoint, receives an HTTP 402 quote, pays in USDC, and the call settles on Base in about two seconds. Loomal's fee is 5% on settled transactions, currently waived. ### Why the two-tier model exists A marketplace that listed only opted-in servers would start nearly empty and stay unrepresentative; one that auto-indexed everything with no claim path would be a directory nobody could act on. The claimed/unclaimed split resolves the tension: the index is comprehensive from day one because it mirrors the public registry, and any maintainer can upgrade their slice of it to a managed, monetizable listing the moment they care to. It also keeps incentives clean. Loomal does not put prices on unclaimed servers — pricing is a decision only the verified owner can make. ### How to tell them apart, and what to do about it On the marketplace, claimed listings are marked as such; unclaimed ones carry a prompt inviting the maintainer to claim. If you maintain an MCP server, searching the Loomal Index for it is worth thirty seconds: the listing likely already exists, and claiming it is a GitHub verification away from being a page you control — and, if you choose, a revenue stream metered per call. For buyers, the distinction is a quick filter: an unclaimed listing tells you a server exists; a claimed one tells you its author is paying attention. ## Context Window URL: https://loomal.ai/glossary/context-window The context window is the maximum amount of text, measured in tokens, that an LLM can process at once — including prompts, conversation history, and tool results. ### What is a context window? The context window is the LLM's working memory: everything the model can "see" when producing its next output. It includes the system prompt, the conversation so far, any documents pasted in, the schemas of available tools, and the results those tools have returned. It is measured in tokens — chunks of roughly three to four characters of English text. The window is a hard limit, not a soft preference. Once it is full, something must be dropped, summarized, or the request fails. Models as of mid-2026 commonly offer windows from around 128k to over a million tokens, but agents routinely fill even large windows on long tasks. ### Why agents fill context windows fast A chatbot's context grows at conversational speed; an agent's grows at tool speed. Every tool call adds the call, its arguments, and — the expensive part — its result to the window. A web scrape can return tens of thousands of tokens in one shot; a database query can return more. Twenty tool calls into a task, the window is mostly tool output, and the original instructions are competing for the model's attention with raw HTML. Context is also a cost: most LLM APIs price by input token, so every token a tool result occupies is paid for again on each subsequent model call in the loop. ### What this means for MCP server design Because tool results consume context, returning less, better-chosen data is a quality feature of an MCP server, not a limitation. Well-designed servers summarize rather than dump, paginate large result sets, let callers select fields, and return structured data instead of raw markup. A search server that returns ten tight snippets beats one that returns ten full pages, even though the second "gives more." Tool definitions themselves count too: a server exposing forty verbose tool schemas taxes the window before the agent makes a single call. Lean, well-described tools are cheaper to carry. ### Context window vs memory The context window is often confused with memory, but they are different layers. The window is what the model processes right now; memory is whatever the application persists outside the model — vector databases, files, conversation summaries — and selectively loads back in. An agent with a 200k-token window and good external memory will outlast one with a million-token window and none, because the window always runs out eventually and memory does not. MCP reflects this split: tools fetch fresh data into the window on demand, while resources and external stores hold what does not need to be resident on every turn. ### Managing context in practice Agent builders work around the limit with a familiar toolkit: summarizing or truncating old turns, storing long-term knowledge in external memory and retrieving it on demand (the RAG pattern), and compacting tool results before they re-enter the loop. Orchestration helps as well — splitting a task across sub-agents gives each its own fresh window instead of one overstuffed shared one. When evaluating MCP servers on the Loomal Index, response shape is worth weighing alongside capability: a server that respects your agent's context budget effectively lowers the per-call cost of every model invocation that follows it. ## Ed25519 Signed Receipts URL: https://loomal.ai/glossary/ed25519-signature Ed25519 signed receipts are tamper-proof proofs of payment or access, produced with the Ed25519 elliptic-curve signature algorithm and verifiable by anyone holding the signer's public key. ### What is Ed25519? Ed25519 is a widely used elliptic-curve digital signature algorithm, valued for being fast, compact, and hard to misuse. A signer holds a private key and publishes a public key; anything signed with the private key can be verified by anyone with the public one. Signatures are 64 bytes, keys are 32, and both signing and verification take microseconds — which is why Ed25519 underpins SSH keys, TLS, package signing, and much of modern infrastructure. Two properties matter for receipts: a signature proves the document came from the keyholder (authenticity), and any change to the document after signing invalidates it (integrity). ### What a signed receipt is A signed receipt is a small structured document — typically recording what was paid, to whom, for which call, and when — signed with the issuer's Ed25519 key. Unlike a row in someone's database, it is portable and self-verifying: the holder can present it to any third party, who can confirm with the public key that it is genuine and unaltered, without trusting the holder or contacting the issuer. That makes it the machine equivalent of a stamped invoice — except forging or editing it is computationally infeasible. ### Why x402 payments include signed receipts In the x402 flow, an agent pays per call in USDC: the server returns HTTP 402 with a price, the agent's wallet pays, settlement lands on Base in about two seconds, and the tool handler runs. The response then carries two proofs — the Base transaction hash, which shows money moved on-chain, and an Ed25519 signed receipt, which binds that payment to the specific call that was served. The pair answers different questions. The chain proves payment happened; the receipt proves what it was for. Together they give both sides a complete, non-repudiable record of a transaction that no human witnessed. ### Receipts as the audit trail for autonomous agents When an autonomous agent transacts on a principal's behalf, nobody reviews each step in real time — accountability has to be reconstructable afterwards. Signed receipts make that practical: an operator can reconcile every cent of wallet spend against receipts, each tied to a named tool call, and verify the lot cryptographically. Disputes shrink to checking a signature rather than comparing two parties' logs. Receipts also matter because x402 settlement is final — there are no chargebacks. The receipt is what replaces the card network's dispute paperwork: durable proof of exactly what was bought, held by the buyer from the moment of purchase. ### Verifying a receipt in practice Verification needs only the receipt, the issuer's public key, and any Ed25519 library — every mainstream language ships one. Check the signature over the receipt's canonical bytes, confirm the embedded transaction hash exists on Base, and the proof is complete. Servers monetized through the Loomal Index issue receipts in this flow automatically; neither buyers nor sellers implement the cryptography themselves. ## Embedding URL: https://loomal.ai/glossary/embedding An embedding is a numerical vector that represents text, images, or other data so that semantically similar items end up close together in vector space. ### What is an embedding? An embedding converts data — most commonly text — into a long list of numbers (a vector) positioned so that items with similar meaning sit near each other in vector space. "How do I reset my password?" and "I'm locked out of my account" share almost no words, but their embeddings land close together because they mean nearly the same thing. That property is what makes embeddings useful: instead of matching keywords, software can compare meanings by measuring the distance between vectors. ### How embeddings are produced Embeddings come from embedding models — neural networks trained specifically to map inputs to vectors. You send a string to the model and get back a fixed-length array, often somewhere between a few hundred and a few thousand dimensions depending on the model. Similarity between two embeddings is usually measured with cosine similarity or dot product. Two important caveats: vectors from different embedding models are not comparable with each other, and if you switch models you must re-embed your entire corpus. ### Embeddings in semantic search and RAG Embeddings are the engine behind retrieval-augmented generation (RAG). A document set is chunked, each chunk is embedded, and the vectors are stored in a vector database. At query time, the user's question is embedded too, and the database returns the chunks whose vectors are closest — those become the context the LLM answers from. The same mechanism powers semantic product search, deduplication, recommendation, and clustering. Anywhere the question is "what in this dataset is most like X?", embeddings are usually the answer. ### Embeddings and MCP servers Many MCP servers are embedding-powered under the hood. A documentation-search or knowledge-base server typically embeds the agent's query, runs a nearest-neighbor lookup against pre-computed vectors, and returns the top matches as tool output. The agent never sees the vectors — it just gets relevant text back. Embedding-backed tools also map cleanly onto per-call pricing. Each query has a real marginal cost (an embedding-model call plus a vector lookup), so charging per search via x402 — where the agent pays in USDC before the handler runs — keeps revenue aligned with the compute each call actually consumes. ### Embedding vs related terms An embedding is the vector itself; a vector database is where embeddings are stored and queried at scale; RAG is the end-to-end pattern that uses both to feed retrieved context into an LLM. People sometimes say "embeddings" loosely to mean the whole retrieval pipeline, but strictly it refers only to the numeric representation. ## Facilitator (x402) URL: https://loomal.ai/glossary/x402-facilitator An x402 facilitator is a service that verifies and settles x402 payments on behalf of a resource server, so the server needs no blockchain infrastructure of its own. ### What is a facilitator? A facilitator is the component in the x402 payment flow that verifies a submitted payment is valid and settles it on the blockchain, returning a confirmation to the resource server. It sits between the server selling access and the chain where payment lands, handling everything crypto-specific so the server does not have to. The design goal is separation of concerns: the resource server decides what costs what; the agent's wallet decides whether to pay; the facilitator answers exactly one question — "did this payment actually go through?" — and makes it go through. ### Where it sits in the x402 flow When an agent calls a paid endpoint without payment, the server responds with HTTP 402 and a payment requirement: amount, currency, and address. The agent's wallet signs a payment authorization and retries the request with it attached. The server forwards that payload to its facilitator. The facilitator checks the signature, amount, and recipient, submits the USDC transfer to Base, and waits for confirmation — roughly two seconds. It then tells the server the payment settled, the server runs the handler, and the response goes back with a signed receipt and the transaction hash. ### What the facilitator saves a server operator Without a facilitator, a server selling per-call access would need to run or rent a Base node, parse and validate signed payment payloads, submit transactions, monitor confirmations, and handle chain-specific failure modes like gas estimation and reorgs. That is a payments engineering team's worth of work to sell ten-cent tool calls. With one, the integration collapses to an API call: forward the payment payload, get back settled-or-not. The server's private keys stay out of the request path, since funds flow to the seller's receiving address on-chain rather than through the server process. ### Trust and verification The facilitator is trusted to report settlement honestly, but its claims are independently checkable: every settled payment is a public transaction on the Base settlement layer, so a seller can audit that reported revenue matches on-chain transfers. In x402, signed Ed25519 receipts give the paying agent the same auditability from the buyer's side. This is a meaningfully weaker trust requirement than card processing, where the processor controls funds, can reverse them for 120 days, and is the only record of what happened. A facilitator coordinates; the chain decides. ### Facilitators and Loomal When a seller claims an MCP server or API listing on the Loomal Index and attaches a per-call price (minimum $0.01), Loomal's payment infrastructure plays the facilitator role: verifying agent payments, settling USDC on Base, and issuing signed receipts — with a 5% fee on settled transactions, currently waived. The seller's only jobs are owning the listing and running the handler. Verification, settlement, and receipt generation happen in the payment path before the handler is ever invoked, so unpaid calls never consume the seller's compute. ## Gas Fees URL: https://loomal.ai/glossary/gas-fees Gas fees are the transaction fees a blockchain network charges to process and confirm a transaction, paid to the validators that execute it. ### What are gas fees? Gas fees are the price of getting a transaction executed on a blockchain. Every transaction consumes computational work from the network's validators, and gas is how that work is metered and paid for. The busier the network, the more you pay to get included in the next block. The term comes from Ethereum, where each operation a transaction performs has a fixed gas cost, and the total fee is gas used multiplied by the going gas price. ### Why gas fees vary so much Gas is an auction. When demand for block space spikes, fees spike with it — Ethereum mainnet fees have ranged from under a dollar to tens of dollars per transaction depending on congestion. Layer-2 networks (L2s) change the economics by batching many transactions together and posting them to Ethereum as one. Base, the L2 that x402 payments settle on, inherits Ethereum's security while keeping per-transaction fees at a small fraction of a cent in normal conditions. ### Gas fees are why micropayments failed on L1 A micropayment only makes sense if the fee to move the money is far smaller than the payment itself. Sending $0.01 on Ethereum mainnet could cost a hundred times the payment in gas — the fee swallows the value entirely. This is the core reason per-call API billing never worked on L1 blockchains, and why card networks (with their roughly $0.30 minimum economics) never worked for it either. On Base, the math inverts: when gas is a fraction of a cent, a $0.01 USDC transfer is overwhelmingly payment rather than overhead. That single change is what makes pay-per-call pricing for MCP servers and APIs economically real. ### Gas fees in the x402 payment flow In an x402 exchange, an agent receives an HTTP 402 response with payment details, its wallet signs the payment, and the transfer settles in USDC on Base in roughly two seconds. The on-chain settlement step is where gas applies — and because it happens on Base, the gas component is negligible relative to even the minimum $0.01 call price. For sellers on Loomal this means the listed price is effectively what moves: there is no fee structure that quietly makes sub-cent-scale calls unprofitable, and settlement is final with no chargeback window. ### Gas fees vs platform fees Gas fees go to the network for executing the transaction; platform fees go to a marketplace or processor for facilitating the sale. They are independent. A $0.05 tool call on Base incurs near-zero gas, while Loomal's platform fee is 5% on settled transactions — currently waived. ## HTTP 402 Payment Required URL: https://loomal.ai/glossary/http-402-payment-required HTTP 402 Payment Required is the long-reserved HTTP status code signaling that a resource requires payment before access — the foundation the x402 protocol is built on. ### What is HTTP 402 Payment Required? HTTP 402 is a client-error status code meaning the request cannot be fulfilled until the caller pays. It has been part of the HTTP specification since 1997, explicitly marked "reserved for future use" — the web's authors anticipated native payments but never standardized how they would work. For nearly three decades the code sat dormant, occasionally repurposed by individual APIs to mean "quota exceeded" or "upgrade your plan". The x402 protocol is the first widely adopted attempt to give 402 the meaning it was reserved for. ### A status code that waited 27 years Why did 402 go unused for so long? Because in 1997 there was no payment instrument a machine could use autonomously. Cards require a human, minimum fees made small payments absurd, and chargebacks made instant digital delivery risky for sellers. Stablecoins on low-fee networks removed each blocker: USDC gives a digital dollar, Base brings transaction costs down to a fraction of a cent, and on-chain settlement is final. Once a wallet could pay $0.01 programmatically in about two seconds, 402 finally had a payment rail worthy of it. ### How x402 uses the 402 status code In the x402 flow, a client requests a paid resource with no payment attached. The server responds 402, and the response body carries machine-readable payment requirements: the amount, the currency (USDC), and the address to pay. The client's wallet signs a payment authorization and retries the same request with a payment header. The server verifies the payment — typically via a facilitator — settles it on Base, runs the handler, and returns the result, often with an Ed25519-signed receipt. The whole round trip completes in seconds with no account, no API key, and no human involved. ### 402 vs 401 and 403 The three client-error codes are easy to conflate but mean different things. 401 Unauthorized says "I don't know who you are — authenticate." 403 Forbidden says "I know who you are, and the answer is no." 402 says "anyone can have this — pay first." That distinction matters for agents: 401 and 403 are dead ends without pre-provisioned credentials, while 402 is an invitation any funded wallet can act on immediately. ### Where you'll encounter 402 in practice Monetized MCP servers and pay-per-call APIs are the main places 402 shows up today. When an agent calls a paid tool listed on Loomal's index, the 402 exchange happens inside the tool call: payment is required and settled before the handler executes, so the seller never does work it hasn't been paid for. ## JSON-RPC URL: https://loomal.ai/glossary/json-rpc JSON-RPC is a lightweight remote procedure call protocol encoded in JSON, and the wire format underlying all Model Context Protocol communication. ### What is JSON-RPC? JSON-RPC is a minimal protocol for calling procedures on another process: you send a JSON object naming a method and its parameters, and you get a JSON object back with the result. The current version, JSON-RPC 2.0, was finalized in 2010 and has barely changed since — it is deliberately small. Unlike REST, JSON-RPC doesn't care about URLs, verbs, or resources. Unlike gRPC, it needs no schema compiler or binary encoding. It is just structured JSON over whatever channel you have. ### Anatomy of a JSON-RPC message A request has four fields: "jsonrpc" (always "2.0"), "method" (the procedure name, e.g. tools/call), "params" (the arguments), and "id" (so responses can be matched to requests when several are in flight). The response carries the same id plus either a "result" or an "error" object. A request sent without an id is a notification — fire-and-forget, no response expected. MCP uses notifications for things like progress updates and change events, where an acknowledgment would just be noise. ### Why MCP is built on JSON-RPC Every exchange in the Model Context Protocol — listing tools, calling a tool, reading a resource, fetching a prompt — is a JSON-RPC 2.0 message. The method namespaces them: tools/list, tools/call, resources/read, prompts/get. The choice was pragmatic. JSON-RPC is transport-agnostic, which lets the identical message format run over a local stdio pipe between a client and a subprocess, over Server-Sent Events, or over Streamable HTTP to a remote server. Server authors write one protocol implementation regardless of how clients connect. ### JSON-RPC and transports JSON-RPC defines what messages look like, not how they travel. In MCP, stdio transport frames messages as newline-delimited JSON on a subprocess's standard input and output; Streamable HTTP posts them to a single endpoint and streams responses back; the older SSE transport used a separate event stream for server-to-client traffic. This separation is why a server can migrate from local stdio distribution to remote hosting without touching its tool logic — only the transport layer changes. ### Reading JSON-RPC when debugging Because the format is plain JSON, MCP traffic is easy to inspect by eye. If a tool call fails, the error object's code and message usually point straight at the problem — a -32601 means the method doesn't exist, a -32602 means your params didn't match the tool's schema. Tools like MCP Inspector are essentially JSON-RPC viewers with an MCP-aware UI on top. ## LLM (Large Language Model) URL: https://loomal.ai/glossary/large-language-model A large language model (LLM) is a neural network trained on vast text data that can understand and generate human-like language — and, increasingly, decide which tools to call. ### What is a large language model? A large language model is a neural network trained on enormous text corpora to predict what comes next in a sequence. From that single objective, surprisingly general capabilities emerge: answering questions, writing code, summarizing documents, translating, and following multi-step instructions. Modern LLMs are further trained to follow instructions and to use tools — to recognize when a task needs external data or actions and to emit a structured request for them instead of guessing. ### From text prediction to tool calling On its own, an LLM can only produce text from what's in its context window; it cannot browse, query a database, or send an email. Tool calling closes that gap. The application presents the model with a list of available tools and their input schemas, and when the model decides a tool is needed it outputs the tool's name and arguments as structured data. The application executes the call, feeds the result back into the context, and the model continues reasoning with real data. The model decides; the surrounding software acts. ### The LLM's role inside an MCP client In the Model Context Protocol stack, the LLM is the brain inside the MCP client. The client (Claude Desktop, Cursor, an agent framework) connects to MCP servers, gathers their tool definitions, and exposes them to the model. The LLM then drives the session: it chooses which MCP tools to call, with what arguments, and how to weave the results into its answer. Quality matters at every layer. A capable model with poorly described tools will misuse them, and a well-built MCP server with vague descriptions will get called wrong — tool descriptions are effectively prompts written for the LLM. ### LLMs and agentic commerce Once an LLM can select and invoke tools autonomously, the natural next question is how those tool calls get paid for. An LLM-driven agent can hit thousands of endpoints in a session — far too many, and far too fast, for human-managed API keys and monthly invoices. This is where per-call payment rails come in: with x402, the agent's wallet settles a USDC payment on Base before a paid tool's handler runs, so the model's decision to call a tool and the payment for that call happen in one machine-speed exchange. The LLM doesn't manage money itself — the wallet layer does — but its tool choices are what drive the spending. ### LLM vs AI agent An LLM is a model; an AI agent is a system. The agent wraps the model with a loop, tools, memory, and goals, letting it take actions over multiple steps rather than produce a single response. Every modern agent contains an LLM, but an LLM alone — with no tools and no loop — is just a very good text generator. ## MCP Client URL: https://loomal.ai/glossary/mcp-client An MCP client is the AI application — Claude Desktop, Cursor, VS Code, and others — that connects to MCP servers and calls their tools on a user's behalf. ### What is an MCP client? An MCP client is the application a person actually uses — the chat interface, code editor, or agent runtime — that speaks the Model Context Protocol to one or more MCP servers. The servers provide capabilities; the client is where those capabilities get used. If the MCP server is a power outlet, the client is the appliance plugged into it. One client can connect to many servers simultaneously, pooling all of their tools into a single session. ### What an MCP client actually does The client's job has three parts. First, connection management: launching local servers as subprocesses over stdio, or opening Streamable HTTP connections to remote ones, and keeping those sessions alive. Second, capability discovery: asking each server what tools, resources, and prompts it offers, and presenting the tool list to the underlying LLM. Third, execution: when the model decides to call a tool, the client sends the JSON-RPC request to the right server, enforces any user-approval rules, and returns the result to the model. Most clients also handle the human-in-the-loop step — asking you before a tool with side effects runs. ### Popular MCP clients The ecosystem spans desktop assistants, code editors, and automation frameworks. Claude Desktop and Claude Code come from Anthropic, the protocol's originator. Cursor, Windsurf, Zed, Cline, Continue.dev, and VS Code with GitHub Copilot bring MCP into the editor. On the automation side, n8n and LangChain can act as MCP clients inside larger agent workflows. Configuration differs by client — each has its own config file location and format — but the protocol underneath is identical, which is why a single MCP server works across all of them without modification. ### Client, server, and host: untangling the terms The MCP specification technically distinguishes the host (the application, e.g. Claude Desktop) from the client (the protocol connection the host opens to one server — one client per server). In everyday usage, "MCP client" almost always means the host application, and that's how marketplaces, docs, and setup guides use the word. Either way, the boundary that matters in practice is: servers expose capabilities, clients consume them. ### MCP clients and paid tools When a client calls a tool on a monetized server, the x402 exchange is handled by a wallet layer rather than the client's UI: the server responds with payment requirements, the agent's wallet signs and pays in USDC, settlement lands on Base in about two seconds, and the call proceeds. From the client's perspective it is still just a tool call that returns a result — plus a signed receipt. Because the payment happens at the protocol level, the same monetized server works from any MCP client without client-specific billing integration. ## MCP Manifest URL: https://loomal.ai/glossary/mcp-manifest An MCP manifest is a metadata file — typically server.json — that describes an MCP server's name, version, packages, and capabilities so registries can index it. ### What is an MCP manifest? An MCP manifest is the machine-readable description of an MCP server that registries consume. By convention it's a server.json file, and it answers the questions a directory needs answered before it can list your server: what is it called, what does it do, where does the code live, what version is current, and how do users install or reach it. It plays the same role package.json plays for npm or pyproject.toml plays for PyPI — except it describes an MCP server rather than a library, and it's read by MCP registries rather than package managers. ### What goes in a manifest The core fields are a namespaced name (for example io.github.yourorg/your-server), a description, the repository URL, and a version. The most consequential section is packages: the list of ways the server can be obtained, each entry naming a registry type and identifier. Supported distribution types span npm, PyPI, OCI (Docker images), NuGet, and MCPB bundles, plus remote entries that point at a hosted Streamable HTTP endpoint instead of an installable package. One server can declare several — an npm package for local use and a remote URL for hosted use, for instance. ### How registries use the manifest When an author publishes to the official MCP registry, the manifest is the publication — the registry validates it, verifies namespace ownership, and serves the metadata through its API. Downstream indexes then pull from that API rather than scraping repos. Loomal's index works this way: listing pages for registry-published servers are populated from manifest data automatically, so the name, description, and install packages you see on a listing trace back to what the author declared in server.json. ### Why the manifest is worth getting right The manifest is most users' first contact with your server, rendered across every directory that indexes it. A vague description, a stale version, or a missing package entry propagates everywhere at once. It also anchors ownership. The official registry verifies that you control the namespace you publish under (a GitHub org, a domain), and claim flows on marketplaces build on the same chain of evidence — on Loomal, verifying ownership of the linked GitHub repository is how an author claims a listing and gains control over how it's presented and priced. ### MCP manifest vs MCPB manifest Two different files share the "manifest" name. The server.json manifest describes a server to registries. An MCPB bundle carries its own internal manifest.json describing how a desktop client should unpack and run the bundled server locally. A server distributed as an MCPB will have both: the bundle's internal manifest, and a registry manifest whose packages section points at the .mcpb file. ## MCP Monetization URL: https://loomal.ai/glossary/mcp-monetization MCP monetization is the practice of adding a per-call payment gate to Model Context Protocol tool registrations so that AI agents pay before the tool handler runs. ### What is MCP monetization? MCP monetization is the practice of adding a payment gate to Model Context Protocol (MCP) tool registrations so that AI agents pay per call before the tool handler runs. Instead of offering MCP tools for free or wrapping them in subscription tiers, developers set a per-call price and AI agents pay in USDC automatically — before the handler executes. The Model Context Protocol gave AI agents a standard way to call tools — search, extract, generate, look up. What MCP did not ship is a payment layer. MCP monetization fills that gap so tool authors can charge for the calls their server handles. ### How MCP monetization works When an AI agent calls a monetized MCP tool, the exchange completes in under two seconds. The agent sends a standard MCP tool call with no payment attached. The paywall middleware intercepts the call and returns a 402 response containing the price, currency, and payment address. The agent's wallet signs the payment requirement and retries the tool call with a payment header. The payment is verified on-chain, USDC is settled on Base mainnet, and the tool handler runs. The response includes a signed Ed25519 receipt and a Base transaction hash. The agent's business logic never changes. The tool author adds one function wrapper; everything else is handled by the payment middleware and the x402 protocol. ### Why MCP monetization matters The Model Context Protocol created a standard for AI agents to call tools. It did not create a standard for tool authors to get paid for those calls. MCP monetization fills that gap. Before MCP monetization, tool authors had three options: give their tools away for free, build a separate billing system (API keys, subscriptions, rate limits), or restrict access entirely. None of these work at machine scale — when the caller is software making thousands of requests per minute, subscriptions break and free tools become unsustainable. Per-call USDC payments via MCP monetization align revenue exactly with usage. A search tool that costs $0.01 per call generates consistent revenue whether it receives 10 calls or 10 million. ### MCP monetization vs traditional API monetization Traditional API monetization relies on subscriptions, rate limits, and human billing cycles. MCP monetization is synchronous, per-call, and requires no human in the payment flow. Where traditional billing charges on a monthly invoice after usage, MCP monetization charges per call before the handler runs. Where card networks impose a roughly $0.30 minimum, MCP monetization settles amounts as small as $0.01 in USDC. Settlement drops from two-to-seven business days to about two seconds on Base, and the 120-day chargeback window disappears — on-chain settlement is final. Implementation collapses from API keys, a billing system, and webhook handlers to a single function wrapper. ### How to implement MCP monetization The fastest way to implement MCP monetization is with Loomal's MCP monetization middleware. Install @loomal/sdk, wrap any MCP tool registration with requirePayment(), and deploy. The agent's wallet pays before your handler runs, and you keep full control of the tool implementation and runtime. For a step-by-step implementation guide, see Loomal's MCP server monetization page at loomal.ai/monetise/mcp. ## MCP Registry URL: https://loomal.ai/glossary/mcp-registry An MCP registry is a catalog of published MCP servers — including the official registry maintained by the MCP project and community indexes built on top of it. ### What is an MCP registry? An MCP registry is a directory of Model Context Protocol servers — the place you go to find out what servers exist, what they do, and how to install or connect to them. Without registries, MCP discovery is word of mouth and GitHub searches; with them, thousands of servers become browsable, searchable metadata. The term covers both the official registry run by the MCP project and the ecosystem of community indexes and marketplaces that consume its data. ### The official MCP Registry The official registry lives at registry.modelcontextprotocol.io. Server authors publish a server.json manifest — name, description, repository, version, and the packages through which the server ships — and the registry validates it, verifies namespace ownership, and serves the result through a public API. It is deliberately a metadata catalog, not an app store: it doesn't host code, rank servers, or process payments. Its job is to be the canonical, machine-readable source of truth that everything else can build on. ### What community indexes add on top Downstream registries take the official catalog and layer on what it deliberately leaves out: categorization, search, usage signals, and commerce. Loomal's index imports servers from the official registry and adds x402 payment support, live-probed tool lists, and a claim flow — maintainers verify ownership of their GitHub repository to take control of their listing. The monetization layer is the distinctive part: a claimed server can attach a per-call USDC price (minimum $0.01) so agents pay before each tool call runs, with settlement on Base. The official registry tells agents a server exists; an index like Loomal lets its author get paid for what it does. ### How to get your server into registries Publishing once to the official registry is the highest-leverage move, since community indexes sync from it. The flow: write a server.json manifest, authenticate with the registry's publisher CLI, prove you control your namespace (via GitHub for io.github.* names), and publish. Updates are new manifest versions. After that, check the downstream indexes that picked you up. On Loomal, claiming your imported listing lets you correct the description, surface the tool list, and set pricing if you choose to charge. ### Registry vs marketplace The words get used interchangeably, but there's a useful distinction: a registry catalogs servers; a marketplace adds a transaction layer — discovery plus the ability to buy and sell calls. Every marketplace contains a registry; not every registry is a marketplace. The official MCP Registry is firmly the former, by design. ## MCP Server URL: https://loomal.ai/glossary/mcp-server An MCP server is a program that exposes tools, resources, or prompts to AI applications using the Model Context Protocol. ### What is an MCP server? An MCP server is the piece of software that does the actual work in the Model Context Protocol. It wraps something useful — an API, a database, a browser, the local filesystem — and exposes a defined set of tools that an AI agent can discover and call. The agent doesn't need to know how the work happens. It sees a tool name, a description, and an input schema; the server handles authentication, API quirks, and data shaping behind that interface. One server, written once, works in every MCP client. ### What a server exposes Servers communicate over JSON-RPC and can offer three kinds of capability. Tools are the workhorses: functions with typed inputs the model invokes to act — search the web, run a query, create an issue. Resources expose readable data by URI for loading into context, and prompts are reusable templates that package recommended workflows. Most servers in the wild are tool-centric. A typical one registers between one and a couple dozen tools, each with a description that doubles as instructions to the calling model. ### How MCP servers are distributed Distribution falls into two camps. Local servers ship as installable packages — npm (run with npx), PyPI (run with uvx), Docker/OCI images, or one-click MCPB bundles — and run as subprocesses on the user's machine, talking to the client over stdio. Remote servers run as hosted endpoints reachable over Streamable HTTP, with nothing to install. The trade-off is control versus convenience: local servers can touch local files and keep credentials on-device, while remote servers centralize updates, scale independently, and are the natural shape for anything monetized. ### Finding and evaluating servers The official MCP registry catalogs published servers from their server.json manifests, and indexes like Loomal build discovery on top — categorized listings, live-probed tool lists, and claim verification so you can tell whether a listing is maintained by the actual author. When evaluating a server, the tool list tells you more than the description: it's the exact surface an agent will see. ### Monetizing an MCP server MCP standardized how agents call tools but shipped no payment layer, so most servers earn nothing regardless of usage. The x402 protocol fills the gap at the HTTP level: a priced tool call returns 402 with payment requirements, the agent's wallet pays in USDC, settlement lands on Base in about two seconds, and only then does the handler run — with an Ed25519-signed receipt in the response. On Loomal, a developer who has claimed their server can attach a per-call price starting at $0.01. The platform fee is 5% on settled transactions, currently waived, and there are no chargebacks because on-chain settlement is final. ## MCPB (MCP Bundle) URL: https://loomal.ai/glossary/mcpb-mcp-bundle MCPB (MCP Bundle) is a packaging format that distributes an MCP server as a single installable file, much like a browser extension package. ### What is an MCPB? MCPB — MCP Bundle — is a distribution format that packs an entire local MCP server into one file: the code, its dependencies, and a manifest describing how to run it. A desktop client like Claude Desktop can install the bundle with a click, the way a browser installs an extension. The format began life as DXT (Desktop Extensions) before being renamed MCPB, so you'll still see the old name in older docs and tooling. ### The problem MCPB solves Installing a local MCP server traditionally means a terminal: have Node.js or Python installed, run an npx or uvx command, then hand-edit a JSON config file with exact paths and arguments. For developers that's a minor chore; for everyone else it's a wall. An MCPB collapses all of that into open-file-and-confirm. Dependencies travel inside the bundle, the manifest tells the client how to launch the server, and any settings the server needs (API keys, folder paths) are collected through a UI the client renders from the manifest's declared configuration fields. ### What's inside a bundle An .mcpb file is a zip archive. At its root sits a manifest.json declaring the server's name, version, entry point, runtime requirements, and user-configurable settings; alongside it lives the server code and its bundled dependencies — node_modules for a Node server, packaged libraries for Python. Because dependencies are vendored in, the bundle runs without the user pre-installing a runtime toolchain — the central promise of the format. ### When to ship an MCPB vs npm or PyPI MCPB targets non-technical desktop users; package registries target developers. If your audience configures Cursor and Claude Code by hand, an npm or PyPI package is lighter to maintain and composes with existing workflows. If your audience is Claude Desktop users who have never opened a terminal, a bundle removes the single biggest drop-off point in your install funnel. These aren't exclusive. A server's registry manifest (server.json) can declare several package types at once — npm for developers, MCPB for desktop users, a remote endpoint for those who want nothing installed — and registries like Loomal's index list whichever distribution forms the author has published. ### Limits to keep in mind MCPB is a local, stdio-based distribution format, so it inherits local-server constraints: the server runs on the user's machine, updates require shipping a new bundle, and client support is concentrated in desktop apps — as of mid-2026, editor and framework clients generally still expect package or remote configuration. For monetized servers, remote hosting over Streamable HTTP remains the natural shape, since x402 payment gating happens at an endpoint you operate. ## Micropayments URL: https://loomal.ai/glossary/micropayments Micropayments are very small payments — often a cent or less — made for individual units of consumption, such as a single API call or document lookup. ### What are micropayments? A micropayment is a payment small enough that traditional payment infrastructure cannot process it profitably — typically anything from a few dollars down to fractions of a cent. The unit being paid for is correspondingly small: one API request, one web page scraped, one row of data returned. The idea is decades old. What changed recently is the arrival of two things at once: blockchains with sub-cent transaction fees, and AI agents that consume services in exactly the tiny, irregular increments micropayments were designed for. ### Why card networks can't process micropayments Card processing typically costs around $0.30 plus a percentage per transaction. Charge someone $0.02 for an API call and the processor fee is fifteen times the price. Traditional rails work around this by aggregating — subscriptions, prepaid credits, monthly invoices — which forces buyers to commit money before they know how much they will actually use. Aggregation also requires an account relationship: signup, stored card, billing address, invoice history. That overhead is tolerable for a human buying one SaaS subscription. It collapses when the buyer is an AI agent that needs to touch fifty different services once each during a single task. ### How stablecoins on Base make micropayments viable Stablecoin settlement on low-fee Layer 2 chains removes the fixed-cost floor. On Base, an Ethereum L2, a USDC transfer settles in roughly two seconds for a fee that is a small fraction of a cent. At that cost structure, charging $0.01 for a single call is a perfectly sound business: the payment is final on-chain, there is no chargeback window, and no invoice needs to exist. The x402 protocol packages this into an HTTP flow. A server answers an unpaid request with HTTP 402 Payment Required and a price; the caller's wallet signs a USDC payment and retries; the server verifies, settles on Base, and serves the response. Each request is its own complete commercial transaction. ### Micropayments and AI agents Agents are the first customers for whom micropayments beat every alternative. An agent researching a topic might need three searches from one provider, one PDF extraction from another, and a geocoding lookup from a third. Subscribing to all three providers would cost orders of magnitude more than the work performed; per-call micropayments cost exactly what was consumed. Micropayments also make spend controllable. An agent's wallet can enforce a per-call ceiling and a total budget, turning cost control into a wallet policy rather than a contract negotiation. ### Micropayments in the Loomal Index Loomal's marketplace applies micropayments to MCP servers and APIs: a developer claims their listing, sets a per-call USDC price (minimum $0.01), and any x402-capable agent can pay and call it. Sellers receive a signed Ed25519 receipt and a Base transaction hash for every settled call, so revenue is auditable down to the individual request. Loomal charges a 5% fee on settled transactions, currently waived. ## Model Context Protocol (MCP) URL: https://loomal.ai/glossary/model-context-protocol The Model Context Protocol (MCP) is an open standard from Anthropic that lets AI applications connect to external tools, data sources, and APIs through one common interface. ### What is the Model Context Protocol? The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, that defines how AI applications discover and use capabilities exposed by external programs called MCP servers. Before MCP, connecting a language model to a database, a search engine, or an internal API meant writing a bespoke integration for every model-tool pair. MCP replaces that N-times-M problem with a single protocol: build one server, and any MCP-compatible client can use it. Clients include Claude Desktop, Claude Code, Cursor, Windsurf, VS Code's Copilot, and dozens of other applications. Servers range from a few lines of code wrapping a local SQLite file to production endpoints serving thousands of agents. ### How MCP works MCP is a client-server protocol built on JSON-RPC 2.0. When a client connects, the two sides negotiate capabilities, then the client can list and invoke what the server offers. The protocol defines three server-side primitives: tools (functions the model can call, like search_flights or run_query), resources (readable data such as files or database records), and prompts (reusable prompt templates). It also defines client-side primitives that flow the other way: sampling lets a server request an LLM completion from the client, and roots let the client scope which directories or URIs the server may operate within. ### Local vs remote MCP servers MCP supports two main transports. Local servers run as a subprocess on the user's machine and communicate over stdio — the client launches them with a command like npx or uvx. Remote servers run on the operator's infrastructure and speak Streamable HTTP, so a client anywhere connects with just a URL. The distinction matters in practice. Local servers can touch the filesystem and private credentials but require per-machine setup. Remote servers need zero installation and can serve many users at once, which is why hosted endpoints have become the dominant pattern for commercial MCP services. ### What MCP deliberately leaves out: payments The protocol standardizes discovery and invocation, but it says nothing about how a tool author gets paid when an agent calls their server. Authentication exists (OAuth for remote servers), but there is no native metering or billing primitive. That gap is where the x402 protocol fits. A monetized MCP server intercepts an unpaid tool call, responds with HTTP 402 and a price, and the agent's wallet pays in USDC — settled on Base in about two seconds — before the handler runs. MCP handles what a tool does; x402 handles what it costs. ### MCP in the Loomal Index Loomal indexes thousands of MCP servers — open-source stdio packages and hosted remote endpoints alike — with live-probed tool lists for each, so you can see exactly what a server exposes before connecting. Maintainers can claim a listing by verifying GitHub ownership, attach a per-call price (minimum $0.01), and start receiving x402 payments from agents without changing how their server speaks MCP. ## OAuth URL: https://loomal.ai/glossary/oauth OAuth is an open standard for delegated authorization that lets an application access a user's resources on another service without ever seeing the user's password. ### What is OAuth? OAuth is an authorization framework that solves a specific problem: how does a user let application A act on their data inside service B without handing application A their service-B password? Instead of sharing credentials, the user approves a scoped grant, and the application receives a token that works only for the permissions the user agreed to. The current widely deployed version is OAuth 2.0, with OAuth 2.1 consolidating its security best practices. Almost every "Sign in with Google" or "Connect your Slack workspace" button is an OAuth flow underneath. ### How an OAuth flow works In the common authorization-code flow, the application redirects the user to the service's authorization server, which asks the user to approve a list of scopes — say, read-only access to their calendar. On approval, the service redirects back with a short-lived authorization code, which the application exchanges for an access token (and usually a refresh token for renewing it). Every subsequent API request carries the access token. The service can inspect it, enforce its scopes, and the user can revoke it at any time without changing their password. Scoping and revocability are the two properties that make OAuth safer than password sharing or long-lived API keys. ### OAuth in MCP servers MCP servers that connect to user accounts — email, calendars, project trackers, design tools — typically authenticate via OAuth. The MCP specification adopts OAuth as the standard authorization mechanism for remote servers over Streamable HTTP, so a client like Claude Desktop can walk the user through granting access the first time it connects. For local stdio servers, the picture is looser: many still take an API key or a pre-obtained OAuth token through environment variables in the client's config file, because there is no browser-based flow to hand off to. ### OAuth vs API keys vs x402 These three mechanisms answer different questions and frequently coexist on one server. OAuth answers "whose data may this application touch, and with what permissions?" An API key answers "which developer account is calling?" — simpler, but unscoped and harder to revoke safely. x402 answers a question neither addresses: "has this specific call been paid for?" A practical example: an MCP server that summarizes a user's inbox might use OAuth to read the mailbox on the user's behalf, and x402 to charge the calling agent $0.02 per summary. Authorization establishes permission; payment establishes commercial terms. Confusing the two is a common design mistake — an OAuth token proves consent, not payment. ### Why this matters for agentic commerce As AI agents act for users across many services, delegated authorization becomes the consent layer of the agent economy: the user grants narrow, revocable access once, and the agent operates inside those bounds. On Loomal's marketplace, listings note how each server authenticates, so you can tell at a glance whether a server needs an OAuth connection, an API key, or nothing beyond an x402 payment. ## Open Source vs. Hosted MCP Server URL: https://loomal.ai/glossary/open-source-vs-hosted-mcp-server The distinction between an MCP server you download and run yourself from source code, and one operated by its author as a managed remote endpoint you simply connect to. ### What's the difference? An open-source MCP server is published as code — usually on GitHub and as an npm or PyPI package — that you download, configure, and run on your own machine or infrastructure. A hosted MCP server is run by its author (or a third party) and exposed as a remote endpoint; you add a URL to your client and never touch the code. The two categories often overlap: many popular servers ship open-source code and a hosted endpoint for the same functionality. The question is not which kind of software it is, but who operates the process that answers your agent's calls. ### How open-source MCP servers run A self-run server typically starts as a subprocess of your MCP client over the stdio transport — the client config specifies a command like npx -y some-server or uvx some-server, plus environment variables for any credentials. You supply your own API keys, you control the version, and nothing leaves your machine except the upstream API calls the server makes. The costs are operational. Every machine needs its own setup, dependency updates are on you, and if the server wraps a paid upstream API you still need an account and key with that provider. Free as in license does not mean free as in operation. ### How hosted MCP servers run A hosted server lives on the operator's infrastructure and speaks Streamable HTTP. Connecting takes one URL — no runtime, no package install, no local credentials beyond whatever authentication the endpoint requires. The operator handles scaling, upgrades, and uptime, and can serve thousands of clients from one deployment. The tradeoffs are dependency and trust: your agent's requests transit the operator's servers, an outage on their side is an outage for you, and the operator's terms govern rate limits and data handling. ### Which fits monetization? Hosted servers are the natural fit for per-call monetization, because the operator controls the endpoint and can gate it with an x402 challenge: an unpaid request gets HTTP 402 plus a price, the agent's wallet pays in USDC, settlement lands on Base in about two seconds, and the handler runs. There is no equivalent choke point for code a user runs locally — once the source is on someone's machine, there is nothing to gate. This is why the common commercial pattern is open core, hosted edge: keep the code open source for self-hosters, and offer a paid hosted endpoint for everyone who would rather pay $0.01 a call than run infrastructure. ### How Loomal treats both The Loomal Index lists both kinds. Open-source server listings carry the package name, install command, and live-probed tool list; hosted listings carry the remote endpoint. A maintainer who verifies GitHub ownership can claim their listing and attach x402 pricing to a hosted endpoint — minimum $0.01 per call, with Loomal's 5% fee on settled transactions currently waived — while the open-source distribution stays exactly as free as its license says. ## Pay-Per-Call API URL: https://loomal.ai/glossary/pay-per-call-api A pay-per-call API is an API priced so that each individual request is billed separately — often via x402 — instead of through a subscription or pre-purchased credits. ### What is a pay-per-call API? A pay-per-call API charges at the granularity of a single request: one call, one price, settled at the moment of use. There is no monthly plan to pick, no credit pack to pre-buy, and no invoice at the end of the month — the commercial relationship begins and ends with each request. The model has always been attractive in theory; what made it impractical was payment infrastructure. Card rails cannot profitably move $0.01, so APIs historically aggregated usage into subscriptions and tiers. Per-call USDC settlement removed that constraint. ### How a pay-per-call request works with x402 The caller sends a normal request with no payment attached. The server responds with HTTP 402 Payment Required, including the price, the currency (USDC), and the payment address. The caller's wallet signs the payment requirement and retries the request with a payment header. The server verifies the payment, settlement lands on Base in roughly two seconds, and only then does the handler execute. The response carries an Ed25519-signed receipt and the Base transaction hash, so both sides hold cryptographic proof of exactly what was bought and when. Because the agent pays before the handler runs and on-chain settlement is final, there are no chargebacks and no unpaid usage to chase. ### Pay-per-call vs API keys and subscriptions Key-and-subscription billing front-loads friction: create an account, store a card, choose a tier, provision a key, then track usage against quota. That sequence assumes a human with a browser. Pay-per-call inverts it — the first request is also the signup, because the payment itself is the credential. The economics differ too. Subscriptions overcharge light users and undercharge heavy ones; the provider absorbs the mismatch with rate limits and overage fees. Per-call pricing maps revenue one-to-one onto cost: a request that costs the provider compute earns the provider money, every time. ### Why pay-per-call suits AI agents Agents are sporadic, wide-ranging consumers. A single task might require one geocoding call, three searches, and a PDF extraction from three different providers — then never touch any of them again for a week. Negotiating contracts or maintaining subscriptions with every provider an agent might conceivably use does not scale; paying $0.01 at the moment of need does. For the agent's operator, per-call pricing also makes spend legible: the wallet's transaction log is the cost report, itemized down to the individual request. Budget enforcement moves into wallet policy — a per-call ceiling here, a per-task cap there — instead of waiting for an end-of-month invoice to reveal what happened. ### Listing a pay-per-call API on Loomal Loomal's marketplace lets developers list MCP servers and API endpoints as pay-per-call: claim the listing, set a per-call price (minimum $0.01), and any x402-capable agent can discover and pay for it with no contract negotiation. Repricing is a single field in the console, so you can adjust as you learn what calls are worth. Loomal takes a 5% fee on settled transactions, currently waived. ## Pay-Per-Use Pricing URL: https://loomal.ai/glossary/pay-per-use-pricing Pay-per-use pricing is a model that charges based on actual consumption — per call, per token, per document — rather than a flat subscription fee. ### What is pay-per-use pricing? Pay-per-use pricing ties what a customer pays directly to what they consume. Instead of a flat monthly fee that buys an entitlement, the seller defines a unit of usage and a price per unit, and the bill is simply units consumed times price. Cloud computing normalized the model — paying per GB stored or per second of compute — and LLM APIs extended it to tokens. The defining property is alignment: cost tracks value delivered. A customer who consumes nothing pays nothing; a customer who consumes heavily pays proportionally. ### Choosing the unit of usage The unit is the central design decision. It should map to something the buyer recognizes as value and the seller can meter honestly: a search query, a page scraped, a document parsed, a thousand tokens processed, a row of data returned. A unit that is too coarse (per month) recreates the subscription problem; one too fine (per byte) becomes illegible to the buyer. For tools exposed over MCP, the natural unit is usually the tool call itself — which is why per-call pricing is the most common form of pay-per-use in the agent economy, though it is not the only one. ### Pay-per-use vs subscriptions Subscriptions trade fairness for predictability. The seller gets recurring revenue and the buyer gets a known bill, but light users subsidize heavy ones and every new customer must clear an upfront commitment hurdle before consuming anything. Usage-based pricing removes the hurdle and the cross-subsidy at the cost of revenue predictability for the seller and bill variability for the buyer. In human SaaS, that variability is a real objection. For software buyers — agents operating under a wallet budget — it is far less of one, because the budget itself caps exposure and every unit consumed was explicitly chosen. ### Why pay-per-use fits AI agents An agent working through a task touches many tools sporadically: a few calls here, one call there, often against services its operator has never used before and may never use again. Subscription signup is a wall an autonomous process cannot easily climb — it involves forms, emails, and cards. Metered access via x402 removes the wall entirely: the agent encounters a price in an HTTP 402 response, its wallet pays in USDC, and settlement completes on Base in about two seconds. Consumption-based pricing also keeps incentives clean on the seller's side. Revenue scales with the load the seller actually serves, so there is no pressure to throttle heavy users behind quotas the way flat-fee plans require. ### Pay-per-use on Loomal MCP servers monetized through Loomal use pay-per-use in its per-call form: the owner sets one USDC price per call, with a minimum of $0.01, and repricing is a single field in the console. Loomal applies a 5% fee on settled transactions, currently waived, and every settled call produces an Ed25519-signed receipt the buyer can audit. ## Payment Channel URL: https://loomal.ai/glossary/payment-channel A payment channel is an off-chain mechanism that lets two parties exchange many small payments while recording only the opening and closing balances on-chain. ### What is a payment channel? A payment channel is a construct that moves repeated payments between two parties off the blockchain. The parties lock funds in an on-chain contract once, exchange any number of cryptographically signed balance updates privately, and finally close the channel by submitting the last agreed state. The chain sees two transactions — open and close — no matter how many payments happened in between. Bitcoin's Lightning Network is the best-known implementation, built to make sub-cent payments viable on a chain where each on-chain transaction can cost dollars. ### How a payment channel works Opening a channel means depositing funds into a contract that both parties can see. Each payment is then just a signed message updating the split of that deposit — instant, free, and private. Either party can close the channel at any time by publishing the most recent signed state, and the contract pays out accordingly. The security model relies on the signatures: an old, stale balance cannot be replayed because the counterparty holds a newer one and the contract gives them a window to dispute. The price of this design is complexity — channels need capital locked up front, liveness to watch for disputes, and routing infrastructure if payments must hop between parties without a direct channel. ### Why channels mattered for micropayments On chains with high or volatile fees, settling a $0.01 payment individually is economically absurd — the fee can exceed the payment a hundredfold. Channels solved this by amortizing one settlement cost across thousands of payments, which historically made them the only credible architecture for machine-speed micropayments. ### Why x402 on Base usually skips channels The calculus changes when settlement itself is nearly free. On Base, an Ethereum L2, a USDC transfer settles in roughly two seconds for a fee that is a small fraction of a cent — cheap enough that a $0.01 API call can simply be settled on-chain, individually, every time. That is the design x402 takes: each HTTP 402 challenge is answered with its own payment, verified and settled per call, with no channel to open, fund, monitor, or close. Per-call settlement also buys simplicity that matters for agent-to-API commerce. The two parties need no prior relationship or locked capital, any agent can pay any server on first contact, and every call yields an independent on-chain record plus an Ed25519-signed receipt. Channels and channel-like constructs still make sense for extremely high-frequency pairs — thousands of payments per second between the same two parties — but for the sporadic, many-counterparty traffic typical of AI agents, direct settlement is the simpler and sufficient answer. ### Where you'll encounter the concept When evaluating agent payment stacks, the channel question is a useful lens: systems built for pre-funded, bilateral relationships descend from channel thinking, while systems built for open, pay-on-first-contact access — like the x402-priced listings in the Loomal Index — descend from per-call settlement. Knowing which model a protocol assumes tells you most of what you need about its capital and trust requirements. ## Prompts (MCP) URL: https://loomal.ai/glossary/mcp-prompts Prompts in MCP are reusable, parameterized prompt templates that a server exposes to clients, packaging a recommended workflow with the right framing and arguments built in. ### What are prompts in MCP? Prompts are one of the three primitives an MCP server can expose, alongside tools and resources. A prompt is a named, parameterized template the server defines — "summarize-pr", "analyze-table", "triage-error" — that a client can fetch, fill in with arguments, and hand to the model as a starting message. Crucially, prompts are user-controlled by design: the person picks one to invoke, typically from a menu or as a slash command, rather than the model deciding on its own. ### How prompts work on the wire A client calls prompts/list to discover what a server offers — each entry has a name, a description, and a declared set of arguments. When the user invokes one, the client calls prompts/get with the argument values, and the server returns fully rendered messages ready for the model's context. Because the server renders the template, it can do real work at fetch time: pull in current data, embed a resource, or tailor the message to the arguments — the "template" can be as dynamic as the author wants. ### Why server authors ship prompts Most MCP servers have a right way to be used — a sequence of tool calls, a framing that yields good results — and prompts let the author encode that knowledge into the protocol itself instead of hoping users read the README or the model infers it. A database server, for example, might ship an "explain-schema" prompt that instructs the model to inspect tables before writing queries. Without it, every user rediscovers that workflow by trial and error; with it, the best practice is one slash command away. ### Prompts vs tools vs resources The three MCP primitives differ in who initiates them. Tools are model-controlled: the LLM decides to call them mid-task. Resources are application-controlled: the client chooses what data to load into context. Prompts are user-controlled: a human explicitly picks a template to start or steer a workflow. A useful shorthand — tools are verbs the model can use, resources are nouns the client can read, and prompts are recipes the user can invoke. ### Prompts and monetized servers Prompts themselves carry no payment semantics — in x402-monetized servers it's the tool calls that are priced and paid per call. But prompts shape the economics indirectly: a well-designed prompt steers agents toward efficient tool sequences, which matters to whoever is paying per call. When evaluating a server on Loomal's index, shipped prompts are a good signal that the author has thought about how their tools should actually be used. ## RAG (Retrieval-Augmented Generation) URL: https://loomal.ai/glossary/rag-retrieval-augmented-generation Retrieval-Augmented Generation (RAG) is a technique that retrieves relevant external information and feeds it into an LLM's context before the model generates a response. ### What is RAG? Retrieval-Augmented Generation (RAG) is a way to ground a language model's answers in information it was never trained on. Rather than relying solely on what the model memorized, a RAG system first searches an external knowledge base for content relevant to the question, then places that content into the prompt so the model can reason over it directly. The technique addresses the two structural limits of any LLM: a training cutoff (the model knows nothing after it) and a closed corpus (it never saw your private documents). RAG sidesteps both by injecting the missing knowledge at query time. ### How a RAG pipeline works A typical pipeline has an indexing phase and a query phase. During indexing, documents are split into chunks, each chunk is converted into an embedding — a numeric vector capturing its meaning — and the vectors are stored in a vector database. At query time, the user's question is embedded the same way, the database returns the chunks whose vectors sit closest to the question's, and those chunks are concatenated into the model's context window alongside the question. Production systems layer refinements on top: hybrid search that mixes keyword and vector matching, rerankers that re-score the retrieved candidates, and chunking strategies tuned to the document type. But the skeleton — embed, store, retrieve, augment, generate — stays the same. ### Why RAG matters Grounding generation in retrieved text measurably reduces hallucination, because the model can quote and cite rather than reconstruct from memory. It also keeps knowledge current without retraining: update the index and the system's answers update with it. And it makes provenance possible — a RAG answer can point at the exact chunks it drew from, which matters anywhere answers must be auditable, from legal research to internal support bots. ### RAG and MCP In agent systems, retrieval increasingly arrives as a tool call rather than a built-in pipeline stage. Many MCP servers exist specifically to provide RAG-style retrieval — over library documentation, codebases, scraped web content, or proprietary datasets — so any MCP client can bolt grounded search onto its model without building an indexing pipeline of its own. This reframes RAG as a service boundary: the hard parts (corpus maintenance, embedding, index freshness) live behind the server, and the agent just asks questions. The same server then works identically across Claude Desktop, Cursor, or any other MCP client. ### Monetizing retrieval Retrieval is one of the cleanest fits for per-call pricing, because each query has an obvious unit of value and a real marginal cost (embedding, vector search, sometimes reranking). A retrieval-focused MCP server listed on Loomal can attach an x402 price per query — minimum $0.01 — and agents pay in USDC, settled on Base in about two seconds, before the search runs. Curated, well-maintained corpora are exactly the kind of asset agents will pay to query rather than rebuild. ## Rate Limiting URL: https://loomal.ai/glossary/rate-limiting Rate limiting restricts how many requests a client can make to an API within a given time period, protecting the service from overload and abuse. ### What is rate limiting? Rate limiting caps the number of requests an API will accept from a given client — identified by API key, IP address, or account — within a time window: per second, per minute, per day. Requests beyond the cap are rejected, typically with HTTP 429 Too Many Requests and a Retry-After header indicating when to try again. It exists for good reasons: protecting backends from overload, containing the blast radius of buggy or malicious clients, and enforcing the boundaries between pricing tiers. ### How rate limits are implemented The most common algorithm is the token bucket: each client's bucket refills at a steady rate and holds up to a maximum, so short bursts are allowed as long as the long-run average stays under the cap. Alternatives include fixed windows (simple but spiky at window boundaries) and sliding windows (smoother, slightly costlier to track). Well-behaved APIs advertise their limits in response headers — remaining quota, reset time — so clients can pace themselves instead of discovering the wall by hitting it. ### Rate limiting and AI agents Agent traffic is bursty by nature: an agent decomposing a research task may fire twenty tool calls in ten seconds, then go quiet for an hour. Free tiers tuned for human-paced usage feel suffocating to that pattern — the agent burns through a daily quota in one task and then stalls, or worse, fails mid-task with a 429 it cannot negotiate around. For MCP servers this is a recurring complaint: the quota that protects the operator from abuse also blocks the legitimate heavy use that would make the server genuinely valuable. ### Quotas vs prices as the throttle Rate limits and per-call prices are both ways of rationing access; they differ in who decides the cutoff. A quota is an arbitrary line set by the operator — generous for some workloads, crippling for others. A price lets the caller decide: an agent paying $0.01 per call via x402 can make exactly as many calls as the work justifies, throttled only by its own wallet budget. The operator's revenue rises with load rather than being capped by their own free tier. The two are complements, not substitutes. A monetized server still needs operational limits against runaway clients and denial-of-service traffic — but the limit can sit far above normal usage, because payment, not the quota, is doing the economic rationing. The x402 design helps here too: the payment is verified before the handler runs, so unpaid floods never reach expensive code paths. ### What to check on a listing When evaluating an MCP server or API for agent workloads, look at the rate limits alongside the pricing model: a low hard cap matters more than a headline price for bursty workloads. Listings in the Loomal Index surface live-probed tool lists and pricing, and a per-call x402 listing generally signals that the budget — not a quota — is the practical ceiling. Check the server's own documentation for residual operational limits. ## Resources (MCP) URL: https://loomal.ai/glossary/mcp-resources Resources are the MCP primitive that lets servers expose readable data — files, database rows, API responses — identified by URIs and loadable into the model's context. ### What are resources in MCP? Resources are one of the three core primitives a Model Context Protocol server can offer, alongside tools and prompts. A resource is a piece of data the server makes readable — a file's contents, a database record, a log, a cached API response — that the client can fetch and place into the model's context window. Where tools let a model do things, resources let a session know things. They're the protocol's answer to "how does relevant data get in front of the model?" ### How resources are addressed and read Every resource has a URI — file:///home/user/notes.md, postgres://db/customers/42, or any scheme the server defines. Clients discover what's available via resources/list and fetch content with resources/read, getting back text or binary data with a declared MIME type. Servers can also expose resource templates (parameterized URIs like weather://{city}/current) and emit notifications when a resource changes, letting clients keep loaded context fresh without polling. ### Resources vs tools The boundary is read versus act. Resources are typically read-only and take no arbitrary input arguments — you read what exists at a URI. Tools accept structured arguments, perform computation or side effects, and return results. Control differs too: in the MCP design, resources are application-controlled — the client (often steered by the user) decides what to load into context — while tools are model-controlled, invoked when the LLM decides mid-task. The same underlying data could be exposed both ways; a server might offer a schema as a browsable resource and a run-query tool that acts on it. ### When a server author should reach for resources Use resources when the value is the data itself and the user should choose what's relevant: project files, configuration, documentation pages, recent records. Use tools when the client needs to ask questions the server must compute answers to. In practice many servers skip resources and expose everything as tools, because tool support is universal across MCP clients while resource UI support has historically been spottier. That's a pragmatic call, but it gives up the clean separation between loading context and taking action. ### Resources in the paid-tool economy Per-call x402 monetization on platforms like Loomal attaches prices to tool calls, since a tool invocation is the natural billable event — the agent pays in USDC before the handler runs. For servers whose core value is data access, this nudges design: expose the chargeable lookup as a tool, and keep resources for the freely readable surrounding context like schemas and documentation. ## Roots (MCP) URL: https://loomal.ai/glossary/roots-mcp Roots are an MCP mechanism by which a client tells a server which directories or URIs it is allowed to operate within. ### What are roots in MCP? Roots are the Model Context Protocol's way for a client to declare the boundaries a server should work within. Each root is a URI — most commonly a file:// path to a directory — and the set of roots tells the server: these locations are relevant and permitted; stay inside them. The canonical example is a filesystem server. Without roots, a server capable of reading files has no protocol-level signal about which files the user intended to expose. With roots, the client can scope it to the current project folder and nothing else. ### How the roots exchange works Roots are a client-side capability, declared during the initial capability negotiation. A server that wants to know its boundaries sends a roots/list request, and the client responds with the current set of root URIs, each with an optional human-readable name. If the user changes scope — opening a different project, say — the client emits a roots/list_changed notification so the server can re-query. This inverts the usual MCP direction: most requests flow client-to-server, but roots (like sampling) flow server-to-client, letting the server ask the environment about its own constraints. ### Why roots matter for security Servers that read or write local files are among the most powerful and most dangerous things an agent can touch. Roots provide the basic sandboxing primitive: least privilege expressed at the protocol level. An IDE-style client can grant a code-analysis server the repository directory while keeping the user's home directory, credentials, and SSH keys out of scope. Roots also improve behavior, not just safety. A server that knows the project boundary can index the right tree, resolve relative paths sensibly, and avoid wandering into node_modules or system directories. ### What roots do not guarantee Roots are a contract, not a cage. The protocol communicates boundaries, but enforcement depends on the server honoring them — a malicious or buggy local server running with your OS user's permissions can still read whatever your account can read. Treat roots as a necessary signal and pair them with real isolation (containers, OS sandboxes, restricted accounts) when running untrusted code. This is one reason provenance matters when choosing servers. A listing whose maintainer has claimed it through GitHub ownership verification — as on the Loomal Index — tells you who stands behind the code that your roots are trusting. ### Roots vs resources Roots and resources both involve URIs but answer opposite questions. Resources are content the server offers to the client — documents, records, files it can serve. Roots are constraints the client imposes on the server — where it may legitimately operate. A filesystem server might expose the files under its roots as resources; the roots came first and defined what could be offered. If you remember one direction, remember this one: resources flow outward from the server, roots flow inward from the client. ## Sampling (MCP) URL: https://loomal.ai/glossary/sampling-mcp Sampling is an MCP feature that lets a server request an LLM completion from the connected client, enabling agentic behavior inside the server without its own model access. ### What is sampling in MCP? Sampling is the Model Context Protocol feature that reverses the usual relationship between server and model: instead of only responding to tool calls, an MCP server can ask the connected client to run an LLM completion on its behalf. The name comes from the underlying operation — sampling tokens from a language model. Concretely, a server handling a tool call might need intelligence mid-task: summarize a 50-page result before returning it, classify an ambiguous input, or decide which of three strategies to take next. Sampling lets it borrow the client's model for exactly that step. ### How a sampling request works Sampling is a client capability negotiated at connection time. When a server needs a completion, it sends a sampling/createMessage request containing the messages to complete, plus optional model preferences — hints about whether to prioritize speed, cost, or intelligence — a system prompt, and a max token count. The client runs the completion against whatever model it has access to and returns the result. The specification puts a human in the loop by design: clients should give the user visibility and control over incoming sampling requests, since a server is effectively asking to spend the user's tokens and inject content into a model conversation. The server never learns the client's API key and never chooses the exact model; it only expresses preferences. ### Why sampling exists Without sampling, any server needing model access would have to ship its own API key and bill its own usage — pushing credential management and inference cost onto every server author and fragmenting model access across the ecosystem. Sampling centralizes both in the client: one key, one bill, one place to enforce policy, while servers stay stateless and credential-free. This division also makes server logic more portable. The same server gets smarter or cheaper depending on which client connects to it, without a single code change. ### Sampling and agentic servers Sampling turns servers from passive tool providers into participants that can reason. A research server can iteratively refine queries based on intermediate results; a data-cleaning server can resolve edge cases that defeat regex. Combined with tools, it allows multi-step agent loops to live behind a single MCP tool call. There is a commercial angle worth noting: a server whose tool calls embed model-quality reasoning is delivering more value per call than a thin API wrapper, which supports a higher per-call price when the server is monetized — on Loomal, anywhere from the $0.01 minimum upward, paid by the calling agent over x402 before the handler runs. ### Limitations to be aware of Client support for sampling is uneven — as of mid-2026 many popular MCP clients still do not implement it, so production servers treat it as an enhancement with a fallback path rather than a dependency. Check your target client's documentation before building around it. There is also a latency cost: every sampling round-trip includes a full model completion, so a tool that samples repeatedly will feel slow compared to one that computes directly. ## SDK (Software Development Kit) URL: https://loomal.ai/glossary/sdk-software-development-kit An SDK is a collection of libraries, tools, code samples, and documentation that helps developers build against a specific platform or protocol. ### What is an SDK? A software development kit (SDK) is everything a platform vendor or protocol maintainer packages up so developers can build against their system without reimplementing it from scratch: libraries that wrap the raw interface, type definitions, code samples, test utilities, and documentation. Where an API is the contract, the SDK is the toolbox for honoring it. Good SDKs collapse weeks of protocol-reading into an afternoon of coding. They encode the maintainer's knowledge of edge cases — retries, encoding rules, version negotiation — so each developer does not rediscover them in production. ### SDK vs API: the distinction An API defines what requests a system accepts and what responses it returns; it exists whether or not anyone wraps it. An SDK is a concrete artifact — usually a package on npm or PyPI — that speaks that API for you in your language, with native types and idiomatic error handling. You can always call an API directly over HTTP; you use the SDK because hand-rolling request framing and auth for every call is wasted effort and a source of bugs. ### The official MCP SDKs The Model Context Protocol project maintains official SDKs in multiple languages — TypeScript and Python are the most used, with others including Java, Kotlin, C#, and Go. They handle the protocol plumbing: JSON-RPC 2.0 framing, transport setup over stdio or Streamable HTTP, capability negotiation, and the lifecycle of requests and notifications. The practical effect is that an MCP server author writes almost no protocol code. Registering a tool is a function call with a name, a schema, and a handler; the SDK does the rest. The same applies on the client side, where the SDK manages connecting to servers and dispatching tool invocations. ### SDKs in agentic commerce Payment protocols follow the same pattern as transport protocols: the standard defines the wire format, and SDKs make it usable. On the seller side, x402 middleware libraries let a server answer unpaid requests with HTTP 402 and verify payment headers before the handler runs; Loomal's @loomal/sdk reduces MCP monetization to wrapping a tool registration with requirePayment(). On the buyer side, wallet SDKs let an agent detect a 402 response, sign a USDC payment, and retry — without the agent's business logic knowing payments exist. When the SDK boundary is drawn well, the entire commercial layer — pricing, settlement on Base, Ed25519 receipts — lives in library code rather than in every developer's application. ### Evaluating an SDK before depending on it Before adopting an SDK, check maintenance signals: release cadence against protocol revisions, issue responsiveness, and whether it is the official implementation or a community port. For MCP work specifically, SDK version matters because the protocol has evolved — Streamable HTTP superseded the older SSE transport, and an outdated SDK can quietly lock you to deprecated behavior. The Loomal Index records each listed server's package name and registry, which is a quick way to see what an implementation is actually built on. ## Settlement Layer URL: https://loomal.ai/glossary/settlement-layer A settlement layer is the underlying blockchain or network where a payment is finally and irreversibly recorded. ### What is a settlement layer? A settlement layer is the underlying blockchain or network where a payment is finally and irreversibly recorded. Whatever happens above it — price negotiation, payment authorization, receipt generation — the settlement layer is where value actually moves from one party to another and the record becomes permanent. The distinction matters because most of a payment flow is coordination, not settlement. An HTTP 402 challenge tells an agent what to pay; a facilitator verifies the payment is well-formed; a receipt proves the payment happened. None of those steps move money. The settlement layer does, and it is the single source of truth for whether a payer actually paid. ### The settlement layer in an x402 payment In the x402 protocol, the settlement layer is typically Base, an Ethereum Layer 2. When an AI agent hits a paid endpoint, the server responds with HTTP 402 and a payment requirement. The agent's wallet signs a USDC transfer, the facilitator verifies and submits it, and the transfer is confirmed on Base in roughly two seconds. Everything before that confirmation is reversible in the trivial sense that nothing has happened yet. After confirmation, the payment is final. The server can safely run the tool handler or return the resource, because there is no mechanism for the agent to claw the funds back. ### Why Base works as a settlement layer for agents Agent payments are small and frequent — a single agent might make thousands of $0.01 calls in a day. That rules out settlement layers where confirmation takes minutes or transaction fees exceed the payment itself. Base settles in about two seconds with fees low enough that a one-cent USDC transfer remains economical. Base also inherits Ethereum's security model as a Layer 2, which is what gives finality its weight: once a transfer is recorded, the cost of rewriting that history is prohibitive. For a seller pricing MCP tool calls at $0.01 each, that is the property that replaces the entire chargeback-and-dispute apparatus of card payments. ### Settlement finality vs chargebacks Card networks settle slowly and conditionally — funds arrive in days and can be reversed for up to 120 days through chargebacks. That model assumes a human cardholder who might dispute a purchase. It breaks down when the buyer is software making thousands of automated calls. On-chain settlement inverts the model: the payment is verified before the work is done, settles in seconds, and cannot be reversed. The seller takes no credit risk and the buyer gets a signed Ed25519 receipt plus a transaction hash as proof. Disputes shift from "reverse the payment" to "prove what was delivered", which receipts handle. ### Settlement layers and the Loomal Index Every paid listing on the Loomal Index settles on Base. When a seller claims an MCP server listing and attaches a per-call price (minimum $0.01), agent payments flow through the x402 protocol and land as USDC transfers on the Base settlement layer, with Loomal taking a 5% fee on settled transactions — currently waived. Sellers never interact with the chain directly: the facilitator handles verification and submission, and the console shows settled revenue per listing. The settlement layer stays invisible until you want to audit it — at which point every payment resolves to a public Base transaction. ## SSE (Server-Sent Events) Transport URL: https://loomal.ai/glossary/sse-transport SSE transport is an earlier MCP remote transport that paired a long-lived Server-Sent Events stream for server-to-client messages with HTTP POST for client-to-server messages. ### What is SSE transport? SSE transport is the original mechanism the Model Context Protocol used for remote servers. The client opened a persistent Server-Sent Events connection to receive messages from the server, while sending its own JSON-RPC messages through separate HTTP POST requests to a companion endpoint. Server-Sent Events itself is a long-standing web standard: a one-directional HTTP stream where the server pushes text events to a connected client. MCP borrowed it to give remote servers a way to push responses and notifications back to clients, since plain HTTP request/response has no native server-push channel. ### How the two-endpoint design worked An MCP client connecting over SSE transport first issued a GET request to the server's SSE endpoint, establishing the event stream. The server's first event told the client which URL to POST its messages to. From then on, the client POSTed JSON-RPC requests to that URL and read responses off the SSE stream. Splitting the conversation across two endpoints worked, but it created operational friction: the long-lived GET connection had to survive proxies, load balancers, and serverless platforms that dislike held-open requests, and the server had to correlate POSTed requests with the right open stream. ### Why Streamable HTTP superseded it The MCP specification replaced HTTP+SSE with Streamable HTTP transport, which collapses both directions into a single endpoint. The client POSTs a JSON-RPC message and the server replies with either a plain JSON response or, when it needs to stream, a server-sent event stream on that same response — no separate standing connection required. The single-endpoint model is friendlier to standard web infrastructure: stateless deployments, CDNs, and middleware all see ordinary HTTP requests. That includes payment middleware — a Streamable HTTP server can return an HTTP 402 challenge per request, which is awkward to retrofit onto a held-open SSE stream. ### SSE transport today SSE transport is deprecated but far from gone. Many remote MCP servers deployed before the transition still expose an SSE endpoint, and most major clients retain backward-compatible support, often falling back to SSE when a Streamable HTTP connection attempt fails. If you operate a remote server that only speaks SSE, migrating to Streamable HTTP is worth scheduling: new clients increasingly assume it, the spec treats it as the current standard, and monetization tooling targets it. If you are choosing a transport for a new server in mid-2026, there is no reason to start with SSE. ### SSE transport and the Loomal Index The Loomal Index lists remote MCP servers across both transports, and the distinction matters when a listing is claimed for monetization. Loomal's x402 payment flow gates each tool call with an HTTP 402 response before the handler runs — a per-request pattern that maps cleanly onto Streamable HTTP. Server owners still running legacy SSE endpoints typically migrate transports as part of claiming and pricing their listing, which also future-proofs the server for clients that have dropped SSE fallback. ## Stablecoin URL: https://loomal.ai/glossary/stablecoin A stablecoin is a cryptocurrency designed to maintain a stable value relative to a reference asset, usually the US dollar. ### What is a stablecoin? A stablecoin is a digital asset engineered to hold a steady value, most commonly pegged 1:1 to the US dollar. Unlike Bitcoin or Ethereum, whose prices float freely, a stablecoin is designed so that one token is always redeemable for — and trades at — one dollar. The point is to combine two properties that normally live in different systems: the programmability and instant settlement of a blockchain, and the price stability of fiat currency. A stablecoin payment moves like crypto but denominates like dollars. ### How stablecoins hold their peg Fiat-backed stablecoins — the kind used in agent payments — hold reserves of cash and short-term US treasuries equal to the tokens in circulation. The issuer mints a token when a dollar comes in and burns one when a holder redeems. USDC, issued by Circle, follows this model and publishes regular reserve attestations. Other designs exist — crypto-collateralized and algorithmic stablecoins — but they carry more peg risk, and the history of algorithmic stablecoins includes notable collapses. For machine-to-machine payments where the amounts must be predictable, fiat-backed reserves are the conservative choice. ### Why stablecoins matter for agentic commerce An AI agent buying API calls needs predictable prices. If a tool call costs $0.01, the agent's budget logic, the seller's revenue forecast, and the receipt that proves payment all depend on that amount meaning the same thing at request time and settlement time. Volatile assets break this. A price quoted in ETH can drift between the 402 challenge and on-chain confirmation, and a seller earning thousands of micro-amounts in a volatile token inherits market risk on every call. Stablecoins remove the conversion problem entirely: prices are set in dollars, paid in dollars, and accounted in dollars, so neither side of an automated transaction needs to think about exchange rates at all. ### Stablecoins in the x402 flow The x402 protocol settles payments in stablecoins, with USDC on Base as the default. When a server responds with HTTP 402, the payment requirement names an exact USDC amount; the agent's wallet signs the transfer, settlement confirms on Base in about two seconds, and the handler runs. Stablecoins are what make x402's minimum viable price so low. Card networks effectively floor transactions around $0.30 in fees; a USDC transfer on Base costs a fraction of a cent, so per-call prices of $0.01 — the minimum on the Loomal Index — are economically sound. ### What sellers should know If you price an MCP server or API on the Loomal Index, you receive USDC — a dollar-denominated asset you can hold, convert, or off-ramp through any major exchange. There is no exposure to crypto price swings between earning and withdrawing, and settlement is final with no chargeback window. Loomal charges a 5% fee on settled transactions, currently waived, and every payment carries a signed Ed25519 receipt plus a Base transaction hash, so revenue reconciles down to individual calls. ## Stdio Transport URL: https://loomal.ai/glossary/stdio-transport Stdio transport is a local MCP transport where the client launches the server as a subprocess and exchanges messages over standard input and output. ### What is stdio transport? Stdio transport is the simplest way to run a Model Context Protocol server: the client spawns the server as a child process and exchanges JSON-RPC messages over the process's standard input and standard output streams. No network, no ports, no TLS — just two processes talking through pipes on the same machine. It is the default transport for locally installed servers distributed via npm, PyPI, or as standalone binaries. When a Claude Desktop or Cursor config file specifies a command like npx or uvx with a package name, that server runs over stdio. ### How it works The client launches the configured command, then writes newline-delimited JSON-RPC messages to the server's stdin and reads responses from its stdout. The server's stderr is left free for logging, which is why MCP servers must never print non-protocol output to stdout — a stray console.log corrupts the message stream and is one of the most common causes of a server failing to connect. The server's lifetime is tied to the client session: it starts when the client launches it and exits when the pipe closes. There is no separate deployment, health check, or uptime concern. ### When stdio is the right choice Stdio shines when the server needs local context: reading the user's filesystem, driving a local browser, or querying a database reachable from the developer's machine. It also inherits the user's local environment, so credentials can come from environment variables in the client config rather than a hosted secret store. For tool authors, stdio is the lowest-friction distribution path — publish a package and any MCP client can run it with a one-line config entry. The Loomal Index lists thousands of stdio-distributed servers alongside remote ones, with the install command on each listing. ### Limitations: one user, one machine, no payments Stdio is inherently single-user and local. There is no way to share one running instance across users, no network boundary to attach authentication to, and no request/response surface where payment middleware could intervene. The transport has no built-in support for per-call billing. This is why x402 monetization targets remote servers. A payment gate needs an HTTP exchange to return a 402 challenge and verify payment before the handler runs; a subprocess piping JSON over stdin has no equivalent interception point. Servers that want to charge per call typically expose a hosted Streamable HTTP endpoint, sometimes alongside an open-source stdio distribution. ### Stdio vs remote transports Choose stdio for local capability and zero-ops distribution; choose Streamable HTTP when the server should be multi-tenant, centrally updated, or monetized. Many projects ship both: the free stdio package for self-hosters and a hosted remote endpoint with per-call USDC pricing. On the Loomal Index, that pattern maps to a single claimed listing whose owner can attach x402 pricing (minimum $0.01 per call) to the hosted endpoint while the open-source package remains freely installable — the software stays free; the hosted calls are what carry a price. ## Streamable HTTP Transport URL: https://loomal.ai/glossary/streamable-http-transport Streamable HTTP transport is the current MCP transport for remote servers, using HTTP POST with optional server-sent event streaming over a single endpoint. ### What is Streamable HTTP transport? Streamable HTTP is the modern transport the Model Context Protocol uses for remote servers, replacing the earlier HTTP+SSE design. A client sends JSON-RPC requests to a single HTTP endpoint, and the server answers each request with either a plain JSON payload or — when it needs to send multiple messages or stream progress — a server-sent event stream on that same response. The defining feature is the single endpoint. Where the old SSE transport split the conversation between a long-lived GET stream and a separate POST endpoint, Streamable HTTP keeps every exchange inside one ordinary HTTP request/response cycle. ### How a session works The client POSTs an initialize request to the server's MCP endpoint and receives a session identifier, which it includes on subsequent requests. Each tool call, resource read, or prompt request is its own POST; the server decides per response whether to reply with JSON or upgrade to an event stream for long-running work. Servers can be stateless or stateful. A stateless server treats every request independently, which suits serverless platforms; a stateful one maintains session context. Either way, nothing about the transport requires a held-open connection, so it deploys cleanly behind load balancers, CDNs, and edge runtimes. ### Why it replaced HTTP+SSE The two-endpoint SSE design fought standard web infrastructure: proxies time out idle streams, serverless platforms bill for held-open connections, and correlating POSTed requests with the right stream added server complexity. Streamable HTTP removes the standing connection while keeping streaming available when a response genuinely needs it. Most clients retain SSE fallback for older servers, but the specification treats Streamable HTTP as the current standard, and new remote servers in mid-2026 should target it exclusively. ### Why it matters for monetization Because every exchange is plain HTTP, a Streamable HTTP server can sit behind the same middleware as any web API — including payment middleware. That is the hook the x402 protocol uses: a paid tool call first receives an HTTP 402 Payment Required response carrying the price and payment address; the agent's wallet signs a USDC payment and retries; the payment settles on Base in about two seconds, and only then does the handler run. This per-request gate is impractical on stdio (no HTTP surface) and awkward on legacy SSE (the stream is already open). Streamable HTTP is effectively the transport that makes per-call MCP pricing possible. ### Streamable HTTP on the Loomal Index The Loomal Index identifies which listed MCP servers expose remote endpoints, and live-probes tool lists from servers that do. When a maintainer claims a listing, attaching x402 pricing — minimum $0.01 per call, settled in USDC with signed Ed25519 receipts — assumes a Streamable HTTP endpoint, since that is where the payment gate lives. If your server is stdio-only today, deploying a Streamable HTTP version is the prerequisite step before pricing it; the open-source local package can keep shipping unchanged alongside it. ## Tool Calling (Function Calling) URL: https://loomal.ai/glossary/tool-calling Tool calling is the mechanism by which an LLM selects and invokes an external function or MCP tool to complete a task. ### What is tool calling? Tool calling — also known as function calling — is the mechanism by which a large language model selects and invokes an external function to complete a task. Instead of only generating text, the model emits a structured request naming a tool and supplying arguments that match the tool's input schema; the host application executes it and returns the result. It is the bridge between language and action. A model cannot fetch today's weather or query a database by generating prose, but it can generate a call to a tool that does. ### The tool calling loop The host application gives the model a list of available tools, each with a name, description, and JSON Schema for its inputs. When the conversation requires one, the model outputs a tool call — say, search_listings with {"query": "weather MCP servers"} — instead of a final answer. The host executes the call, appends the result to the conversation, and the model continues: it may answer, call another tool, or chain several calls. This loop repeating autonomously is the core of what makes a system an agent rather than a chatbot. ### What MCP standardizes Model providers each ship their own tool calling API, but the tools themselves used to be bespoke — every application hand-wired its own functions. The Model Context Protocol standardizes the supply side: an MCP server publishes its tools with names, descriptions, and schemas in a uniform format, and any MCP client can discover and call them. The practical effect is an interoperable tool ecosystem. The same web-scraping or database server works identically whether the caller is Claude Desktop, Cursor, or a custom agent — which is what makes a cross-client index of servers, like the Loomal Index, possible at all. ### Writing tools that get called well The model chooses tools based entirely on their declared name, description, and schema, so those fields are effectively your tool's API documentation and its marketing. Ambiguous descriptions cause missed or wrong calls; overly broad schemas cause malformed arguments. Tool authors should name tools by action, describe exactly when to use them (and when not to), and constrain inputs with enums and required fields. On the Loomal Index, where live-probed tool lists are shown on each server listing, those descriptions are also what prospective users read before installing. ### When a tool call costs money Tool calling assumes execution is free, but the underlying work — a search query, an OCR pass, a paid data lookup — often is not. The x402 protocol attaches a price to the call itself: the server answers an unpaid call with HTTP 402, the agent's wallet pays the stated amount in USDC, settlement confirms on Base in about two seconds, and the handler runs. Crucially, the model's side of the loop is unchanged — it emits the same structured call. Payment happens in the transport layer between client and server, which is why monetizing a tool (minimum $0.01 per call on Loomal) requires no changes to how agents call it. ## Tool Use (LLM) URL: https://loomal.ai/glossary/tool-use-llm Tool use is the general capability of a large language model to invoke external functions or APIs as part of generating a response. ### What is tool use? Tool use is a large language model's capability to recognize that a task requires information or action beyond its own generation — live data, a calculation, a side effect in another system — and to invoke an appropriate external tool to get it. The model decides when to act, picks a tool from those it has been offered, and incorporates the result into its response. Where "tool calling" names the wire-level mechanism (the structured request the model emits), tool use names the broader capability: knowing that a question about today's stock price cannot be answered from training data, and reaching for a quote tool instead of guessing. ### What tool use changes about LLMs Without tools, a model is bounded by its training cutoff and its context window — it can describe the world as of its last update but cannot observe or change it. Tool use removes both bounds: a model can fetch current data, search private corpora, run code, send messages, and write to databases. It also changes the failure modes. A model that guesses produces fluent wrong answers; a model with tool use can ground its answer in a fetched result, and the host application can log exactly which tool returned what. Much of the reliability gain in modern agents comes from replacing recall with retrieval and action. ### Tool use across clients via MCP Every major model provider trains for tool use, but historically each application wired up its own toolset. The Model Context Protocol decouples the two: tools live in MCP servers with standardized descriptions and schemas, and any MCP-compatible client can offer them to its model. The result is that the same capability travels: a developer who connects a web-search or filesystem server gets identical tool behavior in Claude Desktop, Cursor, or a custom LangChain agent. The Loomal Index catalogs thousands of these servers, with live-probed tool lists so you can see what each one actually exposes before connecting it. ### The economics of tool use Tool use turns models into high-volume API consumers. An agent researching a topic might issue dozens of search, scrape, and lookup calls per task — and unlike human users, agents do not sign up for accounts, enter card details, or read pricing pages. Traditional API monetization (keys, subscriptions, invoices) assumes a human in the loop that tool use removes. Per-call payment closes that gap. With the x402 protocol, a tool answers an unpaid call with HTTP 402 and a price; the agent's wallet pays in USDC, settlement lands on Base in roughly two seconds, and the tool runs. The model's tool-use behavior is untouched — payment is handled between client and server, per call, starting at $0.01 on the Loomal Index. ### Tool use, agents, and what comes next Tool use is the load-bearing capability under every more ambitious label — agents, autonomous workflows, agentic commerce. An autonomous agent is, mechanically, a model using tools in a loop with goals and memory; agentic commerce is that loop extended with a wallet so the tools it reaches for can charge it. For tool builders, this is the demand signal worth planning for: as of mid-2026, the fastest-growing consumers of APIs are models, and the tools they can discover (via MCP registries and indexes) and pay (via x402) are the ones positioned to capture that usage. ## USDC URL: https://loomal.ai/glossary/usdc USDC is a US dollar-pegged stablecoin issued by Circle, used as the default settlement currency for x402 payments. ### What is USDC? USDC (USD Coin) is a stablecoin pegged 1:1 to the US dollar and issued by Circle. Each token is backed by reserves of cash and short-term US treasuries, with regular attestations published, so one USDC is designed to always be redeemable for one dollar. Functionally, USDC is a dollar that moves on a blockchain: transfers settle in seconds, work across borders without banking hours, and can be initiated by software holding a signing key — no card network, account number, or human approval in the path. That last property is what makes it the workhorse currency of agentic commerce: an AI agent can hold and spend USDC directly. ### Why USDC for agent payments Machine-to-machine payments need three things: price stability, low transfer cost, and programmability. USDC delivers all three. An agent paying $0.01 for an API call knows the amount will not drift in value between the request and on-chain confirmation — which a payment denominated in ETH or BTC cannot guarantee. Sellers benefit from the same property in reverse: revenue earned across thousands of micro-payments arrives as a dollar-denominated asset, not a volatile token that must be hedged or hastily converted. Accounting stays in dollars end to end. ### USDC in the x402 flow The x402 protocol uses USDC as its default settlement currency. A paid endpoint answers an unpaid request with HTTP 402 and a payment requirement naming an exact USDC amount and address. The agent's wallet signs the transfer, a facilitator verifies and submits it, and the payment confirms on Base — Coinbase's Ethereum Layer 2 — in roughly two seconds. Settlement is final: there is no chargeback window, and the buyer receives a signed Ed25519 receipt plus a Base transaction hash as proof of payment. The seller's handler only runs after the USDC has settled. ### Why Base, and what transfers cost USDC exists on many chains, but x402 settlement standardizes on Base because transfer fees there are a fraction of a cent and confirmation takes about two seconds. That fee profile is what makes one-cent payments viable — on Ethereum mainnet, gas alone could exceed a micro-payment many times over. For comparison, card networks impose effective minimums around $0.30 per transaction in fixed fees. USDC on Base moves the economic floor low enough that the Loomal Index's minimum per-call price of $0.01 leaves real margin for the seller. ### USDC on the Loomal Index Every priced listing on the Loomal Index settles in USDC on Base. Sellers claim their MCP server or API listing, set a per-call price from $0.01 up, and receive USDC as agents pay; Loomal's fee is 5% on settled transactions, currently waived. Received USDC can be held, used to pay for other agent tools, or converted to fiat through any major exchange or Circle directly. The console tracks settled revenue per listing, and each payment reconciles to a public transaction on Base. ## Vector Database URL: https://loomal.ai/glossary/vector-database A vector database is a database optimized for storing and searching high-dimensional embeddings, the backbone of semantic search and RAG. ### What is a vector database? A vector database is a database optimized for storing embeddings — numerical representations of text, images, or other data in high-dimensional space — and running fast similarity search over them. Instead of matching exact keywords, it finds the stored items whose vectors sit closest to a query's vector, which corresponds to semantic similarity. Ask a keyword index for "refund policy" and it matches those literal words; ask a vector database and it also surfaces a paragraph about "returning a purchase for your money back", because the embeddings of the two phrases land near each other. ### How similarity search works Each item is first passed through an embedding model, which outputs a vector of hundreds or thousands of floating-point dimensions. The database indexes these vectors using approximate nearest neighbor (ANN) structures — HNSW graphs are the most common — so that finding the closest matches among millions of vectors takes milliseconds rather than requiring a full scan. Queries follow the same path: embed the query text, search the index, return the top-k nearest items ranked by distance (typically cosine similarity). Most vector databases also support metadata filters, so a search can be restricted to one tenant, document set, or date range. ### Vector databases in RAG Retrieval-augmented generation (RAG) is the dominant use case. Documents are split into chunks, embedded, and upserted into a vector database; at question time, the system embeds the user's query, retrieves the most relevant chunks, and feeds them into the LLM's context so it answers from the source material instead of from memory. The vector database is what makes this work at scale — it is the component that turns "a million pages of documentation" into "the five passages that answer this question", inside the latency budget of a chat response. ### How AI agents use vector databases Agents reach vector databases through MCP servers that wrap them, exposing operations like search, upsert, and delete as agent-callable tools. The Loomal Index lists servers in its RAG and knowledge-memory categories that wrap popular vector stores, so an agent in Claude Desktop or Cursor can query a knowledge base the same way it calls any other tool. This pattern also gives agents durable memory: an agent can embed and store what it learns during a session, then retrieve it semantically in later sessions — a capability raw LLM context windows cannot provide. ### The per-query economics Vector search has real marginal cost — embedding compute, index memory, and storage all scale with usage — which makes it a natural fit for per-call pricing rather than flat subscriptions. A hosted retrieval endpoint that charges per query aligns revenue with the work each search actually performs. On the Loomal Index, the owner of a retrieval-backed MCP server can claim the listing and attach x402 pricing — from $0.01 per call, paid in USDC and settled on Base in about two seconds — so agent queries pay for themselves without API keys or subscription onboarding. ## Webhook URL: https://loomal.ai/glossary/webhook A webhook is an HTTP callback that a server sends to a configured URL when a specific event occurs. ### What is a webhook? A webhook is an HTTP callback: one system registers a URL with another, and the second system sends an HTTP POST to that URL whenever a relevant event happens — a new order, a completed job, a failed payment. The receiver gets notified in real time instead of having to ask. The name plays on "hook" from programming: you hook your code into someone else's event stream, except the hook crosses the network as a plain HTTP request carrying a JSON payload describing the event. ### Webhooks vs polling The alternative to a webhook is polling — repeatedly calling an API to ask "anything new?". Polling wastes requests when nothing has changed and adds latency when something has: an event is only noticed on the next poll. Webhooks invert the direction so the event source pushes the moment something happens. The tradeoff is operational. A webhook receiver must run a publicly reachable endpoint, verify that incoming payloads are authentic (usually via an HMAC signature header), handle retries and duplicate deliveries, and tolerate out-of-order events. Polling is wasteful but simple; webhooks are efficient but demand server-side discipline. ### Webhooks in agent workflows AI agents intersect with webhooks in two ways. First, some MCP servers expose tools for managing them — registering a callback for a repository push, a CMS publish, or a payment event as one step in an automated workflow the agent assembles. Second, webhooks can trigger agents: an inbound event POST can kick off an agent run that processes the event, calls further tools, and acts on the result. In automation platforms, a webhook node is frequently the entry point of an agent-powered pipeline. ### Where x402 removes the webhook Traditional payment APIs lean heavily on webhooks because payment is asynchronous: you create a charge, then wait for a callback confirming it succeeded, failed, or was disputed. Integrating card payments means building and securing that callback infrastructure. x402 payments are synchronous, which deletes this entire category of webhook. The agent pays inside the request — the server returns HTTP 402, the wallet pays in USDC, settlement confirms on Base in about two seconds, and the response comes back with a signed Ed25519 receipt. There is no later "payment succeeded" event to deliver because the result is known before the response is sent, and on-chain settlement has no chargeback events to notify about. ### Webhooks and the Loomal Index The Loomal Index lists MCP servers across communication, automation, and developer-tool categories whose tools create and manage webhooks in external services. Browsing a listing shows its live-probed tool list, so you can check whether a server exposes webhook management before connecting it. For sellers, the contrast is practical: pricing a listing on Loomal requires no webhook handlers, because per-call x402 revenue settles synchronously — the console reports settled transactions without any callback plumbing on your side. ## x402 URL: https://loomal.ai/glossary/x402 x402 is an open, HTTP-native payment protocol that lets any server charge any client per request using HTTP status code 402 (Payment Required). ### What is x402? x402 is an open, HTTP-native payment protocol that enables any server to charge any client per request without a billing system, API keys, or subscription management. It uses HTTP status code 402 (Payment Required) — reserved in the HTTP spec since 1999 but never standardized until now. ### How x402 works The x402 protocol uses a two-call exchange. On the first call, the client makes a standard HTTP request with no payment. The server responds with HTTP 402 and a payment requirement object containing the price, accepted currency, and payment address. On the second call, the client signs the payment requirement using its wallet and retries the original request with a payment header. The server verifies the signature, settles the payment, and handles the request. The entire exchange is synchronous from the client's perspective. For AI agents, the payment negotiation happens automatically — the agent pays and retries without interrupting its workflow. ### x402 and MCP monetization x402 is the payment protocol that powers MCP monetization. When an AI agent calls a paid MCP tool, the MCP server uses x402 to return the payment requirement. The agent's wallet handles the x402 negotiation and the tool runs once payment settles. Loomal implements x402 on the seller side via the requirePayment() middleware, and on the buyer side via agent wallets provisioned in each project. Tool authors never need to implement x402 directly — the middleware abstracts the full protocol. ### Is x402 an open standard? Yes. x402 is an open protocol. Loomal's machine-readable discovery feed lives at api.loomal.ai/.well-known/x402-discovery.json (also at api.loomal.ai/v0/discover), and any facilitator can implement the same wire format. Loomal is one of the first production implementations of x402 for MCP servers. ### x402 vs traditional payment protocols A card payment integration needs a billing system, webhooks, and API keys; x402 needs a single HTTP response header. Card networks impose a roughly $0.30 plus 2.9% floor; x402 settles amounts as small as $0.01 in USDC. Card settlement takes two-to-seven business days and carries a chargeback window; x402 settles in about two seconds on Base and is final on-chain. Most importantly, card rails were never designed for machine-to-machine payments — x402 treats that as the native use case. ## x402 Protocol URL: https://loomal.ai/glossary/x402-protocol The x402 protocol is an open payment standard that uses the HTTP 402 status code to let AI agents pay for API and MCP tool access automatically, settled in stablecoins. ### What is the x402 protocol? The x402 protocol is an open standard, originally proposed by Coinbase, for instant machine-to-machine payments over HTTP. It revives status code 402 Payment Required — reserved in the HTTP specification since the 1990s but left unused — and defines what a 402 response should actually contain: a structured payment requirement an automated client can fulfil on the spot. The target buyer is software. Where every previous payment rail assumed a human filling in a checkout form or provisioning an API key, x402 lets an AI agent encounter a paywall mid-task, pay it, and continue — no account, no card form, no human. ### The protocol flow An agent requests a paid resource with no payment attached. The server replies 402, enclosing the price, accepted currency, and recipient address. The agent's wallet evaluates the requirement, signs a stablecoin payment authorization — typically USDC — and retries the identical request with the payment attached. A facilitator verifies the payment and submits it to the Base network, where it settles in roughly two seconds. Only after settlement does the server execute the handler; the response carries a signed Ed25519 receipt and the on-chain transaction hash. One resource, two requests, payment complete inside the round trip. ### Design properties that matter Three properties distinguish x402 from retrofitted billing. It is pre-paid: the agent pays before the handler runs, so sellers extend no credit and unpaid traffic costs them nothing. It is final: on-chain settlement has no chargeback window, eliminating the 120-day reversal risk of card rails. And it is granular: amounts as small as $0.01 settle economically, far below the roughly $0.30 fixed-fee floor of card transactions. It is also stateless from the buyer's perspective — no API key to provision, rotate, or leak. Authorization is the payment itself, which means a brand-new agent can transact with a brand-new server on first contact. ### Roles in the x402 ecosystem The protocol defines clean roles. The resource server prices and serves content or tool calls. The client — usually an agent's wallet library — interprets 402 responses and signs payments. The facilitator verifies payments and handles settlement so servers never touch blockchain infrastructure. The settlement layer, Base, is where transfers become final. Because the wire format is open, these roles are mix-and-match: any compliant wallet can pay any compliant server through any facilitator. As of mid-2026, implementations exist across multiple languages and agent frameworks, with discovery feeds letting agents find priced endpoints programmatically. ### x402 and the Loomal Index Loomal runs one of the first production x402 deployments for MCP servers. The Loomal Index catalogs thousands of MCP server and API listings; maintainers who claim a listing can attach x402 pricing per tool call — minimum $0.01 — and agents pay in USDC with settlement on Base. Loomal charges 5% on settled transactions, currently waived, and exposes a machine-readable discovery feed so agents can locate priced endpoints without scraping. For a server author, the protocol's complexity is absorbed by middleware: one wrapper around the tool registration, and the 402 negotiation happens before the handler is invoked.