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

scope_hygiene_precheck

FREE pre-check (100/day per wallet; pass caller). Returns assessability only - the full assessability matrix row for the declared family and form plus the resolved per-factor status; no factor is computed and no hygiene finding is returned. The full signed report is the paid scope_hygiene_audit 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>",
      "form": "<form>",
      "records": "<records>"
    },
    "name": "scope_hygiene_precheck"
  }
}

Input Schema

Name	Required	Description
`form`	Yes	The export form: full_text or hash_only.
`caller`	Yes	Solana base58 wallet of the operator; keys the free allowance (100/day per wallet).
`family`	Yes	The memory-store family of the export: mem0, zep_graphiti, letta, or generic.
`records`	Yes	The export's records (up to 1,000; body up to 262,144 bytes). Processed in memory only and never stored.
`variant`	No	Optional family variant (e.g. zep_cloud for Zep/Graphiti).
`manifest`	No	Optional manifest declaring scope keys / sharing markers; a declaration replaces the family default scope-key set.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden and does substantial work: it declares the rate limit (100/day per wallet), the required caller credential, and precisely what is and is not returned (assessability matrix row plus resolved per-factor status, no computed factors, no findings). It does not spell out error behavior or whether the allowance is consumed on invalid input, which keeps it short of 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.

Conciseness4/5

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

Three sentences, front-loaded with the key differentiator ('FREE pre-check') and the scope limitation, with zero filler. The em-dash chain in the middle sentence is dense but each clause carries distinct information about what is returned.

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, nested-object tool with no annotations and no output schema, the description fills the most important gap by describing the return payload (assessability matrix row plus per-factor status). The remaining omissions — error modes, whether malformed records fail the whole call, and how the daily allowance is counted — are secondary for an agent that just needs to invoke it correctly.

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 all six parameters are already documented in the schema, establishing a baseline of 3. The description reinforces the role of caller (keys the free allowance) and of the declared family/form in resolving the matrix row, but adds no format, enum, or constraint detail beyond what the schema already states.

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 ('pre-check' of scope hygiene) and immediately bounds the result set: 'Returns assessability only... no factor is computed and no hygiene finding is returned.' It also names the sibling that does the full job ('The full signed report is the paid scope_hygiene_audit call'), 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?

It gives a clear selection rule: use this free pre-check to get the assessability row, and go to scope_hygiene_audit for the signed full report. The 'FREE... 100/day per wallet; pass caller' clause tells the agent the prerequisite for the free path, but there is no explicit 'do not use this if you need actual findings' exclusion statement beyond the implied contrast.

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?