Skip to main content
Glama
Sign In

Verse by A-to-Mind

by io.github.atomeam
OverviewDiscussionsAdmin

Backtest a trading bot (0.05 USDC, x402)

paid_backtest

Backtest a Verse trading bot (trend-50-200, breakout-20-10, dip-rsi2) on real BTC-USD or ETH-USD daily candles: your parameters, fee, slippage and dates; every trade, the equity curve, max drawdown, buy-and-hold beside it and a walk-forward out-of-sample test. Read only: nothing is traded. Costs 0.05 USDC on Base (eip155:8453) per call, paid with x402 over MCP: call it without payment to get the PaymentRequired terms in structuredContent, then call it again with the signed PaymentPayload in params._meta["x402/payment"]. The settlement comes back in result._meta["x402/payment-response"]. A call that cannot be done (bad input, the service busy) is never charged. The same service over HTTP: POST https://a-to-mind.com/api/x402/backtest.

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": {
      "bot": "<bot>"
    },
    "name": "paid_backtest"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoYYYY-MM-DD, optional
botYestrend-50-200 | breakout-20-10 | dip-rsi2
feeNofee per trade as a fraction (0.008 = 0.8%)
fromNoYYYY-MM-DD, optional
pairNoBTC-USD or ETH-USD
paramsNothe bot's parameters, optional
slippageNoslippage per trade as a fraction

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations it discloses the exact price (0.05 USDC), the network (Base, eip155:8453), the x402 handshake shape, where the settlement receipt appears, and that unsuccessful calls are not billed. It also states "nothing is traded," clarifying that market state is untouched. Annotations only say readOnlyHint=false / destructiveHint=false / idempotentHint=false; the description supplies the financial and transactional consequences those hints cannot express.

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 what is backtested and what comes back, followed by safety, price, and payment mechanics in that order. Dense but every clause carries information; the only cost is a few run-on sentences that pack several ideas each.

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

Completeness5/5

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

There is no output schema, yet the description enumerates the returned artifacts in detail (per-trade records, equity curve, max drawdown, buy-and-hold benchmark, walk-forward out-of-sample test), so an agent knows what it is buying. Combined with the payment flow and failure-billing rule, nothing an agent needs before calling is missing.

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 already 100%, with units and formats spelled out (fee as a fraction, slippage as a fraction, YYYY-MM-DD dates, pair enum). The description's "your parameters, fee, slippage and dates" merely echoes those fields and adds no new semantics such as defaults or valid ranges. Baseline 3 is appropriate when the schema carries the load.

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?

Names a specific verb and resource ("Backtest a Verse trading bot"), enumerates the three supported bot strategies, and names the data (real BTC-USD or ETH-USD daily candles). Nothing about the name is left to guesswork, and the output set (trades, equity curve, max drawdown, buy-and-hold, walk-forward) further pins down what it produces.

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

Usage Guidelines4/5

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

Gives a concrete invocation protocol: call without payment to obtain PaymentRequired terms, then call again with the signed PaymentPayload, and notes failures are never charged. It also points to the equivalent HTTP endpoint. It stops short of explicit when-to-use/when-not guidance versus alternative tools, but the sibling list contains no comparable backtesting service, so the practical gap is small.

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

All Verse by A-to-Mind 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