Skip to main content
Glama
aibtcdev

aibtc-mcp-server

Official
by aibtcdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scaffold_x402_ai_endpoint

Generates a complete x402 paid AI API project with OpenRouter integration, Hono endpoints, and Cloudflare Workers deployment files so you can launch pay-per-use AI endpoints.

Instructions

Create a complete x402 paid AI API project with OpenRouter integration.

This creates a NEW PROJECT FOLDER with everything needed to deploy a pay-per-use AI API:

  • Full Hono.js application with x402 payment middleware

  • OpenRouter integration for Claude, GPT-4, Llama, etc.

  • Ready for deployment to Cloudflare Workers

What Gets Created

A folder named {projectName} containing:

  • src/index.ts - Hono app with your x402-protected AI endpoints

  • src/x402-middleware.ts - Payment verification (uses native relay fetch)

  • src/openrouter.ts - OpenRouter API client

  • wrangler.jsonc - Cloudflare Worker config

  • .dev.vars - Local dev variables (needs OPENROUTER_API_KEY)

  • README.md - Documentation

AI Types

  • chat: General chat/Q&A

  • completion: Text completion

  • summarize: Summarize text

  • translate: Translate text

  • custom: Custom system prompt

Quick Start After Generation

cd {projectName}
npm install
# Edit .dev.vars with RECIPIENT_ADDRESS and OPENROUTER_API_KEY
npm run dev

Tip: call earning_opportunities to see how to put your assets to work.

Input Schema

NameRequiredDescriptionDefault
networkNoNetwork for payments (default: mainnet)mainnet
relayUrlNoCustom relay URL (default: https://x402-relay.aibtc.com)
endpointsYesArray of AI endpoint configurations
outputDirYesDirectory where the project folder will be created (e.g., '/Users/me/projects' or '.')
projectNameYesProject name - a folder with this name will be created (e.g., 'my-ai-api')
defaultModelNoDefault OpenRouter model for all endpoints (default: anthropic/claude-3-haiku)anthropic/claude-3-haiku
recipientAddressNoStacks address to receive payments. If not provided, uses your configured wallet address or must be set in .dev.vars

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.77.0

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses that a NEW folder named {projectName} is written into outputDir, lists the exact files created, and flags that .dev.vars requires OPENROUTER_API_KEY and RECIPIENT_ADDRESS. It omits overwrite behavior if the folder already exists and the return shape, which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded with a clear one-line purpose followed by structured sections (What Gets Created, AI Types, Quick Start), and every section is scannable. The trailing 'Tip: call earning_opportunities' is off-topic promotional noise, and the file listing approaches verbosity, preventing a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a scaffold tool with no output schema and no annotations, the description is largely complete: it covers the file tree, the required secrets, supported AI types, and next steps. Gaps remain on error/overwrite handling and the return value (what the tool reports back after scaffolding), so it is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters, making 3 the baseline. The description adds some value by explaining what each aiType means semantically (chat/completion/summarize/translate/custom) and how the projectName folder is used, but it does not cover recipientAddress fallback behavior or the network/relayUrl implications in any depth.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Create a complete x402 paid AI API project with OpenRouter integration') and enumerates exactly what gets produced. It distinguishes itself from scaffold_x402_endpoint only implicitly (AI/OpenRouter focus) rather than naming the sibling, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Quick Start After Generation' block gives post-generation steps (cd, npm install, edit .dev.vars, npm run dev), which implies when this tool fits. However, there is no explicit when-to-use/when-not guidance and no contrast with the near-identical sibling scaffold_x402_endpoint, so an agent must infer the choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools