Skip to main content
Glama

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

recoverability_probe_probe

$0.05 USDC on Solana per battery run - the payment buys one run of the published error-recoverability battery (exactly 4 calls: unknown tool, missing required parameter, wrong type, corrected retry) against the one target URL you attested you own or are authorized to operate, and one signed report grading each battery item against the published rubric of error-recoverability/v1 (channel used; whether the error names the offending parameter and the expected type/format; whether the corrected retry succeeds), with every factor printed and a bounded excerpt (at most 500 characters) of your own server's response for each item quoted as evidence. No composite score is computed. This is not third-party testing.

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": {
      "target_url": "<target_url>",
      "tool_name": "<tool_name>",
      "required_parameter": "<required_parameter>",
      "expected_type": "<expected_type>",
      "valid_arguments": "<valid_arguments>",
      "attestation": "<attestation>"
    },
    "name": "recoverability_probe_probe"
  }
}

Input Schema

NameRequiredDescriptionDefault
tool_nameYesName of one tool on the target server (1-128 characters).
target_urlYesThe one target URL of the operator's OWN MCP server (http/https, no embedded credentials; loopback/private/link-local targets are refused). The battery POSTs only to this URL, exactly as submitted.
attestationYesOwnership attestation: operator_wallet, the published attestation statement verbatim, target_url exactly equal to the submission's target_url, battery_id error-recoverability-battery/v1, consent true, attested_at within the past 7 days.
expected_typeYesThe expected type of the required parameter: string, number, integer, boolean, object, or array.
valid_argumentsYesThe operator's own valid arguments for the declared tool; must contain the required parameter with a value of the expected type.
required_parameterYesOne required parameter of the declared tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/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 substantial work: it discloses the $0.05 USDC-on-Solana price, that payment buys exactly one run of four requests, that it POSTs to the submitted URL, that evidence excerpts are capped at 500 characters, and that no composite score is produced. It leaves out failure/refund behavior if the target is unreachable and any timing expectations.

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 content is dense and nearly every clause carries information, and the price is appropriately front-loaded. However it is delivered as a single run-on sentence of roughly 150 words, which makes the four-call battery, the report contents, and the scope disclaimer hard to scan.

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 six-parameter, all-required payment tool with a nested attestation object, no annotations, and no output schema, the description compensates well by describing what the signed report grades and that it withholds a composite score. Gaps remain around failure and refund handling and what the operator receives if the target rejects the request.

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 the baseline is 3; the description adds only limited meaning beyond it, mainly framing target_url as the one URL the operator attested ownership of and stressing that the battery POSTs exactly as submitted. The attestation object's fields are already enumerated in the schema.

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 precise verb-with-resource: it runs the published error-recoverability battery (exactly 4 named calls) against one attested target URL and returns a signed rubric-graded report. The scope is unambiguous. It never names the sibling tools (recoverability_probe_precheck, recoverability_probe_criteria, probe_grade_grade), so an agent must infer the precheck-before-paying relationship from naming alone.

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 clear context: this is for testing recoverability of a server the operator owns or is authorized to operate, with an explicit exclusion ("This is not third-party testing"). It does not name an alternative or prerequisite such as the precheck sibling, which is the most likely routing question for a paid tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources