결제 코드를 작성할 필요 없이 모든 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 소액 결제 — API 키 없이 AI 에이전트로부터 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
