Skip to main content
Glama
Sign In

WattCoin

by io.github.WattCoin-Org
OverviewDiscussionsAdmin

CoinLoader/BotAppStore: Start checkout

start_checkout

CoinLoader/BotAppStore: Buy a bot license. By default (confirm=false) it only previews the price and creates nothing; call again with confirm=true only after the user agrees to buy. method=card with confirm=true creates a Stripe checkout session and returns a checkout_url for a human to pay (BotAppStore and CoinLoader). method=sol never creates an order: it returns a price preview and the bot page where a human completes SOL checkout (CoinLoader and wattcoin.org bots only; BotAppStore is card only). Use list_products first to get the SKU. Returns JSON.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sku": "<sku>"
    },
    "name": "start_checkout"
  }
}

Input Schema

NameRequiredDescriptionDefault
skuYesProduct or bundle SKU from list_products (e.g. mill-cert-matcher)
siteNoStore: botappstore, coinloader, or wattcoin (wattcoin.org bots, SOL only). Defaults to botappstore
methodNoPayment method: card (default; not allowed for site=wattcoin) or sol (preview only)
confirmNoDefault false = price preview, nothing created. true = create the card checkout session or SOL hand-off
storefrontNoAlias of site for botappstore or coinloader; site wins if both are given

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"false (default) = price preview, no order. true = hand off to checkout."New value: +"Default false = price preview, nothing created. true = create the card checkout session or SOL hand-off"
    • changedInput schema / properties / method / description
      Previous value: -"card (default; not for site=wattcoin) or sol"New value: +"Payment method: card (default; not allowed for site=wattcoin) or sol (preview only)"
    • changedInput schema / properties / site / description
      Previous value: -"botappstore (default), coinloader, or wattcoin (wattcoin.org bots, SOL only)"New value: +"Store: botappstore, coinloader, or wattcoin (wattcoin.org bots, SOL only). Defaults to botappstore"
    • changedInput schema / properties / sku / description
      Previous value: -"Product or bundle SKU from list_products"New value: +"Product or bundle SKU from list_products (e.g. mill-cert-matcher)"
    • changedInput schema / properties / storefront / description
      Previous value: -"Alias of site for botappstore / coinloader"New value: +"Alias of site for botappstore or coinloader; site wins if both are given"
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: the default path creates nothing, confirm=true creates a Stripe checkout session returning a checkout_url for a human to pay, and method=sol never creates an order. This is important because readOnlyHint=false could mislead an agent into thinking any call mutates state. It does not cover error/failure modes or what a preview response looks like in detail.

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 purpose, then the critical confirm semantics, then method/site constraints. Dense but each clause carries a distinct rule; the parenthetical store lists make it slightly choppy but nothing is redundant.

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?

With no output schema, the description supplies the key return information (checkout_url for card, price preview plus bot page for SOL) and prerequisites. A few details remain thin, such as the preview response shape and behavior on invalid site/method combinations, but it is sufficient to call correctly.

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

Parameters4/5

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

Schema coverage is 100%, so 3 is the baseline, but the description adds real semantic value: the interaction between site and method (wattcoin SOL-only, BotAppStore card-only) and the meaning of confirm=true for each method. It omits the storefront alias, though the schema documents that.

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

Purpose5/5

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

First sentence states a specific verb and resource ('Buy a bot license') tied to the named stores. It is clearly distinguishable from sibling read tools such as list_products, get_product, and get_pricing, and the preview-vs-create distinction is spelled out immediately.

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

Usage Guidelines5/5

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

Explicitly says to call list_products first to obtain the SKU, and states the two-step flow: confirm=false previews, confirm=true only after the user agrees. It also states when sol is valid (CoinLoader and wattcoin.org only, card-only on BotAppStore), leaving little to inference.

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

All WattCoin toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources