AI agent and MCP metering

Meter every billable tool call without coupling the agent to the biller

Record completed MCP tool calls or agent runs as usage events, route them through the customer subscription and tool-specific meter/product-item keys you configure, and keep a retry-safe ledger before pricing or payment logic gets involved.

Preview a real requestStart freeRead the MCP billing guide
What you get
  • Count tool calls, agent runs or another numeric usage signal
  • Route usage through customer subscriptions and tool-specific meter/product-item keys
  • Use one idempotency key per logical event so retries do not double-count
  • Keep raw usage history independent from the payment path

Choose the billable event explicitly

A tool invocation, completed run or another outcome can be the usage signal. Decide that policy in your application, then report the numeric event consistently instead of inferring it later from logs.

Route by customer and tool

Use a customer subscription ingest key, then route distinct billable tool streams through the product item and meter keys you configure. The usage endpoint stays the same across those streams.

Make retries safe

Derive or store a stable idempotency key for the logical billable event. If a producer retries delivery, reuse the same key rather than creating another unit of usage.

Keep failed-work policy in your application

UsageBox records the values you send; it does not decide whether a partial or failed agent action should be billable. Emit usage according to the commercial policy your product actually promises.

Aggregate before financial operations

Use the retained events and rollups as the quantity layer, then let Stripe, another billing system or your own code apply per-call prices, subscriptions, credits or invoice rules.

Keep auth and metering decoupled

OAuth, API keys, rate limiting and MCP transport concerns can evolve independently from the usage ledger. The metering contract only needs the authenticated producer and the usage event.

Implementation pattern

Record the completed billable tool call once

Use the customer subscription plus the product item and meter that represent the tool stream. Your application decides whether a call is billable before it emits the usage event.

A transport retry of this same tool-call event should reuse the same idempotency key so it cannot become a second unit of usage.

curl -X POST 'https://api.usagebox.com/api/v1/usage' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '[{"subscription":"sub_customer-acme-...","product_item":"item_search-tool-...","meter":"meter_tool-calls-...","value":1}]'

Product boundary

UsageBox is the meter, not the whole MCP monetization stack

The product deliberately owns usage evidence and aggregation. MCP authentication, authorization, quotas, rate limiting, pricing, invoices and payments remain separate concerns.

UsageBox owns

  • Usage-event ingestion
  • Idempotency and dedupe
  • Customer subscription routing
  • Meter/product-item routing
  • Raw-event history and rollups

Keep outside

  • OAuth and client auth
  • Rate limits and quotas
  • Per-tool prices
  • Invoices and tax
  • Payments and payouts

See the request before you create an account

Choose the usage signal, inspect the exact payload, then create a free key only when the contract fits your integration.

Preview a real requestStart freeSee pricing