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

probe_grade_precheck

FREE pre-check (100/day per wallet; pass caller). Returns assessability only - the declared family's published expectation table and binding-strength wording, disclosed before payment; no grades are returned. The full signed report is the paid probe_grade_grade 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>",
      "family": "<family>",
      "script_id": "<script_id>",
      "issued_nonce": "<issued_nonce>",
      "canary_echo": "<canary_echo>",
      "probes": "<probes>"
    },
    "name": "probe_grade_precheck"
  }
}

Input Schema

Name	Required	Description
`caller`	Yes	Solana base58 wallet of the operator; keys the free allowance (100/day per wallet).
`family`	Yes	The memory-store family the probe run targeted: mem0, zep-cloud, graphiti, or letta.
`probes`	Yes	Entries for the five probes (persistence_truth, scope_coherence, replay_duplication, repeatable_read, feature_liveness), each with status observed-pass / observed-fail / not-run and an evidence object.
`variant`	No	Optional family variant (e.g. platform / oss).
`script_id`	Yes	The published probe script id the run followed (probe-script/<family>/v1).
`canary_echo`	Yes	The nonce exactly as it came back through the store's read paths (the canary echo).
`issued_nonce`	Yes	The per-run nonce the published script issued for this run (8-256 characters).
`declared_scope`	No	Optional declared scope of the run ("synthetic" for a script run).
`claimed_expectations`	No	Optional claimed expectations: probe ids mapped to RUNNABLE / PARTIAL / NOT RUNNABLE.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 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 full burden and does well: it discloses cost (FREE), a concrete rate limit (100/day per wallet), that the allowance is keyed on the caller argument, and that no grades are returned. It does not cover failure modes or what happens when probes are malformed, which keeps it below a 5.

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?

Three compact sentences, front-loaded with FREE and the rate limit, then the return scope, then the paid alternative. No filler, and the most decision-relevant facts 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?

There is no output schema, and the description compensates by stating exactly what is returned (the family's expectation table and binding-strength wording) and what is not (grades, signed report). For a 9-parameter tool this is fairly complete, though error behavior and the prerequisite relationship between script_id and canary_echo remain unstated.

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% and all nine parameters are documented in the schema, so the description adds little parameter meaning beyond reiterating that the caller keys the free allowance. The baseline of 3 applies 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?

The description states a specific verb and resource — a free pre-check that returns assessability for a probe run — and explicitly distinguishes itself from the paid sibling probe_grade_grade. An agent can tell immediately this is a preview tier rather than a grading call.

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?

It gives clear routing context: this is the pre-payment step, and 'The full signed report is the paid probe_grade_grade call' names the alternative and the condition that selects it. It stops short of stating explicit exclusions (e.g. don't call this when you already need grades), so it is not quite a full when/when-not statement.

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?