ExchangeRebel — pay-per-call APIs for AI agents (x402 on Solana)

lifecycle_precheck

FREE headline pre-check (100/day per wallet; pass caller). Returns assessability only - whether the log is in the published contract form; no counts are computed. The full signed analysis is the paid lifecycle_analyse call.

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": {
      "caller": "<caller>",
      "log": "<log>"
    },
    "name": "lifecycle_precheck"
  }
}

Input Schema

Name	Required	Description
`log`	Yes	The challenge-issuance log to analyse: entries with challenge_id, issued_at, expires_at, optional used_at and rail, in the published log contract form. Processed in memory only, never stored.
`as_of`	No	The evaluation timestamp (ISO 8601) the counts are computed as of.
`caller`	Yes	Solana base58 wallet of the operator; keys the free allowance (100/day per wallet).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does disclose genuinely useful behavior: it is free, rate-limited to 100/day per wallet, keyed on the caller wallet, and deliberately computes no counts. What it omits is the shape of the 'assessability' response and what happens when the daily allowance is exhausted (error vs. degraded result), which matters for an unannotated tool.

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

Conciseness5/5

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

Two tight sentences, front-loaded with the free/assessability-only constraint followed by the paid alternative. No filler, and the most decision-relevant facts (cost, quota, output limits) come first.

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 three-parameter precheck tool with no output schema and no annotations, the description covers cost, quota, keying, scope of output and the paid counterpart. It leaves the actual return shape ('assessability') and quota-exceeded behavior to inference, a modest gap rather than a blocking one.

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 caller, log and as_of are already fully documented. The description reinforces that 'caller' keys the free allowance and that the log must be in the 'published contract form', but adds no format or syntax detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb and resource ('headline pre-check' of the challenge-issuance log) and immediately bounds it: 'Returns assessability only - whether the log is in the published contract form; no counts are computed.' It explicitly names the sibling that does the full job (lifecycle_analyse), so an agent can distinguish the two without opening either schema.

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?

The description routes clearly: use this for the free 'headline pre-check', use the paid lifecycle_analyse for the 'full signed analysis'. The cost/quota framing ('FREE ... 100/day per wallet') makes the tradeoff explicit. It stops short of stating when a pre-check result should block or proceed to the paid call, so a 4 rather than a 5.

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

All ExchangeRebel — pay-per-call APIs for AI agents (x402 on Solana) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?