Feature: Built-in billing/monetization for MCP tools via Agent Bazaar

[TombStoneDash]

Hey @QuantGeekDev 👋

Love what you've built with mcp-framework. We built something complementary — a billing + metering proxy for MCP servers called Agent Bazaar (noui.bot/docs/bazaar).

The problem we solve: MCP server developers can't earn revenue from their tools. The Bazaar adds a commerce layer — you set per-call pricing, agents call through our proxy, we handle metering + Stripe Connect payouts.

What's live:

• 6 tools, 2 providers
• Sub-cent precision metering (microcents)
• 82% payout to providers
• Self-service onboarding: https://noui.bot/providers/register
• TypeScript SDK: npm install @forthebots/bazaar-sdk

Since mcp-framework is TypeScript-native, integration would be natural. Imagine:

class MyTool extends MCPTool {
  pricing = { perCall: 0.001, freeTier: 100 };
  // ...
}

Would you be interested in adding monetization support? Happy to collaborate on a PR.

Docs: https://noui.bot/docs/bazaar

— Hud (TombStone Dash LLC)

[TombStoneDash]

Hey 👋 Quick update on this — the SDK is now live on npm!

npm install @forthebots/bazaar-sdk

Here's a minimal integration example:

import { BazaarProxy } from '@forthebots/bazaar-sdk';
const proxy = new BazaarProxy({ apiKey: process.env.BAZAAR_API_KEY });
// Wrap any MCP tool call to add billing
const result = await proxy.call('your-tool-name', params);
// That's it — billing, metering, and receipts handled automatically

The full billing spec is published at noui.bot/specs/mcp-billing-v1 — it covers metering, receipts, and how the proxy layer works without requiring changes to your existing tool implementations.

We're doing a Show HN on March 4 — would love any feedback, questions, or ideas from this community. If you're interested in testing the integration with this project, happy to help get it wired up.

[JiwaniZakir]

The proposed pricing field on MCPTool would tightly couple the framework to a specific third-party billing provider, which is a significant architectural commitment for a general-purpose framework — the MCP protocol itself has no billing semantics, so any implementation would live entirely outside the spec. A more framework-agnostic path would be middleware/interceptor hooks on tool invocation (e.g., a beforeCall/afterCall lifecycle in the base MCPTool class), which would let any billing layer — including Agent Bazaar — integrate without the framework taking a hard dependency on @forthebots/bazaar-sdk. The proxy model Agent Bazaar already uses is arguably the cleaner separation anyway, since it keeps metering infrastructure out of the tool author's code entirely.

[evidai]

For maintainers reading this thread — adding a data point on a different angle.

We've been shipping LemonCake (https://lemoncake.xyz). The design recently shifted: instead of "billing for human-facing API customers", the gateway now speaks x402 so AI agents can pay autonomously.

• Your MCP/API returns 402 + accepts[] when budget/auth is missing
• Agent presents a hard-capped Buyer Key, mints a Pay Token (JWT), passes Bearer
• Caps enforced server-side (per-mint / daily / monthly). Cannot exceed.
• 0% fee for the first 3,000 calls, 3% after. Live on Stripe off-session.
• Custody-free — we never hold funds.

If you're building an MCP that ends up wanted-but-uncharged (which is most), this gets you discoverable on the agent-payment side without rewriting your billing. 30-second demo (no signup): https://lemoncake.xyz/demo

(Disclosure: I'm working on LemonCake. Not affiliated with Agent Bazaar — different design, sharing as a comparison point so maintainers can compare options.)

[QuantGeekDev]

@evidai Please make a PR and I'll be happy to add it at the framework level

[evidai]

@evidai Please make a PR and I'll be happy to add it at the framework level

@QuantGeekDev That's great to hear — happy to put one together!

Before I start, a quick question on scope: are you thinking
(a) an example / docs showing how to wrap an MCPTool with the
LemonCake gateway (no framework changes), or
(b) a hook in the MCPTool base class (e.g. beforeCall / afterCall)
so any tool can opt into x402 billing without a proxy?

Either works on our end. (b) would give every mcp-framework user
one-line monetization — just want to make sure the direction fits
your vision for the framework before I write the PR.

[QuantGeekDev]

@evidai
One line monetization sounds awesome. Would be great to add to instructions on it as a separate section in "https://github.com/QuantGeekDev/mcp-framework-docs"

[evidai]

@QuantGeekDev Perfect — I'll open a PR against mcp-framework-docs with a monetization section shortly. Thanks!

[evidai]

@QuantGeekDev Just opened the docs PR: QuantGeekDev/mcp-framework-docs#17

Adds a Monetization section covering how to put any MCPTool behind the LemonCake gateway — no SDK, no changes to tool code. Let me know if you'd like any adjustments to the content or placement.

[evidai]

+1 to @JiwaniZakir's point — framework-agnostic invocation hooks (a beforeCall/afterCall lifecycle, or just letting tool authors wrap their handler) are the right call here. The MCP spec has no billing semantics, so a hard dependency on any one provider — mine included — would be the wrong commitment for a general-purpose framework.

Concrete data point that the hook model is sufficient (an update since my last comment): LemonCake now plugs in two ways, neither of which needs anything from the framework —

1. Gateway/proxy — zero code; the tool stays untouched.
2. A plain handler wrapper — lc.charge({ price })(handler). It's just a function around your tool's callback, so it drops straight onto an MCPTool's execute with no framework dependency. Shipped this week as @lemon-cake/mcp-sdk@1.0.0 (npx create-lemon-mcp scaffolds it).

So if mcp-framework exposed a lifecycle hook, a billing layer like this would slot into it cleanly — and until then the wrapper already works without one. Happy to keep the docs PR (#17) framework-agnostic in that spirit.

(Disclosure: I work on LemonCake; not affiliated with Agent Bazaar — sharing as a design data point.)