Skip to main content
Glama
aibtcdev

aibtc-mcp-server

Official
by aibtcdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scaffold_x402_endpoint

Generates a deployable Cloudflare Worker project for a paid x402 API, including Hono endpoints, payment middleware, pricing tiers, and environment config.

Instructions

Create a complete x402 paid API project as a Cloudflare Worker.

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

  • Full Hono.js application with x402 payment middleware

  • Ready for deployment to Cloudflare Workers

  • Based on production patterns from x402-api and stx402

What Gets Created

A folder named {projectName} containing:

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

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

  • wrangler.jsonc - Cloudflare Worker config with staging/production envs

  • package.json - Dependencies including hono (no x402-stacks dependency)

  • .dev.vars - Local dev variables (pre-filled if you have a wallet)

  • README.md - Documentation

Pricing Tiers

Use tiers for consistent pricing:

  • simple/standard: 0.001 STX

  • ai: 0.003 STX

  • heavy_ai: 0.01 STX

  • storage_read: 0.0005 STX

  • storage_write: 0.001 STX

Quick Start After Generation

cd {projectName}
npm install
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 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-x402-api')
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 substantial work: it discloses that a NEW folder is created on disk, lists every generated file, notes `.dev.vars` is pre-filled only if a wallet exists, and gives the deployment target. It omits what happens if the target folder already exists (overwrite/error) and whether generation makes any network calls to the relay.

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?

Front-loaded with the core one-sentence purpose, then organized into scannable sections (What Gets Created, Pricing Tiers, Quick Start). The file-by-file listing is long but earns its place for a scaffolding tool; the closing `earning_opportunities` tip is the one piece that does not serve this tool's purpose.

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 six-parameter generator with no annotations and no output schema, the description supplies what is generated, where, and how to run it. It falls short on the return side — with no output schema, the description should say what the tool reports back (created path, success/failure) — and on failure modes such as an existing folder.

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 baseline is 3 and the description mostly repeats structured information. It does add real value with the pricing-tier table, which maps tier enum values to concrete STX amounts that the schema's enum list does not provide, but it says nothing about `outputDir`, `relayUrl`, or `recipientAddress` behavior beyond what the schema already states.

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?

States a specific verb and resource: create a complete x402 paid API project as a Cloudflare Worker, and enumerates exactly what the generated project contains. The one gap is sibling differentiation — `scaffold_x402_ai_endpoint` appears in the sibling list and is presumably close in function, yet the description never states how this differs (e.g., generic endpoints vs. AI-specific).

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?

Usage is implied by the framing (you want to stand up a pay-per-use API) and a Quick Start block tells the agent what to do after generation, but there is no explicit when-to-use/when-not, no prerequisites, and no routing between this tool and `scaffold_x402_ai_endpoint`. The trailing `earning_opportunities` tip is unrelated to selecting this tool.

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