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

facilitator_fit_check

$0.01 USDC on Solana per challenge - the payment buys one signed facilitator fit check for the challenge you submit: its named facilitator's /supported graded live as served (serves-kind / testnet-only / does-not-serve), all factors printed, guarantees exactly as published or their absence, and the PayAI free-credit state when the named facilitator is PayAI (otherwise NOT-PUBLISHED).

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": {
      "network": "<network>",
      "scheme": "<scheme>",
      "facilitator_url": "<facilitator_url>"
    },
    "name": "facilitator_fit_check"
  }
}

Input Schema

Name	Required	Description
`payTo`	No	Optional seller wallet; required for the PayAI free-credits leg when the named facilitator is PayAI.
`scheme`	Yes	The challenge scheme (e.g. exact).
`network`	Yes	The challenge network (e.g. solana, base).
`facilitator_url`	Yes	The facilitator base URL whose /supported is graded; the host is reported, the path is never stored.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A3.6/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 it well: it discloses the $0.01 USDC/Solana cost per challenge (implying non-idempotent billing per call), the exact graded outcomes, that 'all factors' are printed, that guarantees appear as published or their absence, and the NOT-PUBLISHED fallback for non-PayAI facilitators. It stops short of stating side effects, latency, or what the signed artifact looks like.

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

Conciseness3/5

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

The cost is front-loaded, which is good, but the entire definition is one long run-on sentence packing cost, inputs, and several output clauses together. Every clause carries information, yet the lack of structure makes it harder to parse than it needs to be.

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?

Given a paid grading tool with no output schema and no annotations, the description is fairly complete: cost model, graded outcomes, and fallback states are all covered, and the schema fully documents parameters. The notable gap is that a $0.01 USDC payment is described but no payment mechanism or parameter appears in the schema, leaving how payment is settled unexplained.

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 coverage is 100%, so the schema already documents all four parameters, establishing a baseline of 3. The description adds only marginal meaning beyond the schema — chiefly the conditional that the PayAI free-credit state (and thus the payTo leg) matters only when the named facilitator is PayAI, otherwise NOT-PUBLISHED.

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 action on a specific resource: it buys a 'signed facilitator fit check' that grades the named facilitator's /supported live, with enumerated outcomes (serves-kind / testnet-only / does-not-serve). It's clear what the tool does, but it never names or distinguishes the sibling tools facilitator_fit_criteria and facilitator_fit_precheck, leaving the agent to infer the division of labor.

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 only implied: 'per challenge' and 'the challenge you submit' suggest you call it with a network/scheme/facilitator_url to grade a specific facilitator. There is no explicit when-to-use versus facilitator_fit_precheck or facilitator_fit_criteria, and no stated prerequisites or exclusions, so the agent must infer the workflow position.

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?