为任何 MCP 服务器添加 Stripe 订阅、按调用计费 和 x402 加密货币支付 功能 —— 无需编写任何计费代码。
MCP 计费网关是一个托管的计费代理，位于 AI 代理和您的 MCP 服务器之间。它会自动处理支付验证、使用量跟踪和层级强制执行。您只需注册服务器、设置定价计划，并将调用者指向代理 URL 即可。无需编写计费代码。
实时服务：https://mcp-billing-gateway-production.up.railway.app
pip install mcp-billing-gateway或者使用 uvx:
uvx mcp-billing-gateway添加到 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows)：
{
"mcpServers": {
"mcp-billing-gateway": {
"command": "uvx",
"args": ["mcp-billing-gateway"]
}
}
}添加到项目中的 .cursor/mcp.json：
{
"mcpServers": {
"mcp-billing-gateway": {
"command": "uvx",
"args": ["mcp-billing-gateway"]
}
}
}添加配置后重启编辑器以激活 MCP 服务器。
Related MCP server: Agent Bazaar
工具 | 描述 |
| 返回服务能力、支持的支付方式、功能和集成文档 |
本地 MCP 服务器提供服务发现功能。完整的计费功能在托管网关上运行 —— 请注册为运营商并通过它代理您的 MCP 服务器。
AI Agent → MCP Billing Gateway → Your MCP Server
(billing enforced here)注册为运营商并获取 API 密钥
注册您的 MCP 服务器 URL 和定价计划
将调用者指向您的代理别名：https://mcp-billing-gateway-production.up.railway.app/proxy/{your-slug}/mcp
调用者通过 Stripe API 密钥或 x402 USDC 支付 —— 计费过程透明处理
按调用计费 —— 按工具调用次数向调用者收费（法币或加密货币）
订阅 —— 带有调用限制的月度/年度 Stripe 计划
分级定价 —— 免费层级 + 基于使用量的付费层级
x402 微支付 —— AI 代理无需 API 密钥即可在 Base 链上使用 USDC 支付
运营商仪表板 —— 实时跟踪收入、使用量和调用者
MCP 传输 —— /mcp/ 端点提供完整的 Streamable HTTP MCP 传输
curl -X POST https://mcp-billing-gateway-production.up.railway.app/api/v1/operator/register \
-H "Content-Type: application/json" \
-d '{"email": "you@example.com", "name": "Your Name"}'响应：
{
"operator_id": "op_abc123",
"api_key": "bg_live_xxxxxxxxxxxx",
"message": "Operator registered successfully"
}curl -X POST https://mcp-billing-gateway-production.up.railway.app/api/v1/servers \
-H "Authorization: Bearer bg_live_xxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"name": "My MCP Server",
"upstream_url": "https://your-mcp-server.com/mcp",
"proxy_slug": "my-server"
}'curl -X POST https://mcp-billing-gateway-production.up.railway.app/api/v1/servers/{server_id}/plans \
-H "Authorization: Bearer bg_live_xxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"name": "Pay as you go",
"billing_model": "per_call",
"price_per_call_usd_micro": 10000,
"free_calls_per_month": 100
}'{
"mcpServers": {
"my-server": {
"url": "https://mcp-billing-gateway-production.up.railway.app/proxy/my-server/mcp",
"headers": {
"Authorization": "Bearer CALLER_API_KEY"
}
}
}
}方式 | 适用对象 | 如何操作 |
Stripe 订阅 | 人类开发者 | 通过 Stripe Checkout 进行月度或年度计划 |
Stripe 按调用计费 | 人类开发者 | 每次工具调用消耗积分 |
x402 微支付 | AI 代理 | Base 链上的 USDC，无需 API 密钥 |
# Using the MCP client
result = await session.call_tool("get_billing_info")
print(result)
# {
# "service": "MCP Billing Gateway",
# "version": "0.1.0",
# "payment_methods": ["stripe_subscription", "stripe_metered", "x402_crypto"],
# "features": ["Per-call usage tracking", "Tiered pricing", ...],
# "live_service": "https://mcp-billing-gateway-production.up.railway.app"
# }# 1. Register
API_KEY=$(curl -s -X POST .../api/v1/operator/register \
-H "Content-Type: application/json" \
-d '{"email": "dev@example.com", "name": "Dev"}' | jq -r .api_key)
# 2. Add your server
SERVER_ID=$(curl -s -X POST .../api/v1/servers \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "my-tool", "upstream_url": "https://my-tool.com/mcp", "proxy_slug": "my-tool"}' \
| jq -r .server_id)
# 3. Set pricing: $0.01 per call, 100 free calls/month
curl -X POST .../api/v1/servers/$SERVER_ID/plans \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "Starter", "billing_model": "per_call", "price_per_call_usd_micro": 10000, "free_calls_per_month": 100}'
# Callers now connect via: .../proxy/my-tool/mcp访问您的仪表板：
https://mcp-billing-gateway-production.up.railway.app/dashboard实时跟踪收入、使用量、活跃调用者并配置您的服务器。
端点 | 方法 | 描述 |
| POST | 创建运营商账户 |
| GET | 查看个人资料和 API 密钥 |
| GET | 收入和使用统计信息 |
端点 | 方法 | 描述 |
| POST | 注册 MCP 服务器 |
| GET | 列出您的服务器 |
| POST | 创建定价计划 |
端点 | 方法 | 描述 |
| ANY | 带有计费强制执行的代理调用 |
| ANY | Streamable HTTP MCP 传输 |
┌─────────────┐ ┌──────────────────────┐ ┌──────────────────┐
│ AI Agent / │────▶│ MCP Billing Gateway │────▶│ Your MCP Server │
│ MCP Client │◀────│ (hosted on Railway) │◀────│ (upstream) │
└─────────────┘ └──────────────────────┘ └──────────────────┘
│
├── Payment verification (Stripe / x402)
├── Usage tracking & rate limiting
├── Tier enforcement
└── Operator dashboard网关是一个透明代理。调用者正常与您的 MCP 服务器交互 —— 网关拦截请求、验证支付、跟踪使用量并转发到您的上游服务器。
网关可在上述托管 URL 上使用。如需自托管部署，请克隆服务器仓库并通过 Docker 部署：
docker build -t mcp-billing-gateway .
docker run -p 3000:3000 mcp-billing-gatewayGet information about the MCP Billing Gateway service and integration options.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but fails to detail aspects like authentication needs, rate limits, response format, or error handling. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, 100% schema coverage, and an output schema exists, the description's focus on purpose is adequate. However, it lacks behavioral details (e.g., response structure, error cases) that could enhance completeness, especially since no annotations are provided to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose, which aligns with the baseline expectation for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get information') and target resource ('MCP Billing Gateway service and integration options'), making the purpose understandable. It lacks sibling tools for differentiation, but the scope is well-defined. No tautology or misleading elements are present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, such as for setup, troubleshooting, or comparison with other services. The description implies usage for general information retrieval but offers no context, alternatives, or exclusions, leaving the agent without operational direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2get_billing_infoScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools, as there are no other tools to confuse it with. The tool's purpose is clearly defined as retrieving billing information, making disambiguation trivial.
The single tool name 'get_billing_info' follows a clear verb_noun pattern (get + billing_info), which is consistent with itself. Since there are no other tools, there is no inconsistency to evaluate, and the naming is straightforward.
A single tool is too few for a server named 'MCP Billing Gateway SDK', which suggests a broader scope for managing billing operations. This minimal set likely leaves significant gaps in functionality, such as creating, updating, or deleting billing data, making it inappropriate for comprehensive billing tasks.
The tool set is severely incomplete for a billing gateway domain, as it only provides a read operation (get_billing_info) without any support for create, update, delete, or other essential billing workflows. This will cause agent failures when attempting to perform full billing lifecycle management.
MCP server integrating with Stripe - tools for customers, products, payments, and more.
Monetize any MCP server: x402 paywall, pay-per-call billing in USDC on Base, agent marketplace.
MCP server for Pinchwork - an agent-to-agent task marketplace with credits-based economy
