Skip to main content
Glama

nullclear_escrow_x402_call

Execute x402-gated HTTP API calls through deferred schema escrow; pay the seller only when the response matches your JSON Schema contract, otherwise spend $0.

Instructions

Execute an x402-gated HTTP API call through NullClear deferred schema escrow. The arbiter guarantees payment is only settled if upstream returns valid data matching your schema contract. If the seller hallucinates or crashes, $0 is spent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodNoGET
targetUrlYesUpstream API endpoint demanding x402 payment
jsonSchemaNoJSON Schema draft-07 contract that response must strictly satisfy
minTrustScoreNoMinimum acceptable trust score for seller (0-100, default 50)
sellerAgentIdNoSeller's agent ID for reputation check and Sybil wash-trade gating
requiredFieldsNoDot-notation field paths that must exist in response (e.g. ['data.price'])
buyerPrivateKeyNoOptional buyer private key (defaults to BUYER_PRIVATE_KEY environment variable)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the central economic behavior well ('payment is only settled if upstream returns valid data', '$0 is spent' on hallucination or crash), but omits operational traits such as the private-key auth requirement, settlement latency, and what happens on schema mismatch beyond the refund guarantee.

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 tight sentences, front-loaded with what the tool does and followed by the escrow guarantee. No filler, though the closing benefit sentence is partly rhetorical rather than informational.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-output-schema tool with no annotations, the description covers the value proposition but not the mechanics: how the response contract is enforced, what the caller receives on success vs. failure, or how the trust-score and seller-ID gates interact.

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 86%, so the schema already documents nearly every parameter. The description's mention of 'your schema contract' loosely ties to jsonSchema/requiredFields but adds no format, defaults, or interaction detail (e.g. how minTrustScore relates to sellerAgentId) beyond 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?

The description names a specific verb and resource ('Execute an x402-gated HTTP API call') and frames it within a named mechanism (NullClear deferred schema escrow). It is clearly distinct from the reputation-check and KYA-verification siblings, though it never explicitly contrasts itself with them.

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: the agent can infer this is the tool for making a paid upstream call with escrow protection, but there is no explicit when-to-use, no prerequisites, and no mention of the sibling tools or when to run reputation/KYA checks first.

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

This server cannot be deployed

Other Tools