Skip to main content
Glama

Paddock

by finance.paddock
OverviewDiscussionsAdmin

Verify Before Pay

verify_before_pay
Read-only

Should my agent pay this endpoint right now? Free key - a free pk_free_ key covers it against a shared 10 calls/day; $0.25 per call via x402 beyond it. Over MCP only, 1 free trial call/day is available without a key. CALL THIS BEFORE YOUR AGENT AUTHORIZES ANY x402 PAYMENT. An unpaid GET and POST at query time decode the 402 from the body AND the payment-required header; HTTP 200 is never treated as live. A contract mismatch is route:false and names the field (network, asset, seller, price). Includes independent paid-fulfillment results where available — whether a third party has actually paid this endpoint and got a valid response back, with the settlement hash. Test the result with route === true: the string "inconclusive" is truthy, and it is the one case where you must not pay on our say-so. The bias is deliberate: where evidence is incomplete, verify_before_pay favors inconclusive over a false pass — it will more often decline to clear a good endpoint than clear a bad one. route: true means the live contract matched your expectations — it is not an all-clear on every signal: stale settlement, a circular flag, a payTo divergence, and a failed request pre-flight can each coexist with it, so read the checks block rather than route alone. route_state carries the same verdict as route, always as a string ("true", "false", "inconclusive"), for clients that cannot type a boolean-or-string field. contract_and_request_ok is the narrower combined verdict: true only when route is true AND your own declared request passed pre-flight, false when either is bad, and the string "not_assessed" when a term was never established (usually because you passed no intended_params). Test it with === true; contract_and_request_ok_excludes names the risk categories it is silent on. No success-rate field is returned, deliberately: Paddock observes settlements, not failed calls, so recency and frequency are reported instead. Pass attest: true to also issue a signed, publicly fetchable record of this verdict — returns an attestation id and a URL a third party can verify independently against Paddock's published key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
attestNoAlso issue a signed, publicly fetchable record of this verdict. Returns an attestation id and a URL a third party can verify independently against Paddock's published key.
pay_toNoThe recipient wallet from the 402 you are about to settle. CHECKED against the live challenge: if this endpoint is not currently asking to be paid at that wallet, route is false. Give this, endpoint_url, or both.
api_keyNoPaddock API key. A free key (pk_free_) is enough for this tool — POST an email to paddock.finance/api/keys/free to get one. Builder/Pro Agent keys also work.
endpoint_urlNoThe resource URL your agent is about to pay, e.g. 'https://api.example.com/x402/search'. This is what gets probed.
expect_assetNoAsset contract address you expect, e.g. Base USDC. A mismatch returns route:false.
expect_sellerNoSeller domain you expect, e.g. 'api.example.com'. A mismatch returns route:false.
expect_networkNoNetwork you expect, e.g. 'eip155:8453' or 'base'. A mismatch returns route:false.
intended_paramsNoParameter NAMES your request will carry, comma-separated or as a query string, e.g. 'slug,limit' or '?slug=amazon-us'. Values are discarded. Checked against the schema the 402 declares; a missing required name is reported and does NOT change route.
expect_price_usdcNoPrice in dollars you expect to pay, e.g. 0.01. Any difference returns route:false and names the field.
intended_params_emptyNoSet true if your paid request will carry NO parameters at all. That is an assertion and it is checked: against a challenge that declares anything required, an empty request fails pre-flight. Omitting both this and intended_params means 'I have not told you', which is reported, never read as 'none'. Passing both is an error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations (readOnlyHint, openWorldHint, destructiveHint=false) are consistent and minimal, and the description far exceeds them: it discloses that probes are unpaid GET/POST, that HTTP 200 is never treated as live, that the bias favors 'inconclusive', that route:true is not an all-clear, that no success-rate field exists by design, and that attest:true issues a signed record. This is unusually rich behavioral context beyond the annotations.

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

Conciseness2/5

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

This is an oversized wall of run-on text with no headers or bullets. The single most important instruction ('CALL THIS BEFORE YOUR AGENT AUTHORIZES ANY x402 PAYMENT') is buried mid-paragraph after pricing minutiae, so it is neither front-loaded nor easy to scan. The content is mostly relevant but the density and lack of structure hurt selection usability.

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

Completeness5/5

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

There is no output schema, yet the description fully covers the return surface: route, route_state, contract_and_request_ok, contract_and_request_ok_excludes, the checks block, and the attestation id/URL. Given a 10-parameter tool with no output schema and no required params, the agent has everything needed to call it and interpret the verdict.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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, but the description adds cross-parameter meaning beyond the schema: how each expect_* mismatch yields route:false, that omitting intended_params means 'I have not told you' rather than 'none', and that passing both intended_params and intended_params_empty is an error. It slightly over-restates what the per-field schema already covers, so it stops short of a 5.

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+resource: it verifies whether an x402 payment endpoint should be paid before authorization. The opening framing ('Should my agent pay this endpoint right now?') and the explicit job of probing a 402 make the purpose unmistakable and clearly distinguish it from the data-fetching siblings (get_liveness, get_market_summary, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit directive: 'CALL THIS BEFORE YOUR AGENT AUTHORIZES ANY x402 PAYMENT.' It also spells out the pricing/access conditions (free pk_free_ key at 10 calls/day, $0.25/call via x402 beyond, 1 free trial/day without a key) and the alternative path, so an agent knows exactly when this applies and what it costs.

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

All Paddock toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources