Loomal - Monetize any MCP server in 5 minutes with no % skim.

@ranjan_kumar45 Thank you! That was a deliberate choice—we want sellers to capture the full value of what they build rather than lose margin to another platform fee. We’d be very interested to hear how the comparison looks against the payment solutions you’re using today.

@aymnart Honest answer: at this stage we deliberately keep it simple.

Transactions are micro — often $0.01 per call — so the economics of fraud barely work. There's no chargeback vector (no cards), settlement is on-chain and verifiable, and spend mandates cap what any agent can pay out. Worst case is losing cents, not a lump sum.

On the seller side, we vet sellers before they go live on the Index — at our current scale, that's manual and deliberate. As volume grows, that shifts to automated screening plus reputation built from settled transactions.

On the "no cut" part — fraud prevention isn't funded by transaction fees anyway. We monetize on volume tiers beyond the free allocation, not by skimming payments.

@tarqiya_forgah I think it will be a hybrid. Marketplaces like Loomal will be important for discovery, trust, reputation, pricing, and onboarding—especially while the ecosystem is still fragmented.

Over time, I do expect more open protocols to emerge so agents can negotiate and transact directly with providers. But even then, there will still be a need for a trusted discovery and reputation layer. Our view is that Loomal can evolve from being just a marketplace into part of that underlying commerce infrastructure.

@sabber_ahamed Only settled calls count. Malformed requests get rejected before any payment happens, and failed requests never settle — so no charge to the agent, and nothing burned from your 1,000.

The metering literally sits after settlement in our flow — the counter only ever sees completed payments, so attempts, retries, and errors can't touch it by construction. Your free 1,000 are 1,000 real, settled transactions.

@jean_noel_escande That "quietly" is the part that gets me too — the first time we watched an agent discover a tool, pay for it, and move on mid-task with no human anywhere in the loop, it stopped feeling theoretical. The plumbing for that moment is all we're really building. Thanks for the kind words — and if you've built anything agents should be able to buy, the door's open 🙂

@kevin_win This is exactly the kind of thing we hoped would show up in the comments 😄 The OBD agent is a perfect example because it nails why agents need wallets: the moment your agent knows the fault code, it has more actionable context than you do — it knows the part, the urgency, and the fix. Making it stop there and wait for a human to phone a garage is throwing away the whole point.

The flip side is what makes it work end-to-end: the mechanic doesn't need an "AI strategy" — just a bookable, payable endpoint. Diagnostic lookup priced per call, appointment slot pre-paid against the fault code. That's a listing, not a re-platforming.

Please do experiment with the SDK — and when the car agent books its first appointment, come back and tell this thread. That's the demo nobody could argue with 🚗

@casterhq Thanks for the honest question — here's the simple version.

Agents can absolutely buy physical goods; nothing about the payment side cares whether the product is an API call or a pallet of casters. You ship the same way you do today — the only thing that changes is who clicked "buy."

For a store like yours there are a few paths, depending on how technical you want to get. If you have a developer (even a freelancer), the SDK works today — your catalog becomes something agents can browse and pay for programmatically. If you don't want to run anything yourself, we can host the endpoint for you — you define what you sell, we handle the agent-facing side. And for the no-code route, Shopify/WooCommerce-style plugins are coming that make it a checkbox in your existing dashboard.

Your category is actually a strong fit, by the way. Industrial supplies are exactly what purchasing agents automate first — a maintenance system that notices worn casters and reorders the same SKU is a far more natural agent purchase than impulse shopping.

Happy to help you figure out which path fits — reach out anytime.

@omri_ben_shoham1 Good question — the per-call model changes its shape. Agents never pre-buy access to your tool; every call is a fresh purchase of whatever's live at that moment. So there's no prepaid old contract to strand — anything an agent paid for already completed against the schema that existed when it paid, receipt included.

That said, breaking changes still break integrations, same as any API. Today there's one live version per listing, so the honest playbook is what good API sellers already do: list the new schema as a separate endpoint, run both side by side, deprecate the old one when traffic moves. Since listings are machine-readable, agents can re-check the schema before calling instead of discovering drift the hard way.

Grace periods as a platform feature — pinned schema versions on a listing — is a genuinely good idea, and this comment just moved it up the list

@faisal_arab Not first-come, and deliberately not pay-to-play either. Today agents search the Index by capability, and listings carry real signals — whether it's claimed, whether its tools are actually live, whether it has real usage — so a dead listing doesn't sit above a working one just because it arrived early.

The part I like most: because we don't take a % of anything, we have zero incentive to rank by who pays us more. As transaction history accumulates, ranking leans on the most honest signal that exists — settled calls. What agents actually pay for, repeatedly, is the curation. Reviews can be faked; repeat purchases at real cost can't

@jp_west Not currently — we're built on x402, which MPP is philosophically a sibling of: both standardize HTTP 402 so payment rides in the request itself. We went with x402 for instant USDC settlement and because it was live and proven when we built.

The good news for sellers: the winner of that protocol race matters less than it looks. Payment sits at the transport layer in our design — your listing and your code don't care which 402 dialect the agent speaks. If MPP earns real adoption, supporting it alongside x402 is an us-problem, not a re-integration for you. That's the point of betting on open protocols instead of rolling our own