Skip to main content
Glama
fairquery

fairquery-sanctions-screener

Official
by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List covered sanctions sources (free)

list_sources
Read-onlyIdempotent

Lists official sanctions sources (OFAC SDN/Consolidated, EU, UK, UN), their authorities, download URLs, the 0–100 score scale, and disclaimer for selecting screening lists or citing coverage.

Instructions

WHAT: Static list of the official sanctions lists screen_names checks (id, name, issuing authority, download URL), the 0-100 score scale and the legal disclaimer. WHEN TO USE: to choose the lists parameter for screen_names, cite sources in a report, or explain coverage. WHEN NOT TO USE: to screen a name - use screen_names. Does not download lists or report list freshness. COST: free; local, no network, no APIFY_TOKEN, deterministic. (screen_names costs $0.003 per name.) RETURNS: {sources:[{id,name,authority,url}], score_scale, disclaimer}. PARAMETERS: None: call with an empty object {}; the result is static and cannot be filtered. Its output feeds screen_names: each sources[].id (OFAC_SDN, OFAC_CONS, EU, UK, UN) is a valid value for its lists parameter, and score_scale explains how its minScore threshold is applied. EXAMPLE: {} -> {"sources":[{"id":"OFAC_SDN","authority":"US Treasury OFAC",...},...]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourcesYesCovered lists; id is the value for screen_names.lists
disclaimerYesLegal disclaimer to show with results
score_scaleYesHow best_score is computed

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.2
    • addedOutput schema / properties / disclaimer / description
      Added value: +"Legal disclaimer to show with results"
    • addedOutput schema / properties / score_scale / description
      Added value: +"How best_score is computed"
    • addedOutput schema / properties / sources / description
      Added value: +"Covered lists; id is the value for screen_names.lists"
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds behavior they cannot express: cost is free and local with no network or APIFY_TOKEN, deterministic output, versus $0.003 per name for screen_names. This cost/execution context is exactly the kind of value-add that structured fields cannot carry.

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?

Labeled sections (WHAT/WHEN/COST/RETURNS/PARAMETERS/EXAMPLE) are scannable and front-loaded. However, the RETURNS shape and the EXAMPLE line largely duplicate each other, and the parameter-less nature is restated in two places, so a small amount of text is redundant.

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?

Given an output schema exists, return values need not be explained, yet the description still sketches the shape and adds the cross-tool linkage to screen_names that the output schema cannot convey. Nothing an agent needs to call a zero-parameter, closed-world tool correctly is missing.

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?

Zero parameters, so the baseline is 4. The description still earns its keep by stating the empty-object calling convention and that results cannot be filtered, plus mapping output ids (OFAC_SDN, OFAC_CONS, EU, UK, UN) to the sibling's lists parameter. That is invocation guidance rather than parameter semantics, so it does not push above the baseline.

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 ('Static list of the official sanctions lists screen_names checks') and enumerates the returned fields (id, name, issuing authority, download URL). An agent can instantly separate this reference-data tool from the sibling screen_names screening tool.

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?

The WHEN TO USE section names three concrete scenarios (choosing the lists parameter, citing sources, explaining coverage) and WHEN NOT TO USE explicitly routes screening to screen_names. It also discloses what the tool does not do (no downloading, no freshness).

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

Deploy Server

Other Tools