YourAITools MCP Hub

PayGuard: Bulk OFAC list screening, 1-50 entries

screen_batch

Read-onlyIdempotent

Use for a LIST of 1-50 wallets in one request (billed as one call): payee lists, counterparties, transaction inputs/outputs. Mixed chains allowed; one invalid entry rejects the request. Same data as screen_address. Returns count, sanctioned_count, any_sanctioned, list_updated_at and results[] in input order. Not for: one wallet (screen_address) or more than 50 (split the list). Informational, not legal advice.

[PayGuard via YourAITools MCP Hub] Free tier: same as PayGuard's own MCP server (call without payment and without tier). Paid: batch $0.01 per call, with a credits key (Authorization: Bearer yatc_...) or x402 (USDC; the hub returns the payment terms). Failed tool calls aren't charged: credits are refunded automatically and x402 payments only settle on success.

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": {
      "addresses": "<addresses>"
    },
    "name": "screen_batch"
  }
}

Input Schema

Name	Required	Description	Default
`tier`	No	Paid tier: batch $0.01. Omit tier (with no credits key or x402 payment) to use the free tier.
`addresses`	Yes	1-50 wallet addresses, one string per element, in the same formats screen_address accepts (any chain; chains may be mixed, detected per entry). More than 50 entries or any malformed one returns a bad_request error.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / addresses / examples

Added value: +[
+  [
+    "0x8589427373D6D84E98730D7795D8f6f8731FDA16",
+    "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
+  ]
+]

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / addresses / description

Previous value: -"1-50 blockchain addresses, one string per element, e.g. [\"0x8589427373D6D84E98730D7795D8f6f8731FDA16\", \"bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh\"]. Each: 20-140 letters/digits, optional URI prefix such as \"ethereum:\" or \"bitcoincash:\" (stripped); EVM hex and bech32 match case-insensitively, base58 exactly. Chains may be mixed (detected per address). Any chain is accepted; the SDN list covers Bitcoin, Ethereum and other EVM chains (Base, Arbitrum, BNB Chain, Polygon...), Tron, Solana, Litecoin, Monero, Bitcoin Cash/SV/Gold, Dash, Dogecoin, Ethereum Classic, XRP, Verge, Zcash and USDT/USDC addresses. More than 50 entries or any malformed one returns a bad_request error."New value: +"1-50 wallet addresses, one string per element, in the same formats screen_address accepts (any chain; chains may be mixed, detected per entry). More than 50 entries or any malformed one returns a bad_request error."

First observedOct 24, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower, yet the description still adds substantive behavior: billing as a single call, whole-request rejection on one bad entry, free vs paid tier mechanics, refund-on-failure, and a legal disclaimer. Minor deduction for not stating a rate limit or the result entry shape beyond field names.

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?

The core usage rule and the sibling exclusion are front-loaded in the first two sentences. The trailing hub/payment boilerplate is longer than the functional description and could be trimmed, but it is discrete and scannable rather than interleaved.

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?

For a two-parameter read tool with an enumerable tier, the description covers input constraints, failure mode, billing tiers, and enumerates the returned fields despite no output schema. An agent has everything needed to invoke it and interpret the response.

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 coverage is 100%, so the baseline is 3; the description still adds the batch-as-one-call billing semantics for the tier parameter and states that results[] come back in input order, which the schema does not say. The chain-mixing and invalid-entry notes duplicate the schema but reinforce the call-level consequence.

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?

States a specific verb and resource ('screen a LIST of 1-50 wallets in one request'), the accepted input categories, and the batch scope. It explicitly distinguishes itself from the sibling screen_address, so an agent can route correctly 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 Guidelines5/5

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

Gives an explicit when-to-use rule (lists of 1-50, payees/counterparties/tx inputs-outputs) and an explicit 'Not for' clause naming the alternative (screen_address) plus the remedy for >50 entries (split the list). Coverage of the decision boundary is complete.

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

All YourAITools MCP Hub 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?