Skip to main content
Glama

Genexxis paid agent tools (x402)

sanctions_screen

Fuzzy-screen a name against OFAC SDN, UN, EU, UK, Swiss SECO, World Bank debarment and US BIS/State/Treasury non-SDN lists (optional lists= filter): matches with list, id, primary name, matched alias, score, type, programs, countries, dates of birth, listing date and reference, plus the date each list was checked. Price: $0.008 USDC per call, paid with x402 on Base.

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

Input Schema

NameRequiredDescriptionDefault
nameYesPerson, company or vessel name (any script; accents and legal suffixes are ignored)
typeNoOptional filter: individual, entity or vessel
listsNoOptional comma list to restrict: ofac, un, eu, uk, seco, worldbank, bis, us_csl (default all)
countryNoOptional country name or ISO2 code; boosts entries linked to that country
birthYearNoOptional 4-digit birth year (individuals); boosts entries within 1 year, demotes clear mismatches
thresholdNoMinimum score 0.5-1, default 0.85

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / lists
      Added value: +{
      +  "description": "Optional comma list to restrict: ofac, un, eu, uk, seco, worldbank, bis, us_csl (default all)",
      +  "type": "string"
      +}
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses cost ($0.008 USDC per call), the payment rail (x402 on Base), the return-field set, and the per-list check dates. It does not cover failure behavior, rate limits, or how scores are ranked, which keeps it below 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?

Front-loaded with the core action and list coverage, then the return fields, then the price. It is a single dense run-on sentence, but nearly every clause is load-bearing; the enumeration of lists could have been compressed.

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?

No output schema exists, so the description compensates by enumerating the match fields returned. Combined with the pricing disclosure and the full schema coverage, an agent has enough to call and interpret results; only edge-case behavior (zero matches, timeouts) is absent.

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 parameters are already fully documented. The description's only parameter remark ('optional lists= filter') restates what the schema says, adding no new semantics. Baseline 3 applies.

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 specific verb and scope: 'Fuzzy-screen a name against OFAC SDN, UN, EU, UK, Swiss SECO, World Bank debarment and US BIS/State/Treasury non-SDN lists.' The coverage is stated precisely, but it never names the sibling sanctions_address, so an agent must infer the name-vs-address split from the object of the verb alone.

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?

The usage context is implied by the list enumeration and the optional lists filter, but there is no explicit statement of when to use this vs sanctions_address, or when a screening result should be escalated. The agent gets a plausible default (all lists) and nothing about exclusions.

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